[ros-kernel] How to get started writing ReactOS drivers

Richard Campbell eek2121 at comcast.net
Wed Feb 4 13:18:34 CET 2004


err, wait, your beginning part was misleading, sounds like the guy 
already knew how to write drivers, but would like to write drivers for 
ROS :P

Richard Campbell wrote:

> I have a simple answer:
>
> www.osronline.com
>
>
> Vizzini wrote:
>
>> I just got an e-mail from someone off-list about how to get started
>> writing drivers, and I thought I'd copy my response to this list in case
>> anyone else out there in TV land has the same question.
>>
>> -Vizzini
>>
>> ----------------------------------
>>
>>  
>>
>>> I was wondering, how do you plan to do (or already do) device driver 
>>> development for ReactOS.
>>> I guess using MS DDK is not a very "free" option...
>>>   
>>
>>
>> We have people who use both the DDK and the ReactOS build 
>> environment. In general, the code is almost completely compatible 
>> (with a couple of
>> exceptions, noted below), and the binaries are 100% compatible.  The
>> build systems are not compatible, however, so you do have to either pick
>> one or go out of your way to support both.
>>
>> The DDK method is exactly as it is for normal Windows driver
>> development.  You create a SOURCES file and copy in a Makefile.  Do your
>> coding, run build, and get a .sys file in the end.  This sys file can be
>> copied onto your reactos disk, and once you edit the registry to create
>> the SCM entry (just like windows, too), the driver will load and run. 
>> The other method is using the ReactOS source tree.  The easiest way is
>> to start with a Makefile and .rc file from another driver in the
>> reactos/drivers/ directory.  The whole system runs off of standard GNU
>> make, rather than  using build and/or nmake.  You must use a ReactOS
>> Makefile, though, which collides with the Makefile that build expects
>> from the DDK.  To get around this, you can name your makefile
>> GNUmakefile, so you can have both files in the same directory if you
>> choose to support both build environments.  MinGW make will only look at
>> GNUmakefile, if it exists.
>>
>> In practice, I usually support both, as it's critical to develop and
>> test drivers under Windows 2000/XP/2003, including running under
>> Verifier and running Prefast.  This ensures that if there are any
>> compatibilities between the ReactOS kernel and the Windows kernel, they
>> will be found.
>>
>> One minor legal point - I don't think it's legal to distribute a binary
>> driver built from the Windows DDK for use with ReactOS.  You can
>> distribute the SOURCES and Makefile files, though, and you can build and
>> test with the DDK yourself, so this isn't really an issue.
>>
>> As far as source code compatibility goes, Microsoft's CL.EXE supports
>> some extensions that our compiler (MinGW GCC) doesn't.  In particular,
>> there is no support for SEH constructs, including __try, __except, and
>> __finally.  If you call ProbeForRead(), ProbeForWrite(),
>> MmProbeAndLockPages(), ZwClose(), or anything else that can throw an
>> exception, you have to surround the SEH stuff with
>> #if MSC_VER
>> #endif
>>
>> Inline ASM syntax is different (MS uses Intel syntax, whereas GCC
>> expects AT&T), and include paths are parsed differently (backslash vs
>> forward slash).  File names are case-sensitive on UNIX, of course, as
>> well.  Also, declarations like __stdcall are a little different.  See an
>> example driver for details.  Finally, many (all?) DDK headers use a
>> compiler switch to force the default calling convention to stdcall.  We
>> do not, however, so you have to be careful to actually define any
>> callbacks that need to be stdcall in the proper wya.
>>
>> I have ported a few of my own drivers to build in the native ReactOS
>> environment, and in no case has it taken me more than a few hours. 
>> Our kernel is fairly complete, but generally windows drivers are missing
>> a few imports on ReactOS.  This is where you go from being a driver
>> developer to a kernel developer. ;-)  If you find that some kernel
>> functionality is missing, I would encourage you to dive in and take a
>> shot at coding it up.
>>
>> There is one major caveat to the above:  our kernel does not support PnP
>> or Power Management just yet.  It is being actively worked on, but so
>> far, WDM drivers that expect PnP notifications won't work without some
>> special work on your part.  If PnP is a project you'd like to chip in
>> on, let me know, and I'll set you up with the guys who are working on it
>> now.  I'm sure they'd appreciate the help.
>>
>> What sorts of drivers are you interested in working on?  I like to try
>> to keep a general idea of what is going on in the kernel, so if you do
>> decide to venture out on a project, drop me a note.
>>
>> Best of luck, and don't hesitate to let me know if you have questions or
>> need help.  Also, come by #reactos on irc.freenode.net - there are
>> usually people there (myself included) that can help.
>>
>>
>> _______________________________________________
>> Ros-kernel mailing list
>> Ros-kernel at reactos.com
>> http://reactos.com/mailman/listinfo/ros-kernel
>>
>>  
>>
>
>
> _______________________________________________
> Ros-kernel mailing list
> Ros-kernel at reactos.com
> http://reactos.com/mailman/listinfo/ros-kernel
>




More information about the Ros-kernel mailing list