6
votes

At Microsoft BUILD conference, I saw this figure.

I'm wondering whether the position of Win32 is correct or not. What is the role and position of Win32 API in modern Windows architecture?

My concept of Win32 API is a sort of assembly of all modern Windows architecture. Win32 API (or DDK) bridges "Windows Kernel Services" to the other technologies.

I thought that Internet Explorer/.NET/Silverlight are all build upon Win32 API. Even if a fancy new Metro Apps, I conjecture that Win32 is at the bottom place. However, this figure defies my knowledge.

As you can see, IE/.NET/SL/Metro are sitting horizontally with Win32.

Questions:

  1. Does this figure necessarily mean that Win32 is not the framework of all other modern technologies?
  2. What is "Windows Kernel Services"? How programmers can access them? Isn't it through Win32 API and DDK?

Windows 8 Platform

2

2 Answers

9
votes

The diagram is wrong.

While there were originally other subsystems (e.g. POSIX) which accessed ntdll.dll (the "Kernel Services" gateway) without going through Win32 (kernel32.dll, user32.dll) these are all now defunct.

All modern application frameworks for Windows are built on Win32. The other subsytems are no longer supported. In some cases (drivers, and boot-time system utilities such as chkdsk) code is written directly against the native API, but these scenarios are very rare.

I'm not very familiar with WinRT, but I think Win32 fits underneath it as well (or it may use a combination of Win32 and direct ntdll.dll services).

According to Sasha Goldshtein,

Next, a C++ Metro application will still load Win32 DLLs such as kernel32 and ntdll. Moreover, the WinRT APIs call into the Win32 DLLs – so they are not a replacement but rather a wrapper, an API flavor, on top of Win32. (Historical note: Windows used to have a feature called “environment subsystems”, which can be roughly described as API flavors. WinRT is not an environment subsystem – it is a library on top of the Win32 environment subsystem.)

0
votes

The diagram is (presumably) correct, but only for Windows 8. Windows 8 has a significantly different architecture from previous versions.

I believe applications can make requests directly to the kernel, but the interface is mostly undocumented. Device drivers use the kernel directly.