| Date: | September 30, 2005 / year-entry #286 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050930-10/?p=33983 |
| Comments: | 39 |
| Summary: | Back in 1995, I was participating in a chat room on MSN on the subject of device driver development. One of the people in the chat room asked, "Can I write a device driver in Visual Basic?" I replied, "Windows 95 device drivers are typically written in low-level languages such as C or even assembly language."... |
Back in 1995, I was participating in a chat room on MSN on the subject of device driver development. One of the people in the chat room asked, "Can I write a device driver in Visual Basic?" I replied, "Windows 95 device drivers are typically written in low-level languages such as C or even assembly language." Undaunted, the person clarified: "But I have Visual Basic Professional." |
Comments (39)
Comments are closed. |
I have Windows XP <b>Professional</b>. Can I write device drivers too?
Military Intelligence
Jumbo Shrimp
Visual Basic Professional
As a former VB programmer, I bet there is a clever way to do this. However, for the maintainer out there, I hope he didn’t succeed.
It’s a funny story but you didn’t answer his question.
Can it be done or not? And why not?
( I’m a C++ programmer btw, don’t know too much about VB )
If this was ’95, the chatter probably had VB 6 or lesser, and while you could make calls to the 16/32-bit API, VB didn’t support callbacks. So even with a bit of devilry I don’t see how you could set up your driver entry points (much less "compile" to a DLL).
It would make for a pretty neat hack, though, maybe on par with writing a book without the letter e or something.
The question was about writing device drivers, not applications. Device drivers are written to a different API from Win32 and must observe very complex requirements. Plus you’d have to port the VB runtime library to kernel mode – the work required to do that would be greater than just writing the driver in C to begin with.
The VB runtime would drag a whole raft of dependencies along, wouldn’t it? Imagine having to have audio support configured in order to use your VB-based mouse driver, or somesuch.
Same happens with Delphi over and over again. A friend of mine once wrote this short note, that tells, why it doesn’t work: http://www.luckie-online.de/Developer/Artikel/GrenzenDelphi.shtml
"So this is not possible with pure VB code?"
It depends on what you mean by "pure VB code". Are you referring to VB the language or VB the runtime environment?
Isn’t Microsoft now encouriging people to write drivers in C++, and even CLR? (Please, correct me if I’m wrong; I don’t generally follow device-driver trends.)
Michael:
There’s no reason that a driver couldn’t be written in Delphi for NT. For ‘9x, you’d be correct that you wouldn’t be able to do it, but for NT it would be possible using a modified RTL.
You probably could write one in VB6. I wrote a mouse/cursor controller in QBasic (on Win95, for an intro to computers project) using peek and poke :) I know that isn’t a device driver (it just read from the driver’s place in memory), but if you had access to memory directly, its not impossible(at least on non-NT systems), right?
A while ago I saw an ad on a web page for an OCX that allowed VB programs to handle IRQs, I/O and other driver-type things. I don’t think I could sleep for a week after seeing that :P
I think it would be easier for me to write a VB app that emitted the assembly for a driver than it would be for me to try and get the VB runtime environment into kernel mode.
That said, the year and change I spent working on a VB project (which integrated VB, STL, MFC, QT, and straight Win32 into one application) has still left me waking up at night. Perhaps I’m just not the right person for the job.
Drivers don’t have to be in kernel mode, at least on Linux. All you need is to be able to read/write an I/O port. I bet this is possible on Windows too.
Of course, only very simple drivers.
Let’s see if I learned something from my OS book. I think Windows drivers have to be in kernel mode, as opposed to Linux, where they run in user-mode. Even the windowing subsystem runs in kernel mode, which is the base of some (valid) rants from the Linux boys.
Now, having (read and write) access to memory doesn’t do the trick by itself, since the driver still need to manage other (privileged) system resources like the IRQ table (in order to reserve an interrupt for himself), I/O ranges, etc.
So, even if the developer use an OCX like the one described by Justed a few comments ago, he still needs to compille his driver’s code, the OCX and the VB-runtime to a DLL that can run in kernel-mode. Just like Raymond said, all that work is way harder than writting the driver in C in the first place.
VB can call Windows API functions, so you probably *could* do it from VB, at least for a relatively simple driver. It’d probably be harder than doing it in C, though.
I think I know the OCX Justin is talking about. The name escapes me: it’s been about eight years, and the things the OCX gave you access to were scary.
And I didn’t think win95 drivers ran in kernel mode — I thought the distinction only existed in NT-based OSes (NT/2k/XP).
Eric: Not all Linux drivers run in user mode. (In fact, the low-level drivers for almost all devices don’t. However, the low-level driver for the video card, for instance, is distinct from the actual GUI rendering code. The rendering code runs in usermode, the driver runs in kernel mode. Similarly, the WPA/WPA2 supplicant runs in user mode, while the wireless card driver runs in kernel mode, but both are required before a WPA or WPA2 network may be used.)
If you want almost all drivers to be in user mode, try a microkernel OS. I’ve heard that the Hurd is a microkernel. I know that Minix is.
microbe’s point was that not all drivers *have* to run in kernel mode. If all they need to do is make I/O requests to ports (memory-mapped I/O won’t work, though, so I think this precludes most PCI devices), then they can run in usermode, if they’re run by root. Hence the "only very simple drivers" comment.
Michael Puff wrote:
> A friend of mine once wrote this short
> note that tells why it doesn’t work:
> http://www.luckie-online.de/Developer/Artikel/GrenzenDelphi.shtml
/Now/ I understand !!
"even if someone makes itself the work the DEVICE Driver kit (DDK) into Delphi LANGUAGE ‘translates’, it will determine, that does not have selbige language some features, those is extensively used there"!
One of the few sentences perfectly translated by google was at the end: "I hope that was clear enough." !!
:-)
Re. microkernels, check out L4Ka. Even the memory manager is in userspace. (That still doesn’t mean drivers can have the same dependencies as applications, which is the key problem here.)
@Willi:
"There’s no reason that a driver couldn’t be written in Delphi for NT. For ‘9x, you’d be correct that you wouldn’t be able to do it, but for NT it would be possible using a modified RTL."
It needs more than just modify the RTL. The resulting PE File must be modified as well, because the one genarted by Delphi wouldn’t be accepted by the kernel.
But you are right, Nico managed it for NT but he had tu surrender when Windows 2000 was released. ;)
For the others a short translation:
Delphi was developed and optimized for writing GUI applications for Windows. You can’t tell the Dephi Compiler to compile a PE file that will be accepted by the kernel.
The C headerfiles use special language features you can’t port to Delphi that easy. For example Microsoft specific calling conventions like fastcall and so on. Therfore there are no Units available for Delphi and you can start from the scratch with assembler, because ther is noch Memory Manager, no Compiler Magic, there’s nothing you can rely on.
It might work but you will come to the conclusen, that it needs a lot of work and a HexEditor, but it doesn’t make sense.
GregF, what kind of driver did you write ?! Because there is no VB compiler that generates a sys and like Raymond said, the VB API doesn’t work in kernel mode… Unless you’re talking about a non-kernel driver ?
For C++ in KMD simply write a base class to have new and delete who are kernel friendly. You cannot use global objects because there is no atexit() call. WDK should change this.
There are toolkits that allow you to write Windows "drivers" in VB. They’re user-mode drivers, though.
http://www.jungo.com/windriver_windows.html
Basically, they have a "universal" driver that runs in kernel mode. Your user-mode driver is basically a DLL which calls the kernel-mode component of WinDriver. The kernel-mode part does all of the I/O on your behalf.
The man was simply ahead of his time :)
With the advent of the UMDF (http://www.microsoft.com/whdc/driver/wdf/default.mspx), writing drivers in Visual Basic .Net is not only supported, it’s encouraged!
You *can* write drivers in VB (I have actually done this once) but its not really a good plan. You CAN write perfectly functional Services, though, even though Microsoft don’t recommend this, it works just fine if you have taken the time to understand what a good well-behaved Service should do — and NOT do.
It used to be perfectly normal to use little chunks of Assembler in QBASIC for hardware control. Ah, yes, the good old days.
Reminds me of someone I was talking to at a conference or something, who said that WINS does not work. "I put a WINS server on the same subnet as my workstations, and they still couldn’t find any servers", he said. I said, "did you point the workstations to the WINS server?". He said, "what?".
No mention of kernel level VB hacking can pass without a mention of egg troll’s classic usenet post:
http://tinyurl.com/8qfxt
400 biters – exceptional!
I’m surprised nobody but ‘Andrew W’ has made a comment about why you can’t write in high level languages.
It is because the higher the level of the language, the more it does stuff behind the scenes. Which actually means that it executes code and accesses memory. Kernel drivers have a very specific mandate of not executing, or touching memory locations under certain circumstances (e.g. not touching paged memory while running > DIRQL).
I remember seeing a hack where a VB app was made to be multithreaded (by calling raw Win32 methods). It was interesting to see a development tool like that be pushed beyond its limit. But much more than the VB runtime, I think the actual compiler of VB would not be safe to even write the most trivial of a device driver.
Especially given that the language does not have constructs such as pragma for flagging the executable with paging information – which C++ does have, and allows it to be remotely suitable for kernel programming.
Of course, I’m sure you could really hack this thing, and flag the entire driver to reside in non-paged memory. But let’s not even go there.
Dan said, "VB didn’t support callbacks. So even with a bit of devilry I don’t see how you could set up your driver entry points (much less "compile" to a DLL)."
Actually VB did support call backs, just not officially. You could use the three undocumented VarPtr, StrPtr, and ObjPtr, which you would have to use anyway to interact directly with a lot of the Windows API.
I still wouldn’t recommend it though.
Dan McCarty,
VB 5 and 6 did in fact support callbacks, using the AddressOf operator.
ATI’s radeon drivers requires .net framework.
Tuesday, October 04, 2005 9:49 AM by Nick Nack
> ATI’s radeon drivers requires .net framework.
For display of property sheets and maybe the icon and menus in the notification area? Or for the driver itself?
To answer a question I’ve heard a couple times now, WCF is almost entirely written in C#.&nbsp; And,…