VXD et Service
Résolu
cs_grandvizir
Messages postés
1106
Date d'inscription
samedi 8 novembre 2003
Statut
Membre
Dernière intervention
3 septembre 2006
-
17 août 2005 à 20:12
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 19 août 2005 à 13:44
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 19 août 2005 à 13:44
5 réponses
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
18 août 2005 à 10:20
18 août 2005 à 10:20
Mais il faudrait réécrire ici des bouquins entiers qui traitent ce sujet, impensable.
Extrait de Walter Oney:
To allow multiple applications to share physical hardware, Microsoft introduced the concept of a virtual device driver, whose broad purpose is to “virtualize” a hardware device. Such drivers were generically called VxDs because most of them had filenames fitting the pattern VxD.386, where x indicated the type of device they managed. Using this concept, Windows 3.0 created the appearance of virtual machines outfitted with separate instances of many hardware devices. But the devices themselves continued, in most cases, to be driven by real-mode MS-DOS drivers. A VxD’s role was to mediate application access to hardware by first intercepting the application’s attempts to touch the hardware and briefly switching the processor to a sort of real mode called virtual 8086 mode to run the MS-DOS driver.
Not to put too fine a face on it, mode switching to run real-mode drivers was a hack whose only virtue was that it allowed for a reasonably smooth growth in the hardware platform and operating system. Windows 3.0 had many bugs whose root cause was that very feature of the architecture. Microsoft’s answer was to be OS/2, which it was developing in harmony (using a twentieth-century definition of harmony, that is) with IBM.
Microsoft’s version of OS/2 became Windows NT, whose first public release was in the early 1990s, shortly after Windows 3.1. Microsoft built Windows NT from the ground up with the intention of making it a durable and secure platform on which to run Windows. Drivers for Windows NT used a brand-new kernel-mode technology that shared practically nothing with the other two driver technologies then in vogue. Windows NT drivers used the C programming language almost exclusively so that they could be recompiled for new CPU architectures without requiring any source changes.
Another thing happened along about the Windows 3.0 time frame that has an important ramification for us today. Windows 3.0 formally divided the software world into user-mode and kernel-mode programs. User-mode programs include all the applications and games that people buy computers to run, but they are not to be trusted to deal robustly (or even honestly) with hardware or with other programs. Kernel-mode programs include the operating system itself and all the device drivers that people like you and me write. Kernel-mode programs are fully trusted and can touch any system resource they please. Although Windows 3.0 segregated programs by their mode of operation, no version of Windows (not even Windows Me) has actually put memory protection in place to yield a secure system. Security is the province of Windows NT and its successors, which do forbid user-mode programs from seeing or changing the resources managed by the kernel.
Computing power didn’t really advance to the point where an average PC could run Windows NT well until quite recently. Microsoft therefore had to keep the Windows product line alive. Windows 3.0 grew into 3.1, 3.11, and 95. Starting with Windows 95, if you wanted to write a device driver, you would write something called a VxD that was really just a 32-bit protected-mode driver. Also starting with Windows 95, end users could throw away their I/O maps because the new Plug and Play feature of the operating system identified and configured hardware somewhat automatically. As a hardware maker, though, you might have had to write a real-mode driver to keep happy those of your customers who weren’t upgrading from Windows 3.1. Meanwhile, Windows NT grew into 3.5, 4.0. You would have needed a third driver to support these systems, and not much of your programming knowledge would have been portable between projects.
Enough was enough. Microsoft designed a new technology for device drivers, the Windows Driver Model (WDM), and put it into Windows 98 and Windows Me, the successors to Windows 95. They also put this technology into Windows 2000 and Windows XP, the successors to Windows NT 4.0. By the time of Windows Me, MS-DOS was present only by courtesy and there was finally no need for a hardware maker to worry about real-mode device drivers. Because WDM was, at least by original intention, practically the same on all platforms, it became possible to write just one driver.
To summarize, we stand today in the shadow of the original PC architecture and of the first versions of MS-DOS. End users still occasionally have to open the skin of their PCs to install expansion cards, but we use a different and more powerful bus nowadays than we did originally. Plug and Play and the Peripheral Component Interconnect (PCI) bus have largely removed the need for end users to keep track of I/O, memory, and interrupt request usage. There is still a BIOS in place, but its job nowadays is mostly to boot the system and to inform the real operating system (Windows XP or Windows Me) about configuration details discovered along the way. And WDM drivers still have the file extension .SYS, just as the first real-mode drivers did.
Les services ont un statut et un mode de travail particulier:
http://www.msdn.microsoft.com/library/en-us/dllproc/base/services.asp
Un driver est un code qui s'exécutera en kernel mode, il ne s'écrit absolument pas comme un exe.
ciao...
BruNews, MVP VC++
Extrait de Walter Oney:
To allow multiple applications to share physical hardware, Microsoft introduced the concept of a virtual device driver, whose broad purpose is to “virtualize” a hardware device. Such drivers were generically called VxDs because most of them had filenames fitting the pattern VxD.386, where x indicated the type of device they managed. Using this concept, Windows 3.0 created the appearance of virtual machines outfitted with separate instances of many hardware devices. But the devices themselves continued, in most cases, to be driven by real-mode MS-DOS drivers. A VxD’s role was to mediate application access to hardware by first intercepting the application’s attempts to touch the hardware and briefly switching the processor to a sort of real mode called virtual 8086 mode to run the MS-DOS driver.
Not to put too fine a face on it, mode switching to run real-mode drivers was a hack whose only virtue was that it allowed for a reasonably smooth growth in the hardware platform and operating system. Windows 3.0 had many bugs whose root cause was that very feature of the architecture. Microsoft’s answer was to be OS/2, which it was developing in harmony (using a twentieth-century definition of harmony, that is) with IBM.
Microsoft’s version of OS/2 became Windows NT, whose first public release was in the early 1990s, shortly after Windows 3.1. Microsoft built Windows NT from the ground up with the intention of making it a durable and secure platform on which to run Windows. Drivers for Windows NT used a brand-new kernel-mode technology that shared practically nothing with the other two driver technologies then in vogue. Windows NT drivers used the C programming language almost exclusively so that they could be recompiled for new CPU architectures without requiring any source changes.
Another thing happened along about the Windows 3.0 time frame that has an important ramification for us today. Windows 3.0 formally divided the software world into user-mode and kernel-mode programs. User-mode programs include all the applications and games that people buy computers to run, but they are not to be trusted to deal robustly (or even honestly) with hardware or with other programs. Kernel-mode programs include the operating system itself and all the device drivers that people like you and me write. Kernel-mode programs are fully trusted and can touch any system resource they please. Although Windows 3.0 segregated programs by their mode of operation, no version of Windows (not even Windows Me) has actually put memory protection in place to yield a secure system. Security is the province of Windows NT and its successors, which do forbid user-mode programs from seeing or changing the resources managed by the kernel.
Computing power didn’t really advance to the point where an average PC could run Windows NT well until quite recently. Microsoft therefore had to keep the Windows product line alive. Windows 3.0 grew into 3.1, 3.11, and 95. Starting with Windows 95, if you wanted to write a device driver, you would write something called a VxD that was really just a 32-bit protected-mode driver. Also starting with Windows 95, end users could throw away their I/O maps because the new Plug and Play feature of the operating system identified and configured hardware somewhat automatically. As a hardware maker, though, you might have had to write a real-mode driver to keep happy those of your customers who weren’t upgrading from Windows 3.1. Meanwhile, Windows NT grew into 3.5, 4.0. You would have needed a third driver to support these systems, and not much of your programming knowledge would have been portable between projects.
Enough was enough. Microsoft designed a new technology for device drivers, the Windows Driver Model (WDM), and put it into Windows 98 and Windows Me, the successors to Windows 95. They also put this technology into Windows 2000 and Windows XP, the successors to Windows NT 4.0. By the time of Windows Me, MS-DOS was present only by courtesy and there was finally no need for a hardware maker to worry about real-mode device drivers. Because WDM was, at least by original intention, practically the same on all platforms, it became possible to write just one driver.
To summarize, we stand today in the shadow of the original PC architecture and of the first versions of MS-DOS. End users still occasionally have to open the skin of their PCs to install expansion cards, but we use a different and more powerful bus nowadays than we did originally. Plug and Play and the Peripheral Component Interconnect (PCI) bus have largely removed the need for end users to keep track of I/O, memory, and interrupt request usage. There is still a BIOS in place, but its job nowadays is mostly to boot the system and to inform the real operating system (Windows XP or Windows Me) about configuration details discovered along the way. And WDM drivers still have the file extension .SYS, just as the first real-mode drivers did.
Les services ont un statut et un mode de travail particulier:
http://www.msdn.microsoft.com/library/en-us/dllproc/base/services.asp
Un driver est un code qui s'exécutera en kernel mode, il ne s'écrit absolument pas comme un exe.
ciao...
BruNews, MVP VC++
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
17 août 2005 à 21:04
17 août 2005 à 21:04
vxd est un driver pour win9, .sys sur noyaux NT.
ciao...
BruNews, MVP VC++
ciao...
BruNews, MVP VC++
cs_grandvizir
Messages postés
1106
Date d'inscription
samedi 8 novembre 2003
Statut
Membre
Dernière intervention
3 septembre 2006
22
18 août 2005 à 09:44
18 août 2005 à 09:44
Techniquement, c'est pas très précis.
Pourquoi ne pas garder VXD sur XP ?
Pourquoi le nom de SERVICE ?
Pourquoi les services affolent les pare-feux ?
Un SERVICE est-il plus vulnérable qu'un VXD ?
Leur définition ?
Comment se caractérise un noyau NT ? (98 s'en fichait pas mal)
Les .SYS peuvent être des drivers, mais pourquoi n'est-ce pas des exécutables signés MZ~ ?
Merci de me répondre sur ces questions...
===========
ViewVite XP : HTML
Pourquoi ne pas garder VXD sur XP ?
Pourquoi le nom de SERVICE ?
Pourquoi les services affolent les pare-feux ?
Un SERVICE est-il plus vulnérable qu'un VXD ?
Leur définition ?
Comment se caractérise un noyau NT ? (98 s'en fichait pas mal)
Les .SYS peuvent être des drivers, mais pourquoi n'est-ce pas des exécutables signés MZ~ ?
Merci de me répondre sur ces questions...
===========
ViewVite XP : HTML
cs_grandvizir
Messages postés
1106
Date d'inscription
samedi 8 novembre 2003
Statut
Membre
Dernière intervention
3 septembre 2006
22
19 août 2005 à 12:51
19 août 2005 à 12:51
En quoi et comment se programment les drivers en Kernel Mode ?
===========
ViewVite XP : HTML
===========
ViewVite XP : HTML
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
19 août 2005 à 13:44
19 août 2005 à 13:44
En C et il faut installer le DDK.
ciao...
BruNews, MVP VC++
ciao...
BruNews, MVP VC++
