Make ZDOOM running on DOS

[japheth]

Hello,

Im currently trying to get some win32 games running on DOS with the hx dos extender (this extender is my child ). This is possible because hx has some win32 emulation included, among them is GDI, DirectDraw, DirectSound and others.

I was also able to get zdoom to run, but it required some slight source code modifications. Since I cannot offer a zdoom binary for download on my site, I would appreciate these modifications be included in the standard win32 zdoom version.

The modifications are

- load SHELL32.DLL, COMCTL32.DLL and COMDLG32.DLL dynamically with LoadLibrary/GetProcAddress. These dlls are not required for normal playing and there is no emulation available for them in hx.

- make the eaxeditor an external dll/app which is loaded dynamically. In the modifications I did just deactivate this editor, but this was just for testing reasons of course. This modification is no strong requirement, but would significantly ease the DOS port.

btw: Im aware that there was a DOS port some time ago, but it seems to be pretty outdated now.

Regards

Japheth

[Graf Zahl]

JUst a question: If it is your 'child', why don't you add empty stubs for the DLL's in question? Since these are used rather frequently doing so might help you a lot getting certain things to work.

[japheth]

> If it is your 'child', why don't you add empty stubs for the DLL's in question?

In fact I did this first. But I find it somewhat stupid to supply lots of such dummies. OTOH loading these binaries only on demand will speed up zdoom's startup process . And the modification is simple and is just a couple of extra lines. That's worth the effort for a DOS port IMO (and since hx runs on dosemu, it is kind of a linux port as well).

[Bio Hazard]

Why on earth would you want to run ZDoom in DOS? Any computer that can't run a good enough OS certainly can't play ZDoom at any kind of acceptable speed.

[jallamann]

My old games box runs a p133 with 64mb ram and I plan on upgrading it to a K6-2. I run DOS 7.1 on it without the want and/or need to run Windows. Not that I would need zdoom running in DOS, it would by all means be cool
I like the idea of this extender

[japheth]

> Why on earth would you want to run ZDoom in DOS?

I admit it's a bit of a toy. But for the extender zdoom is a good real-life test-case as well.

btw, there is a palette problem when running with the extender and possibly someone with good knowledge of the zdoom source can put some light on this issue:

in the zdoom source file win32video.cpp, method DDrawFB::DDrawFB(),
there is a palette initialization routine:

Code: Select all

	for (i = 0; i < 256; i++)
	{
		PalEntries[i].peRed = GPalette.BaseColors[i].r;
		PalEntries[i].peGreen = GPalette.BaseColors[i].g;
		PalEntries[i].peBlue = GPalette.BaseColors[i].b;
                ...
	}

which is good so far, but the peFlags field is not initialized. The object is created by using HeapAlloc() without the zeroinit flag, so there might be a random value in this field. Hx's IDirectDrawPalettte emulation gets very confused if bit 1 of the peFlags field is set, with the effect that in fullscreen mode some palette entries are not set, which looks very ugly.

So my question is: is this kind of a (hidden) bug in zdoom or a bug in hx's emulation?

Regards

Japheth

[Graf Zahl]

In fact I did this first. But I find it somewhat stupid to supply lots of such dummies.

Your entire project seems rather pointless if you have to ask other programmers to change their projects because you are unwilling to add such a trivial thing.

OTOH loading these binaries only on demand will speed up zdoom's startup process .

That's irrelevant because you have to ask for ZDoom to be changed.

And the modification is simple and is just a couple of extra lines. That's worth the effort for a DOS port IMO (and since hx runs on dosemu, it is kind of a linux port as well).

Again that's irrelevant. Either provide a complete solution or accept the fact that some software won't work.

[japheth]

> That's irrelevant ...
> Again that's irrelevant. ...

Are you "Seven of Nine"?

> Either provide a complete solution or accept the fact that some software won't work.

I don't agree that just these two options are "legal". I may suggest anything which I think is (more or less) useful, that's the purpose of this subforum. Please don't pollute other people's threads with such "irrelevant" remarks.

[randi]

- load SHELL32.DLL, COMCTL32.DLL and COMDLG32.DLL dynamically with LoadLibrary/GetProcAddress. These dlls are not required for normal playing and there is no emulation available for them in hx.

SHELL32 is needed to get the name of the ini file. COMCTL32 is needed for theming on XP and the EAX editor. COMDLG32 is needed for the EAX editor. Sure, the EAX editor is not used for normal play, but the config file is.

- make the eaxeditor an external dll/app which is loaded dynamically. In the modifications I did just deactivate this editor, but this was just for testing reasons of course. This modification is no strong requirement, but would significantly ease the DOS port.

I'd much rather keep it as part of the EXE, since that's just easier for me.

btw: Im aware that there was a DOS port some time ago, but it seems to be pretty outdated now.

Yes, there was at one time a DOS port (for only one version). It was quickly abandoned because it was unreliable and there really wasn't much point.

[Graf Zahl]

> That's irrelevant ...
> Again that's irrelevant. ...

Are you "Seven of Nine"?

> Either provide a complete solution or accept the fact that some software won't work.

I don't agree that just these two options are "legal". I may suggest anything which I think is (more or less) useful, that's the purpose of this subforum. Please don't pollute other people's threads with such "irrelevant" remarks.

DOS is irrelevant!

And no matter what you think, don't decide that some things are not necessary to emulate and then bug others to acquiesce to your request to support them in a way that suits your limited emulation. The probability is extremely high that the answer will be a flat out 'no'.

[Kristus]

DOS is irrelevant!

Mm, yeah I wish. But being an old games afficionate I need it (although, Dosbox does me a lot of favors. ). I don't see the point of this emu though. If you can be spared from using dos, then why not be it?

[Caligari87]

DOS FOREVER!!!

Must find a copy of the latest MS-DOS that isn't windows-integrated... must... dualboot... games... 5 1/2 floppy... nostalgia... *faint*

[japheth]

> SHELL32 is needed to get the name of the ini file.

Possibly not. I implemented my suggestions in the zdoom source, tried it and it seems to have not problems to find and read it's ini file. The one usage of shell32 was in i_crash.cpp. But may be I edited some outdated version.

> The probability is extremely high that the answer will be a flat out 'no'.

Yes, but it is possibly not 100%

Regards

[Graf Zahl]

I think the answer in this case was and I fully understand why.

[Syfo-Dyas]

Hey guess what?!?! I'm going to resurrect another ancient thread!!!

I'm getting ready to send Japheth a PM and see where he left off with all this. It's a very curious project, though I am wondering if it would still be possible to pull off with that latest additions to ZDOOM and what not.


Anyhow, what makes this project significant to me is the fact that:

1. Japheth claims to have been able to launch an EXE made for Winblows under DOS which suggests that this might be possible for other games and applications I presume?

2. If a more recent version of ZDOOM could be ran from DOS then I would presume that it could also be loaded up under DOXBOX which in turn would make ZDOOM very very portable! If he was able to run ZDOOM (at the time) on a "p133 with 64mb RAM", then I would presume that any operating system with a port of DOSBOX could run it just fine too, assuming they have a fair amount of RAM and processing power. I think a 2.4Ghz machine and up would do the trick just fine.