But I have Visual Basic Professional


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)
  1. Matt says:

    I have Windows XP <b>Professional</b>. Can I write device drivers too?

  2. Dave says:

    Military Intelligence

    Jumbo Shrimp

    Visual Basic Professional

  3. Miles Archer says:

    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.

  4. KristofU says:

    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 )

  5. Dan McCarty says:

    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.

  6. oldnewthing says:

    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.

  7. spork says:

    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.

  8. BTX says:

    >Plus you’d have to port the VB runtime library to kernel mode

    so this is not possible with pure VB code?

  9. Michael Puff says:

    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

  10. oldnewthing says:

    "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?

  11. theorbtwo says:

    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.)

  12. Edge says:

    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.

  13. Rick Scott says:

    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?

  14. Justin Olbrantz (Quantam) says:

    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

  15. 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.

  16. microbe says:

    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.

  17. Eric says:

    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.

  18. pcooper says:

    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.

  19. Merle says:

    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).

  20. Bryan says:

    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.

  21. TC says:

    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." !!

    :-)

  22. josh says:

    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.)

  23. Brian says:

    It would make for a pretty neat hack, though,

    > maybe on par with writing a book without the

    > letter e or something.

    I don’t know if you were purposefully alluding to this, but someone did in fact write a book of over 50,000 words without using the letter ‘e’. http://spinelessbooks.com/gadsby/index.html

    > Isn’t Microsoft now encouriging people

    > to write drivers in C++, and even CLR?

    I don’t see anything wrong with writing device drivers in C++. You would probably have to stay away from STL things that require support from whatever windows calls libstdc++, but you could certainly take advantage of some OO features.

    I can’t see a CLR device driver ever existing though. As someone said already, it would require the runtime VM being able to run in the kernel and that would be a SIGNIFICANT undertaking.

    > 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?

    The fact that you were doing this in DOS, which has no concept of usermode/kernel mode (or memory protection, privilege, etc) is why it was simple to do such a thing.

    > 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

    I’m not familiar with this at all, but I would imagine that this works by having a surrogate / stub kernelmode driver written in C that just presents an interface to the hardware that the VB code can call.

  24. Andrew W says:

    > Isn’t Microsoft now encouriging people

    > > to write drivers in C++, and even CLR?

    > I don’t see anything wrong with writing device drivers in C++. You would probably have to stay

    > away from STL things that require support from whatever windows calls libstdc++, but you could

    > certainly take advantage of some OO features.

    Actually, MS throws up some big caveats for developing drivers in C++. It mostly has to do w/ C++ generating code "behind the scenes" (e.g, array constructors and such) and the developer not being able to explicitly control if this code goes into pageable or non-pageable memory. A couple of years ago MS produced a white paper about it for devcon.

    We develop our drivers in C++ and have run into this sort of issue before. There’s places in our driver code with big warning comments like "don’t move this seemingly-safe-to-page method to pageable memory because it’s keeping intrinsic function xx in nonpageable memory!". egads. All told, though, we prefer dealing w/ this sort of thing to coding in C.

  25. Luckie says:

    @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.

  26. autist0r says:

    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.

  27. msemack says:

    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.

  28. Ken says:

    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!

  29. GregF says:

    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.

  30. boxmonkey says:

    I don’t know if you were purposefully alluding

    >to this, but someone did in fact write a book of

    >over 50,000 words without using the letter ‘e’.

    >http://spinelessbooks.com/gadsby/index.html

    If this sort of thing interests you, you should check out Ella Minnow Pea: A Progressively Lipogrammatic Epistolary Fable (http://www.amazon.com/exec/obidos/tg/detail/-/0967370167/)

  31. James Risto says:

    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?".

  32. JamesW says:

    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!

  33. memet says:

    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.

  34. kbiel says:

    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.

  35. Matt says:

    Dan McCarty,

    VB 5 and 6 did in fact support callbacks, using the AddressOf operator.

  36. Nick Nack says:

    ATI’s radeon drivers requires .net framework.

  37. Norman Diamond says:

    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?

  38. Picky says:

    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?

    Just for the control panel. Not the driver itself.

  39. To answer a question I’ve heard a couple times now, WCF is almost entirely written in C#.&amp;nbsp; And,…

Comments are closed.