Hi there,

Decided to create an account here, as posting on X would be rather painful experience.

Both MGENVXD and GENVXD seems to be part of "mplayer" library. But in version that I have (GOG, Quake The Offering), it doesn't look like they're used.

In quake these calls can be found - again in unused - mpllib.c and mpllpc.c.
There's similar code used in Red Alert: Command & Conquer.

https://git.clss.pl/externals/CnC_Remastered_ … ALERT/MPLIB.CPP

I briefely looked at the code, and it looks like it's a channel to provide some Windows APIs functionality to game run in a
"dos window" (called DOS Box inside quake readme). There's also following piece to support that, which I found in:
https://www.hydrogen18.com/blog/peeking-under … nd-conquer.html

Update 2020-06-08 Larry Hastings reached out to me directly to correct some of my assumptions. It turns out the source code that […]
Show full quote

Update 2020-06-08 Larry Hastings reached out to me directly to correct some of my assumptions. It turns out the source code that I presumed
was in fact the MPlayer implementation is not. In fact it is a piece of software called the "chunnel" which allows a DOS mode application
running on Windows 95 to interact with the networking stack provided by Windows. He also shared some details of how MPlayer integrated
with games. I've reproduced it here, with the names of other individuals removed.

First, most companies didn't do their own integration with Mplayer; they just sent us a code drop and we had to figure out how t […]
Show full quote

First, most companies didn't do their own integration with Mplayer; they just sent us a code drop and we had to figure out how to build
it and do all the integration work ourselves. But I think Westwood was the exception to the rule. I remember one of our
"porting engineers" took a trip out to visit Westwood before Red Alert shipped. He was very impressed by the RA network model!

Second, all Mplayer assets were sold to GameSpy, who didn't want any of the online services (Mplayer / POP.X / Global Rankings).
All they wanted was the userbase, and... the ad sales team, maybe? Anyway, GameSpy folded in 2013, and their assets were sold to
Glu Mobile, so I guess theoretically they own the IP now. Meanwhile, in 1998 TEN pivoted to do "classic" online games, in 1999
they rebranded themselves as Pogo.com, and in 2001 they were bought by... EA! So EA is probably safe shipping the TEN code.
And I doubt anybody cares about the Mplayer code either, it's long dead.

Third, remember how I said companies tended to do a code drop and Mplayer did the integration work themselves?
That was true of id software too. The Mplayer code you saw inside Quake 1 is not integration with the Mplayer gaming service!
It's actually technology we licensed to id called the "chunnel", written by a British programmer guy named ***.
The "chunnel" was a library that let 386 protected mode DOS programs running under Windows make calls into Windows 95's
Winsock networking stack. Remember, this is circa 1996, gaming under Windows hadn't quite happened yet.
Quake initially shipped as a DOS program and wasn't ported to Win32 until a year or two later.
The "chunnel" solved a real problem for id, letting their 386 protected mode DOS program participate in network play
when run under Windows. Part of how they showed their thanks was, Mplayer got every id game (while it was a going concern).
Note that if you run early versions of Quake for DOS, like the initial shareware demo, the "splash screen" has the original
Mplayer logo (the golden waveform), and a note about "technology licensed from". And that explains the "-mpath" command-line
setting for the DOS builds of Quake 😉

Besides -mpath, it is quite possible, that some other options from quake command line were passed to the lib, but I don't want to speculate
too much about it. (I'm mostly refering to -winmem and -winlock)

Gritty details

Let's get back to code, the lib is also used in Witchhaven2:

https://github.com/willtate/whaven2/tree/master/SRC/mplayer

There are visible MGenInitVxD and MGenUninitVxD exports, which I haven't seen anywhere in quake source, there's no implementation,
but not a big issue here, what MGenInitVxD is basically load VXD, and issue three Ioctls, ioctls are called via ids: 1, 2, 5, we can find them in Witchhaven2's mgenord.h

1#define MGENVXD_REGISTER_ORD       1
2#define MGENVXD_GETMEM_ORD         2
3#define MGENVXD_DEREGISTER_ORD     3
4#define MGENVXD_WAKEUP_ORD         4
5#define MGENVXD_MAKEDQS_ORD        5

In my case mgenvxd.vxd has 9883 bytes and md5: 4c7fc48ca4d16f4efbcf176c4eb0538e

DeviceIoControl dispatcher is located at 0xC0000390, actual dispatch table is at 0xC00002D4.

• 0x1 MGENVXD_REGISTER_ORD - looks like some initialization
• 0x2 MGENVXD_GETMEM_ORD - allocates requested chunk of memory - with PAGELOCKED and PAGEZEROINIT flags (0x81), and creates `rtq_node` there, the APIs below operate on those
• 0x5 MGENVXD_MAKEDQS_ORD - registers interrupt handler 0x48 - the DOS application running under Windows, will use that handler through Windows VMM (Virtual Machine Manager).

For completeness:
[list
[*] MGenUninitVxD issues ioctl MGENVXD_DEREGISTER_ORD
[*] MGenWakeUp issues ioctl MGENVXD_WAKEUP_ORD
[/list]

There also seems to be two other ioctls, with ids 6 and 7, I'm not quite sure what they do.

To "call" interrupts, there are following IDs used:

1// these are DPMI functions.  Make sure they don't clash with the
2// other MGENVXD_XXXX functions above, or the DPMI functions!
3#define MGENVXD_GETQUEUECTR_ORD    6
4#define MGENVXD_MOVENODE_ORD       7
5#define MGENVXD_GETNODE_ORD        8
6#define MGENVXD_FLUSHNODE_ORD      9
7#define MGENVXD_MCOUNT_ORD         10
8#define MGENVXD_MASTERNODE_ORD     11
9#define MGENVXD_SANITYCHECK_ORD    12
10#define MGENVXD_WAKEUPDLL_ORD       13
11#define MGENVXD_WAIT_ORD`           14

and as can be seen in quake source, interrupt handler is called like so:

1int MGenGetQueueCtr(int qNo)
2{
3   REGISTERS   regs;
4
5   regs.d.eax = MGENVXD_GETQUEUECTR_ORD << 16 | MGENVXD_DEVICE_ID;
6   regs.d.ebx = qNo;
7   int386(CHUNNEL_INT, &regs, &regs);
8
9   return regs.d.eax;
10}
11

MGENVXD_DEVICE_ID is passed in low WORD, while id in high WORD.

Note: in the dll itself, I haven't seen functions corresponding to MGENVXD_WAKEUPDLL_ORD or MGENVXD_WAIT_ORD.

Interrupt handlers form a chain, so the mplayer handler located at 0xC0001312 is "being nice" and there's a check if low-word equals MGENVXD_DEVICE_ID (0x18AA),
if it's not previous handler in chain is called, if it is, actual handler is called, which is located at 0xC0000CF0.

Given, that I don't see the dll used, I don't think it has much sense to describe particular handlers.

There's a great resource, an old book by Karen Hazzah: Writing Windows VxDs and Device Drivers .

Last but not least: I love your books and your work.

mastodon: @gim@lou.lt, elonX: @gim