Win32 Implementations: a Comparative Look
Total Page：16
File Type：pdf, Size：1020Kb
Chapter 3 Win32 Implementations: A Comparative Look IN THIS CHAPTER ^ ^ ^ + Comparing and contrasting implementation of the Win32 API in Windows NT and Windows 95 + Aspects of implementation in both Windows NT and Windows 95 EACH OPERATING SYSTEM provides set f serviceo s applicationn sa referred- s a o t programming interface (API) - to developers in some form or another. The develop- ers write software applications using this API. For example, DOS provides this in- terface in the form of the famous INT 21h interface. Microsoft's newer 32-bit operating systems, such as Windows 95 and Windows NT, provide the interface in . API 2 Win3 e th f o m for e th Presently, there are four Win32 API implementations available from Microsoft: 8 95/9 s Window + ^ ^ + Window T ^sN - ^ ^^^^ ^^^ ^^^ ^^ ^^^^ ^^ ^- ^^^^^^^^^^ + Win32s ^ ^^ ^ ^ ^^^ + Windows CE Of these, Win32s is very limited due to bugs and the restrictions of the underly- ing operating system. Presently, Win32 API implementations on Windows 95/98 and Windows NT are very popular among developers. Windows CE is meant for palmtop computers. The Win32 API was first implemented on the Windows NT op- erating system. Later, the same API was made available in Windows 95. Ideally, an application written using the standard Win32 API should work on any operating system that supports the Win32 API implementation. (However, this is not neces- sarily true due to the differences between the implementations.) The Win32 API should hide all the details of the underlying implementations and provide a consis- tent view to the outside world. 23 24 Part 1: Essentials In this chapter, we focus on the differences between the implementations of the e b d shoul u yo , developers s A . 95 s Window d an T N s Window r unde I AP 2 Win3 f o h bot n o n ru n ca t tha s application p develo u yo e whil s difference e thes f o e awar these operating systems. Win32 API Implementation on Windows 95 The Win32 API is provided in the form of the famous trio of the KERNEL32, e thes , cases t mos n i , However DLLs). ( s librarie k lin c dynami 2 GDI3 d an , USER32 DLLs are just wrappers that use generic thunking to call the 16-bit functions. Generic thunking is a way of calling 16-bit functions from a 32-bit applica- tion. (More on thunking later in this chapter.) - in , Hence . compatibility d backwar s wa 5 9 s Window r fo l goa n desig r majo e Th stead of porting all the 16-bit functions to 32-bit, Microsoft decided to reuse the existing 16-bit code (from the Windows 3.x operating system) by wrapping it in 32- bit code. This 32-bit code would in turn call the 16-bit functions. This was a good approach because the tried — and — true 16-bit code was already running on millions of machines all over the world. In this Win32 API implementation, most of the o t down s thunk 2 USER3 , KRNL386 o t n dow k thun 2 KERNEL3 m fro s function . GDI.EXE o t n dow s thunk 2 GDI3 d an , USER.EXE Win32 API implementation on Windows NT On Windows NT also, the Win32 API is provided in the form of the famous trio of e don s i n implementatio s thi , However . DLLs 2 GDI3 d an , USER32 , KERNEL32 e th completely from scratch without using any existing 16-bit code, so it is purely a 32-bit implementation of Win32 API. Even 16-bit applications end up calling this . this e achiev o t g thunkin l universa s use m subsyste t 16-bi s NT' s Window . API t 2-bi 3 Chapter 3: Win32 Implementations: A Comparative Look 25 - applica t 16-bi m fro s function t 32-bi g callin f o y wa a s i thunking Universal ) chapter. s thi n i r late g thunkin n o e (Mor . tions - appli t 16-bi t suppor o t d use e ar h whic , GDI.EXE d an , USER.EXE , KRNL386.EXE s (Window W WO e th h throug 2 GDI3 d an , USER32 , KERNEL32 o t p u k thun , cations on Windows) layer. Most of the functions provided by KERNEL32.DLL call one or e ar s service m syste e nativ e Th . work l actua e th o d o t s service m syste e nativ e mor . NTDLL.DLL d calle L DL a h throug e availabl . 6 r Chapte n i d discusse e ar s service m syste e thes l Al As far as USER32 and GDI32 are concerned, the implementation differs in NT m subsyste e separat a , 3.51 T N s Window r Unde . versions r late d an 1 3.5 s version process implements the USER32 and GDI32 calls. The DLLs USER32 and GDI32 contain stubs, which pass the function parameters to the Win32 subsystem - ap t clien e th between n communicatio e Th . back s result e th t ge d an ) (CSRSS.EXE - fa l cal e procedur l loca e th g usin y b d achieve s i m subsyste 2 Win3 e th d an n plicatio cility provided by the NT executive. mechanism ) (LPC l cal e procedur l loca e th f o s detail e th s cover 8 r Chapte Under Windows NT 4.0 and Windows 2000, the USER32 GDI32 calls the system d an 2 USER3 . WIN32K.SYS d calle r drive e devic e kernel-mod a y b d provide s service , Hence . interrupt h 2E e th g usin s service m syste e thes l cal t tha s stub n contai 2 GDI3 most of the functionality of the Win32 Subsystem process (CSRSS.EXE) is taken over 0 4. T N n i s exist l stil s proces S CSRS e Th . (WIN32K.SYS) r drive e kernel-mod e th y b . I/O e Consol g supportin y mainl o t d limite s i e rol s it , however — 0 200 s Window d an 26 Part 1: Essentials It is interesting to note that the Win32 API completely hides NTDLL.DLL from - ulti I AP 2 Win3 e th y b d provide s function e th f o t mos , Actually . developer e th mately call one or more system services. This system service layer is very powerful - func I AP 2 Win3 t equivalen e hav t no o d t tha s function s contain s time y man d an . implicitly L DL s thi o t k lin s utilitie t Ki e Resourc T N s Window e th f o t Mos . tions Win32 Implementation Differences Now we will consider a few aspects of the Win32 API implementation on Windows - so s thi g usin m progra s developer y wa e th t affec t migh t tha 5 9 s Window d an T N called standard Win32 API. Address Space Both Windows 95 and Windows NT deal with flat, 32-bit linear addresses that give e th s a o t d referre r (hereafte B 2G r uppe e th , this f O . space s addres l virtua f o B 4G shared address space) is reserved for operating system use, and the lower 2GB (hereafter referred to as the private address space) is used by the running process. e th h Althoug . process h eac r fo t differen s i s proces h eac f o e spac s addres e privat e Th virtual addresses in the private address space of all processes is the same, they may point to a different physical page. The addresses in the shared address space of all the processes point to the same physical page. Under Windows 95/98, the operating system DLLs, such as KERNEL32, USER32, s DLL e thes T N s Window n i s wherea , space s addres d share e th n i e resid , GDI32 d an are loaded in the process's private address space. Hence, under Windows 95/98, it is . application r anothe f o g workin e th h wit e interfer o t n applicatio e on r fo e possibl For example, one application can accidentally overwrite memory areas occupied by . processes r othe e th l al f o g workin e th t affec d an s DLL e thes Although the shared address space is protected at the page table level, a kernel-mode component (for example, a VXD) is able to write at any location . space s addres B 4G n i In addition, under Windows 95/98, it is possible to load a dynamic link library in the shared address space. These DLLs will have the same problem described pre- viously if the DLL is used by multiple applications in the system. Windows NT loads all the system DLLs, such as KERNEL32, USER32, and GDI32, in the private address space. As a result, it is never possible for one application to __________Chapter 3: Win32 Implementations: A Comparative Look____27 f I . so o d o t g intendin t withou m syste e th n i s application r othe e th h wit e interfer - applica t tha y onl t affec l wil t i , DLLs e thes s overwrite y accidentall n applicatio e on .