Linker cannot generate VXD files.

[joncampbell123]

wlink.lnk has a listing to generate Windows VXD files, but it doesn't work.

"format windows vxd" confuses the linker and it generates a NE executable instead of the LE format needed for VXDs.

I tried asking the linker to generate an OS/2 2.x DLL instead to make an LE executable but apparently internal relocations are not supported for the LE format, even though VXDs are LE format and use internal relocations all the time. In fact, many .386 and .VXD files I examined have relocations for members of the DDB structure pointed to by entry point #1 of the LE format.

I am trying to develop in the DOSLIB project a working Windows 95 mouse driver according to the DDK for the system, which shows two components for the mouse driver. One is the traditional "MOUSE.DRV" for backwards compatibility with Win16 programs, the other is a VXD driver that does the work as the mouse driver. I have developed in DOSLIB a tool to examine and decompile VXD files which may help fixing this issue.

I'm making the assumption that since OS/2 and Windows diverged long before Windows 3.1 the chances are slim the Windows kernel would support LX type linear executables.

[joncampbell123]

I'm not asking this project to integrate VXD development headers or libraries in any way, but if the linker were to support internal relocations when generating LE executables it would enable VXD development using the Open Watcom tools.

[jmalak]

OW Linker support VXD for Windows 3.1 (see bld/win386/vxd project). If you want VXD support for Windows 9x then it must be extended. anyway proper use is "system win_vxd" because "format windows vxd" is not only necessary setup.

[jmalak]

VXD suppose 32-bit modules and it looks like you use wrong linker commands if create NE 16-bit format instead of VXD 32-bit LX format executable. Please, could you show full linker command and all used *.lnk files

[joncampbell123]

I noticed that "system win_vxd" seems to work now. As far as I can tell it's perfectly valid, but for some reason Windows 3.1 thinks it's corrupt. More examination is required.

[joncampbell123]

I made a working .386 file using Microsoft tools, which worked (it took time to strip a VXD sample down to the bare minimum that would do nothing but load)

Then I had Open Watcom link the OBJ files that were generated by Microsoft tools, and Windows accepted the .386 file, though it crashed because Microsoft MASM generates iterated data OMF records that WLINK doesn't support. Still, a step in the right direction.

EDIT: Apparently Windows crashes because the iterated records fill in the DDB Control procedure address. If that comes out zero, then Windows crashes calling that entry point.

EDIT: The warning message from WLINK is:

Warning! W1162: file dboxvxd.obj(dboxvxd.ASM), record 17: relocations on iterated data not supported

EDIT: This test was carried out against Windows 3.1 in DOSBox-X

[joncampbell123]

Hey, it works. At least, Windows 3.1 is happy with my VXD that loads and does nothing but execute INT 3 for DOSBox's debugger when it's entry points are called. Windows starts up just fine with it.

Noted in my project that there are some undocumented extra LE header fields Windows requires to carry the SDK version and VXD request ID. Also putting your DDB in a code segment doesn't work, even though VXDs are mapped into a flat 32-bit space.

[jmalak]

If you specify what should be change in Wlink with regards to VXD stuff I will fix it in Wlink.

[joncampbell123]

It looks so far like Wlink is able to generate VXDs without issue. I have DOSLIB now with two VXD examples. One uses WLINK + NASM, and the other WLINK + WCC386 with lots of inline assembly and #define macros.

[joncampbell123]

This isn't important now, but one thing you might look into is support for relocations with iterated data segments. Microsoft MASM in some cases will generate such records, such as when assembling code in the Windows 3.1 DDK. NASM and WCC386 do not generate such records, so it's not a problem anymore in DOSLIB.