If my program primarily uses the win32 API, are my API calls being emulated in Windows XP/Vista/7?
+1
A:
No. The Win32 API is a bit misnamed. It probably should have been named the Windows API. It is not emulated unless your code is actually running in one of the emulation modes.
JaredPar
2009-05-07 13:46:06
It's Win32 because the Windows API already existed as 16-bit.
RolandTumble
2009-05-07 16:23:43
Win16 was originally branded the "Windows API"; on the introduction of 32-bit Windows, the names Win16 and Win32 came about because there were significant differences, but Microsoft regularly uses the name "Windows API" when referring to Win32 (and Win64, which is source-level compatible).
ephemient
2009-05-07 16:43:49
+1
A:
What Jared said about the naming. Not sure if this is what you were getting at, but if you are running a 32 bit process on a 64 bit operating systems, there is an emulation (or "thunking") layer which allows them to run. This is true for all 64 bit editions of Windows.
jlew
2009-05-07 14:16:55
The VDMs running 16-bit apps on 32-bit Windows also use thunks to translate Win16 calls into Win32 calls. It's not really emulation so much as a technique which helps to forward calls between the otherwise incompatible 16-bit and 32-bit environments. Windows on MIPS and Alpha had *real* emulation to run 16-bit x86 apps, but that's neither needed nor present in Windows on x86.
ephemient
2009-05-07 16:38:46
+3
A:
There's the Windows NT kernel underneath it all, and native NT applications use the (largely undocumented) NT API to interact with it.
csrss.exe, the "Client/Server Runtime Subsystem", is a native NT application which provides the user-mode Win32 subsystem, and win32k.sys provides the kernel-mode Win32 subsystem. Win32 applications cannot run without these two loaded.
smss.exe, the "Session Manager Subsystem", is the first application to be executed during startup. As one of its tasks, it starts the Win32 subsystem.
What do you consider "native"? The kernel does not understand Win32 at all -- all Win32 API calls are handled by the runtime and csrss, which eventually boil down to NT API calls. But you will never have Windows running without the Win32 subsystem.
There also exist OS/2 and POSIX subsystems for Windows as well. I do not believe that they are in common use.
If you're familiar with UNIX, here's a rough analogy: is syslog(3) a native API?
POSIX mandates its existence. It is likely implemented by the libc runtime library as "connect to a socket/pipe and send a message". This cannot work unless the syslogd daemon is running. A syslogd daemon is started by the init scripts.
It's not a perfect analogy; many applications do not depend on syslog(3), and it is usually possible to stop and restart the syslogd daemon without detrimental effects on the system's operation (much unlike csrss.exe).
ephemient
2009-05-07 14:44:41
Thanks, all very educational to me. The question resulted from my confusion on what is the relationship between .NET and "old" win32 API. I am considering writing new applications using c++ and win32 and want to make sure I am not making use of an API that is supported just for backwards compatibility.
2009-05-07 14:56:07
Microsoft's .NET implementation sits atop Win32. In theory this could change; however, I doubt it will ever happen. Even if it does, Microsoft will continue to support the Win32 API forever -- even the Win16 API still works, thanks to wow32.dll (Windows-on-Windows-32).
ephemient
2009-05-07 16:11:26
@ephemient: I've been starting to question that: - it appears they believe the future is in .Net and CLR. - VS2010 will be WPF and MEF based. - research in projects like singularity ( http://research.microsoft.com/en-us/projects/singularity/ ). - Win7 has XP Mode. At what point does Win32 become a legacy mode that is supported the way Mac OS X supported Classic when OS X came out?
sean e
2009-05-14 05:32:05