Author Topic: Compiling an OS/2 Driver  (Read 1945 times)

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 264
  • -Receive: 50
  • Posts: 1755
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Compiling an OS/2 Driver
« on: December 27, 2017, 03:12:33 pm »
Hi

I want to make some little experiment to learn to compile a simple driver on OS/2, and if something works write some little/quick thing for EDM/2.

I have zero experience on this area (just like when I compiled some PM samples). I'm just interested on the process of compiling the driver, since developing a driver is a lot more complex.

Do you recommend any drivers that is very straight forward to compile, just to try to understand the procedure ?

I have the IBM Device Driver Kit (Dated on 2004), so I can also use the tools and samples from it. And I also have some driver source code samples on the OS2World github.

Regards
« Last Edit: December 27, 2017, 03:20:16 pm by Martin Iturbide »


Martin Iturbide
OS2World NewsMaster
... just share the dream.

Eike

  • Newbie
  • *
  • Thank You
  • -Given: 2
  • -Receive: 2
  • Posts: 14
    • View Profile
Re: Compiling an OS/2 Driver
« Reply #1 on: December 27, 2017, 05:48:45 pm »

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 264
  • -Receive: 50
  • Posts: 1755
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Compiling an OS/2 Driver
« Reply #2 on: December 27, 2017, 07:06:29 pm »
Hi Eike.

I noticed that articles but are more focused on the development of the driver instead on just the compiling process. I'm seeking advice on which can be an easy sample to compile a driver for newbies.

Regards
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Eike

  • Newbie
  • *
  • Thank You
  • -Given: 2
  • -Receive: 2
  • Posts: 14
    • View Profile
Re: Compiling an OS/2 Driver
« Reply #3 on: December 27, 2017, 08:07:02 pm »
Handouts for a session from warpstock europe in bochum 1999.
HTML and sources.

Have fun. ;)

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 264
  • -Receive: 50
  • Posts: 1755
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Compiling an OS/2 Driver
« Reply #4 on: December 27, 2017, 09:22:16 pm »
Thank you Eike.

I didn't known that material existed. I will check it out and see if I can compile that sample.

Regards
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Andreas Kohl

  • Full Member
  • ***
  • Thank You
  • -Given: 6
  • -Receive: 10
  • Posts: 246
    • View Profile
    • warpserver.de
Re: Compiling an OS/2 Driver
« Reply #5 on: December 27, 2017, 11:41:37 pm »
It depends on which drivers from DDK should be built. For first timers I would recommend to set up a virtual machine with Warp 4. Two 2 GB partitions with FAT file system is a good start for the system installation. Then simply install C/2 or MS C 6.0. Now you can follow the route from The Developer Connection Device Driver Kit for OS/2 CD-ROM. The file USEDDK.INF from directory \DDKX86\BOOK includes a short overview and step-by-step instructions for each samples.

For drivers that only use 16-bit tools it can be easier to use Windows 2000 or DOS - at least sometimes.

Roderick Klein

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 8
  • Posts: 190
    • View Profile

Andy Willis

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 9
  • Posts: 164
    • View Profile
Re: Compiling an OS/2 Driver
« Reply #7 on: December 30, 2017, 04:19:57 am »
You put my HLT driver up on github... I had never written a driver so I used the HelloWorld driver to build it.
http://www.edm2.com/index.php/OS/2_Device_Drivers_for_Dummies_-_The_Beginning

Lars

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 24
  • Posts: 185
    • View Profile
Re: Compiling an OS/2 Driver
« Reply #8 on: December 30, 2017, 04:57:35 pm »
Hi Martin,

my gut feeling is that you actually want to do more than just compiling a driver. My feeling is that you want to enable others to actually write a device driver, maybe you are thinking about people capable of writing a device driver for Windows but who have no clue about OS/2.

That said, I'd go with Roderick's hint. Have a look at David's driver library (for 16-bit and also for 32-bit).
Don't use the DDK for these purposes:
1) the DDK is a mess. It is unstructured, things are difficult to find.
2) the DDK mostly relies on the old 16-bit Microsoft C compiler and/or masm.exe, an extremly old Microsoft assembler that can only deal with nothing better than an 386 CPU.
2) I do not recommend to take any of the DDK code as being correct or suitable for SMP systems. Fact is, many of the DDK drivers are VERY old. You cannot rely on that code to work on any modern system, SMP systems in particular.

The only thing that is really necessary from the DDK are the header files as they basically define all of the internal interfaces/structures (as far as things have been made public to begin with).

Unfortunately, even with this info there are things about OS/2 that are really special:
1) a 16-bit driver is, well, 16-bit. For example, if you want to read a 32-bit HW register there is usually a HW requirement to read it as full 32-bits. That will require a minimum of assembler code because you will need to use memory instructions that will move a full 32-bit of data. A 16-bit compiler won't generate these instructions. There are more of these issues.

2) You will need to fumble around with virtual addresses: a selector and an offset. That is what most programmers nowadays will have forgotten about. Then there is the additional difficulty to hop back and forth between virtual addresses, linear addresses (a 32-bit offset in a flat 4 GB address space) and physical addresses. The reason for this most likely will be that virtual addresses can only address a "chunk" of memory <= 64 kBytes. More often than not this is not sufficient. For example, USBEHCD.SYS needs to address 128 kBytes of internal management data structures to make isochronous transfers work (something that you need to make USBAUDIO.SYS work, for example).


Lars

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 264
  • -Receive: 50
  • Posts: 1755
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Compiling an OS/2 Driver
« Reply #9 on: December 31, 2017, 04:57:51 pm »
Thanks Lars. Your feeling is right, but I will need to try it to see if I can accomplish something.

I found your post on the other thread interesting.
Here you go with 2 drivers that I have written:

http://hobbes.nmsu.edu/download/pub/os2/system/drivers/misc/mchnchk2.wpi
http://hobbes.nmsu.edu/download/pub/os2/system/drivers/misc/syscall.wpi

The WPIs contain all the source code. While they might not serve a practical purpose for most people, they are a live example of what can be done in a device driver.

And here is another one (including source code).
http://hobbes.nmsu.edu/download/pub/os2/system/drivers/misc/os2pcat3.wpi

The latter is a PSD. Hopefully the source code contains enough comments for people to understand :-)
I will check on that too.

Let me see how my testing goes so I can elaborate more specific question and the problems that may arise.

Thanks for help.

Regards
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Roderick Klein

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 8
  • Posts: 190
    • View Profile
Re: Compiling an OS/2 Driver
« Reply #10 on: December 31, 2017, 06:27:32 pm »
Also forgot about the Microsoft C compiler. Its better to use the Open Watcom compiler. It may not be suitable to compile Mozilla with as that requires GCC. The Open Watcom compiler seems to be much stricter in grabbing any errors in your code then Visual Age or the Microsoft 6 C compiler that is included in the DDK. Also the Open Watcom code I understands generates better optimized code.

If you do want to write an article recommending how to write drivers.

* Include some decent comment in the code.

* Any kind of source control system is your friend. Having worked at Mensys the fact  drivers where *frequently* checked in made it *easier* to find why a certain version of a driver would suddenly blow up. Its then easier to locate the code that was modified.

As I have said so often, finding the cause of a kernel dump can be extremely time consuming.  That is why the above conditions may cost some time when you work on you project. But you will be gladd you did it when you run into a problem.

Roderick

Lars

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 24
  • Posts: 185
    • View Profile
Re: Compiling an OS/2 Driver
« Reply #11 on: January 01, 2018, 12:53:19 pm »
Hm,

unfortunately, Watcom produces debug info that no IBM supplied debugger can use, including ICSDEBUG.EXE (the debugger that comes with Visual Age) and ICAT (the remote source code debugger that can debug either via serial port or via UDP). This is also true if Watcom creates debug info in CODEVIEW format (looks like the CODEVIEW variant that Watcom generates is not understood by the IBM debuggers).

Just for that reason it can occasionally be better to still use Microsoft C 6.0 compiler as that one produces a CODEVIEW format that the IBM debuggers can understand.
If you don't care about source code debugging then of course this is not relevant.

Where that is possible I tend to create 2 makefiles: one for compiling/linking via Watcom and one for compiling/linking via VAC. Then I can develop using VAC and if everything works ok I can switch over to Watcom for the final build.

Lars


Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 264
  • -Receive: 50
  • Posts: 1755
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Compiling an OS/2 Driver
« Reply #12 on: January 03, 2018, 03:36:37 am »
Hi.

I'm starting a little bit slow to compile the driver. I'm starting with the driver1.zip example. It is a little bit old but I wanted to try it.
I installed "os2tk45" with all the packages so "os2.h" and "os2def.h" are from there.

I'm getting this error when I run "nmake".

If I have the "startup.obj" already generated I get his message:

Code: [Select]
Microsoft (R) Program Maintenance Utility   Version 1.13
Copyright (c) Microsoft Corp 1988-91. All rights reserved.

        masm -Mx -e -t -l -N startup;
 Assembling: startup.asm
        cl -c -Asnw -Gs -G2 -Zl -Zp -Ox -Fadriver1.cod driver1.c
Microsoft (R) C Optimizing Compiler Version 6.00A.04
Copyright (c) Microsoft Corp 1984-1990. All rights reserved.

driver1.c
C:/usr/include/os2tk45\os2def.h(99) : error C2054: expected '(' to follow '_Seg1
6'
C:/usr/include/os2tk45\os2def.h(99) : error C2061: syntax error : identifier 'PU
CHAR16'
NMAKE : fatal error U1077: 'C:\OS2\CMD.EXE' : return code '2'
Stop.


« Last Edit: January 03, 2018, 03:47:03 am by Martin Iturbide »
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 93
  • Posts: 1216
    • View Profile
Re: Compiling an OS/2 Driver
« Reply #13 on: January 03, 2018, 04:42:39 am »
Using too new of a toolkit? Looking at my DDK\base\h directory, that line is guarded, eg
Code: [Select]
   #ifdef __IBMC__
      typedef UCHAR     * _Seg16 PUCHAR16;
      typedef CHAR      * _Seg16 PCHAR16;
   #endif
along with a lot of other stuff that is also guarded. I'd guess you should be using the DDK headers. Hopefully someone more knowledgeable can chime in.
Edit:
Looking at env.cmd, it looks like I'm correct, you need the toolkit included with the DDK.
« Last Edit: January 03, 2018, 04:45:54 am by Dave Yeo »

Lars

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 24
  • Posts: 185
    • View Profile
Re: Compiling an OS/2 Driver
« Reply #14 on: January 03, 2018, 10:01:22 am »
If you compile with a 16-bit compiler (which cl.exe is), make sure you include the DDK header file directories before you include the TOOLKIT directories.
In fact, you will very likely not need to include the TOOLKIT header files at all if you include the DDK header files.

Be absolutely sure that you reset/delete the INCLUDE and LIB environment variables before you run the makefile and that you properly define the includes and libraries via the proper compiler and linker switches/directives. I have been caught by the problem of including the wrong header and library files more than once.

Lars