DOS Doom Code Execution

[seed]

4 hours ago, Dragonfly said:

Look, if someone makes a mod worth playing, I guess it's on the mod-maker to also provide ample instructions on how to play the mod, no? You don't let map authors release a wad for, idk, EDGE, and go on to never tell you how to play the mod in the first place, right?

 

If the wad/mod is worth playing, people can and will go the extra mile to set up the environment to play it, provided there's clear / easy enouh instructions to follow

 

Debatable and entirely subjective.

 

If I am to go through a ton of steps just to play the damn thing and there's still no guarantee it will work fine, then thanks but no, I won't play it regardless of how good it may be. I've already done this with some older games where setting them up to run as well as they could on a modern system was more work than it was worth, so I resigned and never played them. At one point I draw the line, too much for too little.

 

Ease of use > any product.

 

11 hours ago, Graf Zahl said:

DosBox is arcane for those who grew up on modern computers and have no interest in technical solutions. They may unknowingly use it if they get a predefined setup, but they most likely won't be able to create one themselves.

 

100% agreement there.

Edited October 9, 2020 by seed

[kgsws]

On 10/8/2020 at 8:51 PM, Linguica said:

?? Potential ACE inside the BSP tree? What is the theory behind this?

Well, it's an unchecked recursive function. So stack "under-flow" ?

 

Quote

Everyone about text parsing.

Text parsing is not that hard, but there are some things i would rather do on PC, during compile time. Biggest issue i have with is DECORATE. It adds a lot of new states and mobjtypes but there is no indication how much in advance. I can't think other way but to do double parsing. One just to count size required for allocation and other for actual parsing.

I am not sure about the best way to add custom states and mobjtypes while keeping old ones working, yet.

 

2 hours ago, Altazimuth said:

One thing I've thought about that I can't spot being mentioned on prior pages at least: Would such abuse be usable to add some sort of ACE header to an otherwise normal vanilla save such that you can circumvent the save game buffer overflow? It'd be an incredibly involved setup for pretty minimal gain but it could be a neat workaround.

Either way my imagination is rather lacking here, compared to the incredibly impressive work already done. Great job on this, kgsws! How hard is it to write an individual ACE savegame, anyway?

It could add totally new code for savegame handling, so yes. Technically there is only one ACE savegame that does include loader which handles initialization for rest of the code. Main code can be compiled in C and just slapped at the end of prepared ACE savegame.

Well, that is because i have already made quite some progress on working hacking API. (Still hacking rather than modding. Even though you can make mods this way.)

 

On 10/8/2020 at 10:15 PM, holaareola said:

Couldn't we use a map slot like map33 that is hardly ever occupied?  I created a little test wad a second ago and -warp 33 worked for me in Dosbox'd doom2.exe, GZDoom and Crispy.

MAP33 causes illegal memory access. I know in DOS it does not matter that much. Most of the time this address is just unmapped and this bug is just skipped. But would it work everytime? What about in windows, i can't test that.

 

 

More about DECORATE.

I would certainly support only limited feature set. Before expressions were a thing. And of course limited set of flags and so on.

 

Here is a quick update. My testing map. I add new rooms with new features.

Edited October 9, 2020 by kgsws : forgot MAP33 info

[Smite of Disrespect]

this thread is now about snek

 

post your snek

 

 

[M_W]

5 hours ago, dew said:

 

> when u fail to control the narrative but still keep trying

Yeah, I don't know why he bothers developing ZScript. Might be worth doing it for the fun of it, but don't expect it to find an audience when people can just play REKKR or BTSX on Steam.

[Revae]

I feel like a lot of the conversation has shifted post by post, maybe without sufficient quoting. At this point we're talking about users who "don't read anything". That's maybe a fair demographic to discount for a project like this. If we're talking about the validity of this overall, Graf said it's a worthwhile pursuit but the audience will likely be limited. He's pretty much right, unless this gets somehow interpreted into modern ports. Which is a reasonable consideration since the initial question was "Is it worth it?".
Although 5 pages, and obvious personal interest from kgsws probably indicates that it's worth it regardless.

[Doomkid]

On 10/6/2020 at 8:21 AM, rustygizzard said:

you've gotta be shitting me. mouselook and an overlaid status bar? this is crazy. i don't even give a shit if this runs on any ports, fuck it, just show me what else can be done on vanilla doom. 

I agree so hard with this. Ports can already do things that ports can do, I’m here for the DOS exe!
 

On 10/6/2020 at 8:33 AM, Graf Zahl said:

remember Entryway's limit epanding modified EXE?

Heck I don’t just remember it, I use it all the time, plus the mirror of it on Doomshack sees regular downloads.
 

On 10/6/2020 at 10:06 AM, kgsws said:

You can't distribute modified EXE file so you have to pack patcher and patch file with your WAD file. My intention was to sidestep this issue. It is not exactly as i imagined but all you have to do is run the game with more parameters (-loadgame) and boom.

I’m pretty sure distribution of modified Doom EXEs is fine, isn’t it? Doomp and Doom2p have been around since 2006 with no issues, and some older mods come with pre-DeHackEd-applied EXEs. I was under the impression it was fine but if there’s any actual legal reason not to do this I’d like to know just to avoid it ever being a problem.
 

On 10/6/2020 at 4:19 PM, printz said:

Just continue using DOSBox to play this hacked flavour of Doom. It's currently a fully stable emulator. You underestimate its robustness. Instead of trying to adopt this hack into Doom source ports, the larger community's better effort would be spent on keeping DOSBox alive on as many platforms as possible.

Absolute agreement.

[NY00123]

Well, looks like the discussions about the viability of running this under Chocolate Doom have more-or-less ended.

 

As already said, it's still interesting to see this done with Vanilla Doom for the first time. I suppose that we'll see what's to come as the time is passing.

 

On 10/6/2020 at 9:53 AM, NY00123 said:

I know that the latter approach is being used for Commander Keen mods. Of course, it's practically impossible to properly support all possible patches in a re-implementation (like Commander Genius) or a source port, not without more-or-less running the original exe in an emulator. A small, finite subset of patches can still be supported, of course, but there will obviously be more.

 

On 10/6/2020 at 11:19 AM, Graf Zahl said:

 

Binary patches of executables always come with a risk, though, and that's not limited to exploits. Just have a look at Quake 2. Thanks to its DLL interface, any port switching to a different architecture other than 32 bit Windows is left in the cold with many of those old user mods which shipped their own game DLL but didn't bother including the source.

 

 

Now, this is a good example. From a bit of earlier experience that I had, even if the architecture is the same, a mod made to work on 32-bit Windows installations may not work as-is on a different platform, like Linux, at least not without just using the Windows executable via Wine. Reason being, of course, that a compatible DLL replacement (e.g., an .so file) should be built.

 

There can be multiple reasons for supporting modding in this manner. Flexibility is an obvious answer, and maybe performance was a concern for certain games. While some form of scripting is significantly better in terms of compatibility with future ports, this is probably not a goal for many commercial products.

 

Back to my Commander Keen example, I wasn't entirely sure how was the Quake 2 example related, because I referred to 16-bit real mode DOS apps that presumably always need a CPU emulator for running on modern OSes, anyway. However, it's true that Virtual 8086 mode i.e., VM86, exists. Windows installations which aren't 64-bit (including 9x and NT-based installations) can take advantage of it for varying forms of compatibility with DOS apps. Similarly, DOSEMU can take advantage of VM86 on Linux, if supported.

 

Since Keen Dreams has been the only open-sourced Commander Keen title since 2014 (albeit the related Hovertank 3D and Catacomb games were also open-sourced in 2014), it was natural that custom binary patches would become the way. One may assume that the community is too small to consider some form of scripting as a standard. However, there's the Keen 4-6 reverse-engineering project known as Omnispeak, in which object states of type "statetype" (also commonly known as "Galaxy Actions") are exported to external files. The developer of Commander Genius also seems interested in implementing some form of scripting.

 

Also, I was maybe not entirely correct when I referred to the whole Commander Genius project as a re-implementation. This might be the case for Keen 1-6, but from what I know, the Keen Dreams support is based on the original code (via the Reflection Keen Dreams port).

 

Even for the few individuals working on EXE patches in differing times, the approaches and priorities were different. A couple of examples that I'm aware of:

- Evidence shows that levellass wasn't reading assembly code. She was working directly with machine code. Even with Keen Dreams being open-sourced, she still seemed to like the process of figuring out patches.

- On the other hand, lemm was reading binary code using assembly translations, and, IIRC, didn't seem to mind coding in C first. Given the choice, he wouldn't have a problem with using code written in a higher-level language like C, compared to assembly.

[Redneckerz]

 

Quote

I doubt it. The last time this happened for me was Caverns of Darkness. I thankfully declined when faced to play this with the semi-broken DOS EXE it came with. Fortunately I was able to come up with an alternative solution.

Always nice reading not-so-obvious snark at other people's work. Totally unnecessary equally so. I never understood why you *need* to do this every single time its about something as far removed from GZDoom as possible, whether that's CoD or in Doom ACE.
 

On 10/9/2020 at 10:18 PM, Altazimuth said:

Either way my imagination is rather lacking here, compared to the incredibly impressive work already done. Great job on this, kgsws! How hard is it to write an individual ACE savegame, anyway?

I believe this is where that modding API comes into play. Counting KGSWS posts, there seem to be multiple ways to achieve ACE exploitation:

• Through a modded Savegame with Loader and modded WAD.
• Through a modded Savegame only.
• Through a modded WAD only.

So there are multiple methods of execution (quite literally). Such an API will likely describe what each of these can and cannot do in terms of flexibility or eventual penalties.
 

On 10/10/2020 at 8:08 AM, Revae said:

I feel like a lot of the conversation has shifted post by post, maybe without sufficient quoting. At this point we're talking about users who "don't read anything". That's maybe a fair demographic to discount for a project like this. If we're talking about the validity of this overall, Graf said it's a worthwhile pursuit but the audience will likely be limited. He's pretty much right, unless this gets somehow interpreted into modern ports. Which is a reasonable consideration since the initial question was "Is it worth it?".
Although 5 pages, and obvious personal interest from kgsws probably indicates that it's worth it regardless.

It's totally worth it. Vanilla Doom remains a valid platform of WAD making and MOD making, even though its still a nice. Being DOS-only, it is a sub-niche within said niche. But the reason this excites people is because of the possibilities this offers - Enough for many to put the DOS-only limitation aside.

 

Which makes sense. If you get significant freedom in the default executable to the point where entirely new features are possible, like custom status bars or even custom games, at the cost of being limited to pure DOS or DOSBOX, its an offer many are willing to accept. The only real hurdle is ease of use, and on that notion Graf is partially right.

Beyond that, however, he is not, for reasons made prior.

On 10/10/2020 at 10:55 AM, NY00123 said:

Well, looks like the discussions about the viability of running this under Chocolate Doom have more-or-less ended.

That's because this is prohibitively difficult replicate on ChocoDoom since its a DOS-only exploit. To replicate, you need to fully simulate the entire DOS enviroment with every single quirk it exhibits - Which is something DOSBOX does not do, it emulates, it does not simulate.

 

Real world simulation of such an environment comes at a significant performance penalty - Which, although possible, is highly unlikely would ever be a thing for Choco.

 

Edited October 11, 2020 by Redneckerz

[ReaperAA]

I think Graf is probably right when he said that the audience for this will be limited. After all, most people (including me) prefer playing on a source port rather than DOSBox and most modders would continue to make wads/mods with source ports first mentality.

 

With that being said, I still think this a cool endeavour and would definitely like to see how far the vanilla .exe can be pushed (if only for my own curiosity sake).

[wallabra]

On 10/6/2020 at 5:19 AM, Graf Zahl said:

 

Binary patches of executables always come with a risk, though, and that's not limited to exploits. Just have a look at Quake 2. Thanks to its DLL interface, any port switching to a different architecture other than 32 bit Windows is left in the cold with many of those old user mods which shipped their own game DLL but didn't bother including the source.

 

I like Quake 3's approach, that is compiling C to platform-agnostic bytecode, optimizing it to a target architecture only on game init, and if and only if the game is running on that platform during the fact. I also like the UnrealScript approach, of making your own bytecode. Honestly, I feel it is more elegant than just reading text directly, or compiling text on init everytime.

 

Text is for human representation and preprocessing; beyond that, it becomes a burden, and boy a burden it can be. It's bad practice to put all the code in the same place ever. Split the parser off into a compiler or something. Reading bytecode (with eg fread) is usually simpler than parsing text on the fly. Unless, dunno, unless you use Python?

 

But compiling extensions as native DLLs?... I mean, what the fuck? id were having some extra shady joints that day, if they thought they could just use headers with externs and let people compile mod code to x86 and with the Windows dynamic link ABI! At least build a raw bytecode blob like .com or something. Better yet, put all that raw compiled x86 into a container file that can index entrypoints and such! Hmm... I don't know you, but it smells like WAD to me! Or, er, sorry, smells like ZIP to me.

 

[Loud Silence]

This could be used to make good upgrade to vanilla:

Ability to bind ANY key.

Raised or removed limits.

640x400 or 640x480 resolution if possible.

Autorun option in menu.

[LexiMax]

There's two sides of the coin.  Quake has always been better at doing total conversions because you either have complete access to the gameplay source or run scripts in a virtual machine that govern gameplay.  Heck, it even seems like most games that used the Quake engine were more like glorified total conversions that could also modify the rest of the source that wasn't available to modders.

 

That being said, layering new features on top of the existing engine like Doom does it is not necessarily bad.  It's much easier to figure out for a modding newbie, for one thing.  Anytime I ever had the idea of prototyping a game mode for Zandronum, I was able to do it out within a few pages of ACS scripts and maybe a few DECORATE replacements.  At no point did I have to throw myself into the deep end of some enormous modding SDK.  There's value to that, even if it ends up in an enormously complex morass like what ZDoom eventually turned into.

 

However, I don't really consider ACE either of those things.  This is basically the same sort of amazing feat as getting Super Mario World to play Pong.  The fact that new source port features can be hacked into the original DOS executable is just a bonus feature, and trying to support a theoretical ACE mod in other ports seems like it'd missing the point, since the whole point of being able to modify Vanilla is that it's DOS Vanilla and not something else.  After all, if you want to hack features into other ports, you don't need ACE, you just load up Visual Studio and add your feature.

Edited October 10, 2020 by AlexMax

[rustygizzard]

2 hours ago, Loud Silence said:

This could be used to make good upgrade to vanilla:

Ability to bind ANY key.

Raised or removed limits.

640x400 or 640x480 resolution if possible.

Autorun option in menu.

not a programming guy but is this possible? It would be cool to get some of these features in vanilla using only savegames or wads, and could possibly make playing dos doom less of a pain in the ass for the user.

[Redneckerz]

16 hours ago, Loud Silence said:

This could be used to make good upgrade to vanilla:

Ability to bind ANY key.

Raised or removed limits.

640x400 or 640x480 resolution if possible.

Autorun option in menu.

Raised limits already exists as Doom-plus and others.
Autorun and any key bind should be possible.

 

Resolution increase i am not too sure, but KGSWS probably knows.

[kgsws]

On 10/10/2020 at 9:33 PM, Loud Silence said:

This could be used to make good upgrade to vanilla:

Ability to bind ANY key.

Raised or removed limits.

640x400 or 640x480 resolution if possible.

Autorun option in menu.

First thing my code does is that it enables autorun. In a way where you can walk by pressing 'run' key.

Binding any key is quite simple but also time consuming (locationg all key checks).

Raised limits are possible, bit tedious though. However all patch locations are already known since there are EXE hacks that raise limits.

Changing resolution is also possible but very tedious. There are VESA modes in DOS, build engine supports these. I am not sure how these work but i think it would require video RAM acces (so all drawing functions).

And worse, planes have hardcoded max height of 255. That might be worst thing to change.

Yea, and then there is an issue with aspect ratio.

 

 

Anyway, my demo WAD is getting closer to release. I think i will add one more feature and release first version.

I have much more ideas but it already takes quite a lot of time.

[D.Vile]

Is that supposed to be colored lighting !? That`s neat, reminds me of Doom 64. And speaking of that game, I wonder if it might be possible to recreate that Terraformer room with some basic scripting...

[Maes]

At this point I wonder if stuff like the Sky May Be, and even more, its "unreleased" sequel "The Blessed Engine" actually used some form of ACE exploit... but no, it's just a plain DEH patch. Hard to believe at times.

 

On 10/10/2020 at 10:14 PM, Gustavo6046 said:

But compiling extensions as native DLLs?... I mean, what the fuck? id were having some extra shady joints that day, if they thought they could just use headers with externs and let people compile mod code to x86 and with the Windows dynamic link ABI!

 

Then again, this was at a time where CPU horsepower was still somewhat at a premium, and 100% scripted extensions were still seen as too restrictive -even if Quake pioneered the use of just just such a language. However, using DLL extensions was not by any means exclusive to Quake 2 - in fact, it kinda became a trend for later id engine -e.g. Idtech 4 aka Doom 3 seems to be able to use both regular scripting and compiled DLL extensions. I dunno if Quake 2 was restricted to just using DLLs though, that'd kind of suck.
 

Edited October 12, 2020 by Maes

[SaladBadger]

quake 2 is indeed limited strictly to native DLLs, as graf had mentioned earlier. id didn't reintroduce the idea of a scripting VM until Quake 3, though Quake 3 still supports dlls for debugging purposes or mods that need things like filesystem access. it's kinda a nightmare, I like that I can grab yamagi's x86 build and play any old mod just fine, but if I go for a x86-64 build, that breaks down immediately. Another game I kinda enjoy, descent 3, suffers even worse because they decided to use dlls for things like level scripting, so it came to pass that a new linux build was made that happens to be not as bad as the old one but then suddenly practically all old levels break because of this.

 

The late 90's were kinda a dark time for game dev, weren't they?

[Redneckerz]

22 hours ago, kgsws said:

Anyway, my demo WAD is getting closer to release. I think i will add one more feature and release first version.

I have much more ideas but it already takes quite a lot of time.

Thats not a COLORMAP. (Or is it? Some parts look like typical COLORMAP fuckerY)

 

That's colored lighting with fades.

 

THAT'S COLORED LIGHTING WITH FADES.

 

What the actual fuck man. I was half-joking when i said ''new lighting and shadow effects'' and yet here you are doing exactly that.

This heavily reminds me of my all time fave Wolf3D mod, Green Arrow:



Which does equally impressive stuff with lights and shadows.

You know what - I am done for. The left shot alone is just the most brilliant thing i have seen this side of the sun of Doom this year. Absolutely, absolutely... fuck. Its amazing.

If you weren't already a suggestion for a Cacoward - Now it would just be criminal not to just for the whole idea and execution alone.

 

10 hours ago, Maes said:

At this point I wonder if stuff like the Sky May Be, and even more, its "unreleased" sequel "The Blessed Engine" actually used some form of ACE exploit... but no, it's just a plain DEH patch. Hard to believe at times.

It and its Blessed Engine II sequel are fascinating DeHackEd patches that really tried to pass off as an actual engine... but it was just a very elaborate DeHackEd patch. Still one of the all time greats.

[Noiser]

Amazing dude, that's really exciting! I did some tests with colored lighting before but it was very limiting. This is the real deal!
 

On 10/11/2020 at 7:49 PM, kgsws said:

 Changing resolution is also possible but very tedious.

And it's not even necessary imo. Part of the charm of vanilla is the original resolution >:-)
(I wouldn't mind see it increased though)

Edited October 13, 2020 by Noiser

[GuyMcBrofist]

A large project that uses this would be cool, and playing it would be worth setting DOSBox up for plenty of Doom players IMO.

[rustygizzard]

ok i leave for 2 days and i come back to see colored lighting and higher resolution, jesus christ

[kgsws]

On 10/12/2020 at 3:28 AM, D.Vile said:

Is that supposed to be colored lighting !?

Yes, colored light. Just like many source ports can do.

 

22 hours ago, Redneckerz said:

Thats not a COLORMAP. (Or is it? Some parts look like typical COLORMAP fuckerY)

That's colored lighting with fades.

Oh no, it's just a COLORMAP. It can be used per-sector though. Well, like many source ports do colored sector lights.

 

22 hours ago, Redneckerz said:

This heavily reminds me of my all time fave Wolf3D mod, Green Arrow

That actually looks great. Hard to tell it's a Wolf3D mod just from the screenshot.

 

20 hours ago, Noiser said:

I did some tests with colored lighting before but it was very limiting.

I am kinda curious. In original doom engine or in source ports?

 

1 hour ago, rustygizzard said:

ok i leave for 2 days and i come back to see colored lighting and higher resolution, jesus christ

Eh, some expectations are getting too high. Higher resolution was just a question. It's not implemented.

 

 

Well anyway. It is time to release first version.

https://github.com/kgsws/doom_ace/tree/doom2_ace/wad - get demo.wad

Again remainder, it's Doom2 v1.9 only. Exploit is contained in MAP32, so start with "doom2 -file demo.wad -warp 32", then you can start new game.

I have intentionally added bad M_DOOM so you can't even enter menu if you do not start it properly. Also TITLEPIC ... (you can try if you are interested)

Those bad entries are cancelled when my exploit runs, so you won't even notice. Oh and forget about source ports for now.

 

Take this wad just as a proof of concept. It is intended to show what can be done. It does not yet contain modder-friendly API or converter or stuff ...

This should hopefully show real interest in DOS EXE modding.

You can also check source code if you are interested. It's mostly hooking (redirecting) original EXE calls to my code.

https://github.com/kgsws/doom_ace/tree/doom2_ace/demo

 

OK, now let's see what happens. Oh and by the way, can you get 100% in my demo map?

[Redneckerz]

6 minutes ago, kgsws said:

Oh no, it's just a COLORMAP. It can be used per-sector though. Well, like many source ports do colored sector lights.

How does this differ from the stock COLORMAP? By careful tuning, you can achieve Vanilla Colored Lighting already, see here.

 

 

6 minutes ago, kgsws said:

That actually looks great. Hard to tell it's a Wolf3D mod just from the screenshot.

I am just giving you ideas ;)

6 minutes ago, kgsws said:

Well anyway. It is time to release first version.

https://github.com/kgsws/doom_ace/tree/doom2_ace/wad - get demo.wad

Again remainder, it's Doom2 v1.9 only. Exploit is contained in MAP32, so start with "doom2 -file demo.wad -warp 32", then you can start new game.

I have intentionally added bad M_DOOM so you can't even enter menu if you do not start it properly. Also TITLEPIC ... (you can try if you are interested)

Those bad entries are cancelled when my exploit runs, so you won't even notice. Oh and forget about source ports for now.

 

Take this wad just as a proof of concept. It is intended to show what can be done. It does not yet contain modder-friendly API or converter or stuff ...

This should hopefully show real interest in DOS EXE modding.

I will try this out ASAP in DOSBox.

 

[URROVA]

Ehhh... WTF vanilla running an HEXEN FORMAT MAP, with thing specials and all xD

Coming soon: ACS on vanilla.

Edited October 13, 2020 by URROVA

[rustygizzard]

1 hour ago, kgsws said:

Eh, some expectations are getting too high. Higher resolution was just a question. It's not implemented.

honestly i don't really know what to expect, but i do keep being surprised by what is being added to this project. as far as the resolution, i misread and thought that it was implemented.

[termrork]

this is beyond awesome! imagine a future with a list of wads which are actually mods... you will not have to create a new source ports for your crazy ideas! I will mess around with it for sure!

 

also I made a little video about snake.wad and demo.wad (spoilers inside). you will be able to see it when it is fully uploaded (in ~1h, I will sleep now):

 

 

 

Edited October 14, 2020 by termrork

[TheOnlyTrueFenix]

OK so, for some reason, some textures are missing and the pistol looks weird when i shoot it

Spoiler

Spoiler

Spoiler

 

I'm playing this on dosbox and it looks like i'm the only one with this problem.

[Gez]

On samedi 10 octobre 2020 at 4:37 PM, ReaperAA said:

With that being said, I still think this a cool endeavour and would definitely like to see how far the vanilla .exe can be pushed (if only for my own curiosity sake).

 

13 hours ago, URROVA said:

Ehhh... WTF vanilla running an HEXEN FORMAT MAP, with thing specials and all xD 

It's not pushing the vanilla .exe, since it's using an exploit to run arbitrary code instead of vanilla code. It's really closer conceptually to a source port. Just a source port that has to be loaded by running the vanilla .exe first.

 

[THEBaratusII]

Uploaded a video demonstrating the WAD.