[mike_s]

Original Title: The return of original Duke Nukem 3D for DOS (with internet mode)

....Oh, I finally get to make a post now after a song-and-dance registration process.... anyways....

As you know this is the year 2021 and we are in the covid season where many people are home more than ever before and are told to social-distance. So I figure, why not bring back the original Duke Nukem 3D back to life and run it network style so players around the world can play?

The interesting news is some people have reached that stage because they use Microsoft Windows and a port designed to run for that system such as Eduke, or they use a program that basically takes over the duke nukem executable and runs it as if its duke nukem.

The sad news however is people who don't use windows (such as me) will not benefit. What's even sadder is that people who only use DOS and no windows will not benefit at all Because of this, I have an idea, but I'll get to my skills first then to the proposals:

Skills

I was trying to make a complete HTTP server for MS-DOS for another project. The great news is I was able to make an ARP server, and I can process IPV4 packets. I may be able to process UDP packets as well (which will be enough to run multiplayer games). How was I able to pull this off? With minimal quick basic and heavy assembly. I even learned the crynwr packet driver interface.

Idea 1 - DOS port
One idea is to use my skills to make a DOS port to use with the network connector (like yang). I did manage to pull this off in the past a few years ago by utilizing Quickbasic, assembly, and winsock routines (for windows 95). It was crazy, but it worked. I do have pieces to the code but I'm not supporting windows now. Now if I do roll this off, then all computers that are capable of loading DOSBOX and those who can connect it to their network as per network instructions set out here dosbox networking instructions can use my port without any special host OS configuration.

Idea 2 - DOS network suite
Since I haven't quite figured out TCP yet (since my troubleshooting with it is a pain), this idea may be more difficult to roll off if I use TCP for connectivity purposes, but it would be an entire network package. Just think game connector (like yang) plus port all in one and all in DOS without the need of anything special. Heck, someone with an old CGA or EGA monitor could benefit from this.... (well at least until the players are ready to play the game because after that, duke would look funny. lol)

Idea 3 - DOS port with dedicated server
Not sure how well this would roll off, but since I'm still onto pure DOS mode, this idea would require one to install Arachne web browser as that is the best MS-DOS web browser out there. Then they connect to a dedicated website that lists all the active duke nukem players and one would click "join" to join the game and the game host can click "start" on the webpage and then all clients will automatically have their DOS port loaded and duke nukem started at the same time. This will require some work (at least with how the web browser handles extensions), and this will require someone to make their computer as a web host all the time.


Based on everything, I may be able to join a game with me pulling off idea 1, but I was wondering if others would be interested in playing Duke Nukem 3D completely in MS-DOS mode (no windows) and with networking support, (or at the very least, playing Duke Nukem 3D in DOSBOX with dos packet driver loaded).

Now if we did all connect in real MS-DOS mode, then the lagging will only be limited to the quality of the network itself, and we have no other software to blame because windows isn't running in the background.

What do you guys think?

[High Treason]

We (me and people in my Discord, as we're into DOS systems) actually played with tunneling a few years ago but couldn't get it working very well - at best, we could get a game going, but it would stall like hell. We tried everything from a tool called 'GIT' to me running layer 2 tunneling servers to make up a VPN. Turns out most tunnels don't like routing IPX broadcast traffic.

At the very least, I suppose people in such communities would be interested in something like this. I'd certainly want to play it and suspect a few other people would. I can't help you with code or anything (trying and failing to re-lean C, think learning CON has erased this information from my brain and it's hard to stuff said information back in.), but if you develop anything and need help testing it, I certainly don't mind doing that, given I have at least 15 MS-DOS computers on hand at any given time and always like having excuses to plug them in... Although I suspect the 286-6 will be largely useless and I'd be throwing such tasks at the overworked Pentium again, haha.

[mike_s]

High Treason, on 10 April 2021 - 03:07 PM, said:

At the very least, I suppose people in such communities would be interested in something like this. ...but if you develop anything and need help testing it, I certainly don't mind doing that...

Cool. I noticed you run a website.
I was thinking if your server package included unlimited bandwidth then a website could be built on it that which can show active players and functions like a network connecting client (similar to dukematcher) so only thing people need to download is just the port and then the website launches the port program when all players agree to start the game. Something like that.

The bandwidth requirement comes in because people can refresh the page any time to see who is in and what rooms are free etc.

[mike_s]

Original Title: How player info is passed from duke connector to the port

Sorry if the title of the question appears offensive.

But I'm making my own game port and effectively replacing the commit.exe that comes with duke nukem 3D so that people can play against people worldwide instead of being restricted to their local LAN.

What I discovered based on commit source documentation (found by searching for and downloading dukenet.zip from 3D realms site) is that when the game wants to communicate with players, all the commit driver will know is what data goes to what player number, but it doesn't go past defining what the player number really means.

In my case, my driver will have access to the entire network packet. (Heck, I could make wireshark for MS-DOS right now if I wanted to). This means it can access the MAC address and IP address and port number. Because of all this level of access, In order for me to send a packet successfully, I'll need to make the driver determine the remote MAC address, remote IP address and remote port as these three things combined will determine the player number.

Here are my thoughts on how to approach this situation for when a new multiplayer game starts, but I don't know if any of these thoughts match the approaches other ports would take:


Thought 1: Pass all info in as parameter to driver

This will be the easiest to implement at my driver end. Data could be encoded for security and speed purposes by the multiplayer chat software then my driver could decode it. The drawback is that I don't think any networking software related to Duke Nukem would capture MAC addresses.

Thought 2: Pass IP address and Port only

The disadvantage here is the need to issue broadcasting MAC addresses (FF:FF:FF:FF:FF:FF) when trying to retrieve the true mac address. More like doing an ARP/RARP request. Question is how well would routers deal with this.

Thought 3: Pass No info

While this may be most secure, it will be more difficult to implement, and for it to work, there needs to be a central server to connect to in order to collect all the info for the game.


Then again, I could make my software compatible with all the duke nukem network clients out there like yang if I knew the parameter format they pass to duke nukem 3D. Maybe the format is customizable from client to client I don't know but if I can adapt to a common format, then my port would work with the rest of the ports, except that mine would allow the real dos duke nukem 3D to run network style.

What do you guys think? Should I go with one of my thoughts? or should I follow a common format?

[mike_s]

Original Title: A special Duke Nukem 3D server that connects people to real duke nukem

Some of this may be wishful thinking but it can probably become a reality.

In the past people needed to use a few clients just to play Duke Nukem 3D: a chat client, and a port.

Now wouldn't it be nice if everyone from different generations (including people with older computers) can all come together to play Duke Nukem?

I am close to reinventing commit.exe for Duke Nukem which allows you to play duke nukem against other players on UDP/IP, not the old IPX. Once that is done, I will try to include TCP/IP so custom game maps can be downloaded as needed to ensure all players have the exact same map when playing.

Now if everything pulls off nicely, then somehow I gotta get a web server with FTP and shell access (for free) that people connect to for map and driver access and so people can see who is online and actively playing, etc.

If everything pulls off perfectly, then the hard-core DOS users with good monitors will be able to join simply by downloading the arachne web browser and searching for open lobbies with it and then they can click on a lobby, then the commit driver will load and when all players are ready, the game will start!

Speaking of hardcore DOS, that would be the FASTEST environment if people make use of XMSDSK memory manager and load everything from that.

Arachne can be downloaded here: Arachne web browser

And those who want to run Duke Nukem the fast way, you can get XMSDSK from the package explained here: XMSDSK info or just get the file in this archive: Here. When xmsdsk is loaded, copy all the files onto it then run duke3d from it.

For XMSDSK, at minimum, you need to load himem.sys in config.sys then load xmsdsk in autoexec.bat.

[William Beavis]

Would love to see this come true. Not a bad idea.

[mike_s]

Original Title: A test-bed server for my new COMMIT driver

I'm close to making my COMMIT driver ready for DOS Duke Nukem 3D.

But what I want to do is TEST like crazy.

Once my driver is done, there will be two files in one package for people to download:

1. An MS-DOS TSR that loads essential components into memory.
2. the COMMIT executable itself that launches Duke Nukem 3D in network mode.

Then my driver will expect to feature the following:

1. Each user can select his own port to use. (you still may need to enable port-forwarding in your router). The port number does not have to be common to all users.

2. When the driver loads, it checks to see if user has required map and if it doesn't, the map will be downloaded. I will include a setting where a user can define the map download folder so other maps elsewhere won't be overwritten.

3. I may include network buffering options which utilize XMS (extended) memory. This will come in handy to users that run tons of other applications in the background that slow down the system at the same time.

4. Possible custom data chunk transfer sizes. This is very useful for those few players that may be still on a dial-up connection (or that uses a dial-up connection somewhere in their internet path).


In order for map downloading to work successfully, I'm looking for a test server to try to download map files from with my driver. I'm looking for one that won't label my computer as a spammer just because I accidentally issued a wrong command. it would be nice if the server has an option that allows me to restart it incase a wrong command makes it crash.

In the meantime I'm going to try local emulated servers and at this time I'm using netcat. then I may use something else, but eventually I want to run tests on the internet.

[mike_s]

Original Title: COMMIT replacement plus multi-map experience

Anyone who has browsed these forums within the past 45 days may know that I have been reinventing the COMMIT driver for the DOS Duke Nukem 3D so it can work in many more environments.

The good news is I ended up getting TCP working in the driver, however, I needed the help from another driver, NTCPDRV. That is the Trumpet TCP driver for DOS.

I ended up downloading the google home page and comparing it to a duke nukem map, the speed is decent. For me, given my computer is last generation, it took about 7 seconds to download the google homepage, so downloading a complex map may take that time at tops.

So one thing I'll have as an option in my driver (provided there's a server for it) is for the same game map to be downloaded to all players just before the game starts. This is why I wanted to include TCP/IP capabilities in my driver.

And check out my NEW THOUGHT... Multiple matches across several maps without returning to the host OS. What this means is that players can agree on several maps to be played, then the driver downloads the correct maps all in order for every player so each one has the exact same set of maps. Then for each map, Duke Nukem 3D is started. Then when players exit the game, then Duke Nukem is started again, but this time, for the next map. And the process continues until every map has been accessed.

That's my thought. Back to the driver story...

The only thing now is a bit more configuration will generally be required to make everything work together but I am working on minimizing that as we speak so the package can run "out of the box".

Best of all, everything will work well in MS-DOS mode.
I'm testing everything in DOSBOX 0.74.
Then I'll test it on a LAN without IPX protocol because I don't think anyone uses IPX anymore.

[High Treason]

Ah, I knew I'd forgotten to get back to someone somewhere, haven't had much free time.

So, servers. I'd have gladly let you use mine if it were suitable, but unfortunately it'd require an entirely new VM and it doesn't have the resources left for this. It'd be running IIS so would use ASP rather than PHP, databases would have to be flat and FTP would be on an unconventional port at an extremely low speed, as would web services. As it is, though, the server already has a hard time and cannot be upgraded any further, no ram for further VMs for a start. Hopefully you find a suitable one somewhere.
In any case, I'm glad to hear progress is being made.

[mike_s]

High Treason, on 19 May 2021 - 02:32 AM, said:

It'd be running IIS so would use ASP rather than PHP, databases would have to be flat...

If you could configure your server to run MS-DOS executables, I could make an even flatter database in the executable itself and run that as if its a PHP file. Given that you'd be running IIS, I bet you'll meet the requirements of my DOS EXE's (MS-DOS 5.0+)

Quote

and FTP would be on an unconventional port at an extremely low speed, as would web services.

Thats fine for the initial stages, but if this becomes popular, then either the web speed will need to be faster or I'll have to impose some access (to the server) limits to the server in my driver, but that will cause the user experience to be slow between the time the driver is started and the time duke nukem itself starts.

Quote

As it is, though, the server already has a hard time and cannot be upgraded any further, no ram for further VMs for a start.
Hopefully you find a suitable one somewhere.

Serving the server pages in itself won't need much processing power since I can program things in old-school. The only thing if I make it look pretty is the browser doing an occasional image download for new clients since browsers can cache pages. That would use a few hundred KB each time, but for the pages themselves, I can guess a few KB. I factored in player names and internal headers.

However, the part that will use bandwidth the most is map-synchronization because there's a chance in many games where the host wants everyone to play a specific map of a specific version and no other players have the correct version so that means all the remaining players would automatically download the same map (simultaneously) from the server. But I can also make it where each player takes its turn to download a map but that would make the experience much slower. Another way to reduce bandwidth use is to limit the filesize of each map.

I'll explain why as an example...

Say there is no limit to the map file size and a game starts with a 300 KB map and 8 players.
Assume only the host has the correct map and correct version.
This means the remaining 7 players must download the 300 KB map. That's 300 x 7 = 2100 KB bandwidth used (excluding internal headers of roughly 2KB a player). So grand total, about 2114 KB.

Now if we limit the map size to 50 KB a player and the same scenario above exists, then 50 x 7 = 350 KB of bandwidth only used.

So there are workarounds and ways to things but we gotta balance the user experience with game server resources available.

[mike_s]

Since one guy on here reported that he has a computer (virtual machine?) with limited resources, I'm just curious as to what I should set XMS memory requirements to for my driver.

XMS is short for eXtended Memory Specification which in short is the common memory we all refer to.
My driver can require as much as 64 MB memory as a high limit due to how himem.sys (the DOS memory driver by Microsoft) is implemented.

If I make the requirement high, then I can cache data quickly. This is beneficial to people with computers that are too slow to handle the speed of the incoming network data. Also, I can slightly increase the map download speed since it will be downloaded to memory first before to disk. (Heck, with the help of a 3rd party driver (XMSDSK) in real DOS mode, one can bypass the disk thrashing altogether.)

For now I think 8 MB will be reasonable, but if there is a better number, I'd be open to it provided there's a good reason.

[mike_s]

NEWS as of May 22nd

This might be a DOSBOX issue, but something funny happened with XMS ram and the trumpet NTCPDRV driver while I was testing my driver. so some disk churning might be unavoidable without a special DOS setup, HOWEVER, it is still possible as a user to run everything off of a RAM drive. I don't think Microsoft Windows has native support for a ram drive (maybe except for windows 9x and older which is already obsolete by Microsoft because windows is now at version 10 I think, but I stopped using windows as of a few years ago).

Nevertheless, the map downloading through the driver is modest, but given the funny nature of DOSBOX networking, sometimes a connection wont start. This might be strictly a DOSBOX problem but I am working on it.But then again, a map download is only necessary if you don't have the correct version of the required map.

Now if I could get some sort of server (someone here might be already offering one) that can just serve dynamic pages and can store map files then I can be all set and run tests on that server.

[mike_s]

Time to test the tough networking

Can't believe a few weeks have gone by. Anyways, I managed to get successful more times than not with downloading HTML data via my driver testing.

Now, my next step is to try to download game maps while correctly reporting the download progress from various servers. So if anyone who hosts game maps see in their server logs a user agent named "old-software" then that is me testing to see if I can download a map from your server that's accessible to the public.

Since the driver I am making is for DOS, the final server in the end must be able to satisfy all of the following:

Access via IPV4 (Standard IP addressing of xxx.xxx.xxx.xxx).
Map must be accessible via HTTP protocol, not HTTPS. HTTPS means I have to do certificate coding and many certificates will probably need purchasing anyway.
Protocol must be HTTP version 1.1. version 1.0 might work too. but HTTP 2.0 (spdy) will NOT work.

And it would be nice if the server can spit out the CONTENT-LENGTH HTTP header so my driver has an idea on how much storage space the map needs. It makes some users sad when they see no progress bar going across for a large download. Well, I know duke nukem map files are not that large, but I'm just saying.

[mike_s]

NICE NEWS

Well I have nice news and somewhat of bad news.

The Nice news is that downloading maps continue to work with my driver.

The somewhat bad news is that the download speed and possibly game speed may be currently capped to a low value.

Those running in Real DOS mode (no windows) will be the luckiest

A packet driver controls all the networking. Anyone who runs Duke Nukem from DOS mode will be luckiest if your network card uses an RJ45 jack and you connect to your network in a wired fashion. You can get speeds up to 10/100/1000Mbps. and download of the maps will likely be FAST.

Those running in 32-bit windows might be lucky

There is a utility invented that is compatible with many 32-bit versions of windows that allows its own DOS box to see that a packet driver exists. If you are lucky, you will get great speed. Here's the link to the driver: Packet driver for Windows

Those running in other OS's might NOT be lucky

I currently run DOSBOX in Linux for all my testing, and after tweaking with settings, the max speed I can currently achieve for gaming is about 11KB/s. This is because dosbox can connect to the outside world via its virtual serial port so that acts as an internet tunnel via the linux PC. The linux PC is the software router with NAT. Also, there are two utilities that need to be used for proper operation but they limit speed. slattach for linux and ETHERSL packet driver for DOS. Both limit virtual serial port speed to 115200bps (or 11KB/s). The former utility could be hacked for higher speed, but ETHERSL needs a re-write to achieve higher speeds in DOS mode if that is even possible.

The only other option with the DOSBOX setup is that I hear of a megabuild that comes with a packet driver interface already setup but I never tried it and the last place I saw it available for download is via internet archives with a notice that the package has NOT been tested for viruses.

If theres another DOS emulation system that works for my computer I could give that a try. Qemu used to work until I upgraded my slackware then that didn't work anymore. Plus my computer is old and 32-bit. Anyways, I'll continue and who knows, Maybe Duke Nukem 3D for DOS doesn't even need an ultra fast internet connection for gaming to happen.

Come to think of it, does anyone know the bandwidth requirements for DOS Duke Nukem when it comes to playing on a network?

[mike_s]

MICROSOFT PULLED A STUNT

Before I begin, I'll say that I use two programming languages for coding. Quick Basic and assembler, supposedly for ease of use and to integrate advanced functionality.

Well, I got some sad news and okay news.

The sad news is that I relied on Microsoft Quick Basic to make production faster, however the damn compiler decided to corrupt my code to the point that I have to start that section over, and its a big section In fact, the code got so corrupted that when I loaded it in another editor, the code went from a small amount to over 300,000 blank lines.

The good news is the assembler code remains intact.

I'll probably have to code almost everything in assembler.

So the estimated completion date is now unknown

[mike_s]

COMING SOON (Online testing)


I did manage to secure web space from my friend's server however it may not last forever, so I'll eventually need a better server afterwards. So I figure, I might as well now describe how the whole thing will work and how it will work with EVERY operating system including MS-DOS!


First, the lobbies.

These lobbies will be delivered as HTML pages on HTTP protocol that aren't meant to be cached for a long time. If you are using pure DOS, then I'd recommend you grab yourself a copy of Arachne web browser 1.70 and set that up while you are waiting along with your packet driver because you'll need that too.

You will be able to name the lobbies you host, set the maximum players as well as the game files necessary to start the game, and the location of the files. AND get a load of this: The driver WILL support ZIP files. Why zip? because some players create maps that won't work unless other game files are modified. So its much beneficial to zip them up and make it one download.

Also, the lobby host can make the lobby a private lobby where only certain players are allowed to join.

Players can set their names as well.

Then the driver...

This is where things get really interesting, and the process is completely dependent on your host operating system for the game.

If you're using DOS and arachne, the process will be so seamless, that as soon as you are ready to jump into the lobby, the commit driver loads inside duke nukem and waits for other players. Heck, if you really want to crank up the loading speed, then you need to make a ramdrive with XMSDSK.EXE utility and throw all the duke nukem files (and even arachne browser) on that.

If you are using some other operating system (most of us), and you use a DOS emulator, then a special config script (specific to the game session) will need to be executed that co-aligns with the script necessary to start the DOS emulator and the driver within it.

I intend to support both DOSBOX 0.74 and DOSEMU 1.4.0.0 for emulators.
If you use any other DOS emulator, I could possibly incorporate the functional driver into it as well.

I did make the driver in the past support Windows 9x but I don't think anyone still uses Windows 9x anymore so for now, I'll ignore those operating systems.

Also, anyone that's excited right now, just know that you'll need a computer with a 486 or newer processor along with at least 2 MB XMS memory for slightly faster download speed (because disk access is slow).
My driver won't support systems having processors older than the 486 because of the instructions the code uses to execute certain tasks, and running my driver on those older processors may produce unpredictable results.

Stay Tuned....
I'll provide another update when I have the web interface done. It will have further instructions.

[NY00123]

I saw your other threads related to the driver beforehand. While I currently don't expect myself and many others to use the driver any time soon, I think it's impressive that you still have the motivation to continue working on it. Then again, I realize that there are many other examples,

What this reminded me of was the following thread from 2008: https://forums.3drea...ead.php?t=32416

[mike_s]

NY00123, on 08 July 2021 - 09:18 AM, said:

I saw your other threads related to the driver beforehand. While I currently don't expect myself and many others to use the driver any time soon, I think it's impressive that you still have the motivation to continue working on it. Then again, I realize that there are many other examples,

What this reminded me of was the following thread from 2008: https://forums.3drea...ead.php?t=32416

I also used mik3ca as a username believe it or not. While I skimmed the board now, I think that was me highlighting my driver back then which was just for windows. At that time, I made use of Windows sockets in my driver. But this time, I'm going beyond that so that people without windows will be able to play. And who knows, maybe my driver will be a hit since I heard that people are beginning to be interested in older computers again, and they may be selling at high prices.

Speaking of which, I just found a listing on Ebay: Right here. This 286 which is too old for Duke Nukem.... the seller wants $600 USD and charges for shipping. For me in my area of Canada (East), the price is a whopping $750 + $201 shipping + about $100 import charges which is roughly $1,000 for an old complete 286 PC.

I'll continue

Anyways, I'm continuing on this driver and I'm even making setup wizards so people can make very few clicks and/or button presses in Linux or DOS so that installation is a breeze. As for windows, I may have to tweak some files since I stopped using Windows since XP.

The bottom line

I'll get to the bottom line in another thread since it's not specific about the driver.

[NY00123]

mike_s, on 10 July 2021 - 09:58 PM, said:

I also used mik3ca as a username believe it or not.

I was almost sure that the 3DR forums poster was the same individual, heh.

Quote

While I skimmed the board now, I think that was me highlighting my driver back then which was just for windows. At that time, I made use of Windows sockets in my driver. But this time, I'm going beyond that so that people without windows will be able to play. And who knows, maybe my driver will be a hit since I heard that people are beginning to be interested in older computers again, and they may be selling at high prices.

What I think that eventually matters the most is ease of use. The need to forward a port or two is a great obstacle, especially in instances where it's simply impossible for the user.

Let's see what can we get as the time is passing.

[mike_s]

NY00123, on 11 July 2021 - 11:56 AM, said:

I was almost sure that the 3DR forums poster was the same individual, heh.



What I think that eventually matters the most is ease of use. The need to forward a port or two is a great obstacle, especially in instances where it's simply impossible for the user.

Let's see what can we get as the time is passing.

I think port forwarding is something out of user's control unless they have administrative rights to their router connected to the internet or to the internet. Its a security thing. There's a possibility that port forwarding isn't required at all, but I'll have to keep working on the driver and see.

[mike_s]

BREAKING NEWS

I just did some MORE discoveries and it turns out my commit driver may even be compatible with ALL emulators and ALL systems that support the DOS network packet driver specification. Dosemu has one built-in. Dosbox can generate one via serial port slip emulation in linux, and Virtual box will probably have one built-in as well and the last emulator is probably the only free one that works in 64-bit windows.

Having said that, I just may be able to make a magical file that works with all emulators.

Basically, its a hard drive partition with Duke Nukem shareware edition and necessary drivers (including mine) to get it up and running in network mode, plus the partition will have a special tag value embedded into it so when it comes time to connect to the network, the network will then know who is who. Also, these images when run will automatically start duke nukem so the limits are really based on what constraints you put on the emulator configuration itself.


So for most people (that don't want to go to dos-only), this is what shall happen:

First, The user will need to download a DOS emulator.

Then the image (I'll make) with shareware duke nukem and drivers is to be downloaded. File size may range from 10 MB to 32 MB which is packaged in a self-extracting zip file. The package contains the image itself, a lobby parsing utility, and a setup program.

Because I'm designing this for hard-core duke nukem gamers and for the people who are completely computer illiterate, my setup program intends to find the first dos emulator it thinks you have then configures the parsing utility to reference it when starting the emulator.

Now since I hardly used Windows 10, some settings at your end may be necessary, primarily the knowledge of your local IP address and gateway so a connection can be made. I think this information can be reached in a control interface in that OS. I know when I used Win9x back in the day that the settings were under "network settings" in the "control panel". Another way I think one can determine this is to execute a command prompt (run CMD app) and type "ipconfig /all".

The parsing utility will handle the tiny downloaded files when you select a lobby to play in. Each download is less than 100 bytes, so the delay should be in milliseconds, even on the worst connection (unless your internet signal is literally cut). The parsing utility then takes the download file, translates it and injects it into the image so the image has the updated tag, then your emulator is launched with the image and the game will then start.

So far, I tried 32-bit windows programming with Dev-C++ and while some functions don't work, some others seem to work ok so I may pull off an installer in that. I will apologize in advance if you expect fancy windows. The only thing fancy you'll get out of all of this is the Duke Nukem game itself when it launches in the DOS emulator.

I'll keep at it and hopefully everything will work out for ALL operating systems in existence (except for dos 5.0 and under). Anyone using straight DOS should upgrade to at least DOS 6.22

And if you want to modify the images to replace duke nukem with the full version, accommodation can be made for that too but for simplicity, the image size should be 32MB or under.