You can program in assembly under Win32 all you like. You just can't call DOS interfaces (e.g. int 21h). Complaining that your int 21h based code doesn't work in Win32 apps is pretty much exactly the same as complaining that your Macintosh app doesn't run under Windows - of course not, they're different OS's.

The issue is complicated by the fact that Windows will emulate DOS apps. So your int 21h code will work *if* you use DOS tools to build it. VC.Net is not a DOS tool.

Quote:Original post by Prozak
If you want to code in assembly, just drop back to DOS ... and you won't have to deal with Win32's idiosyncrasies....

Ye gods. Do you really want to go back to segmented architecture, 64k limits, and EMS/XMS memory?!? DOS has way more ideosyncasies than Win32 :).

Quote:Original post by Anon MikeYe gods. Do you really want to go back to segmented architecture, 64k limits, and EMS/XMS memory?!? DOS has way more ideosyncasies than Win32 :).

Well, to get over the 64k limits all you need to do is go into protected mode, or install an EMX/XMS lib and work from that.

All he needs is an editor, and perhaps understanding the idiosyncrasies of DOS, he can see why some of the choices for Win32 where made the way they where made...

All I'm saying is that some people like to go back to the roots of it all... I know I'm one of them...

How Do Windows NT System Calls REALLY Work?

Inside the Native API

Here's an example of the assembler code for invoking a system call on NT

NtCreateFile:    mov    eax, 0x0000001A    lea    edx, [esp+04]    int    0x2E     ret    0x2C

Eax holds the system call number, Edx hold a pointer to the function arguments.

The signature of this function is

NTSTATUS NtCreateFile(  PHANDLE FileHandle,  ACCESS_MASK DesiredAccess,  POBJECT_ATTRIBUTES ObjectAttributes,  PIO_STATUS_BLOCK IoStatusBlock,  PLARGE_INTEGER AllocationSize,  ULONG FileAttributes,  ULONG ShareAccess,  ULONG CreateDisposition,  ULONG CreateOptions,  PVOID EaBuffer,  ULONG EaLength);

There are more than 256 system calls available on Windows NT/2K/XP, most of them are wrapped in functions exported by ntdll.dll.

The direct syscall interface for Windows is not guaranteed to never change. You'll save yourself a lot of headache by just calling the documented dll entrypoint.