OSDev.org

somehow related (same picture two times but on different hostings) :
http://information2share.files.wordpres ... -games.jpg
http://i.zlowiki.ru/120704_4e0b8851.jpg

inb4: yes, this list lacks some great things, e.g.: Prince of Persia.

A Revolutionary DOS game might just work and people will buy compatible ancient machines just to run the game, by the way,
If You Believe This, I Have a Bridge I Want to Sell You.

It should be clear that this game will be played on a modern hardware also. Either as a native version or with an emulator. Except the enthusiasts that runs it on real hardware.

I am quite sure that you would try the game. Maybe just being curious to see how the silly idea is implemented. That is the catch of this.

Nable wrote:somehow related (same picture two times but on different hostings) :
http://information2share.files.wordpres ... -games.jpg
http://i.zlowiki.ru/120704_4e0b8851.jpg

inb4: yes, this list lacks some great things, e.g.: Prince of Persia.

That picture brings good memories. I have seen that before and I also noted that Prince of Persia is missing. Perhaps my favorite game by then!

I am now unactivating this project even it has not started. The basic idea still applies.

However, I am not to abandon the 16-bit MS-DOS programming entirely. I have already done some custom MS-DOS stubs for PE/COFF executables. Have you ever seen a program that uses this possibility to integrate two versions of the same program? I have only heard of the Regedit that comes shipped with Windows 9X or so.

If I have enough time sometimes, I may be keen to write a program that comes with a single compact executable that runs natively on MS-DOS and Windows. The data should be shared as much as possible between these two versions. Maybe I should set some artificial limit, let's say 4K, for the executable and see how much can be done with it. Maybe someone has already done a 4K demo that makes use of this.

Antti wrote:I am quite sure that you would try the game. Maybe just being curious to see how the silly idea is implemented. That is the catch of this.

Possibly. But if I had to buy it to try it out, I guess my curiousity wouldn't be big enough.

Antti wrote:I may be keen to write a program that comes with a single compact executable that runs natively on MS-DOS and Windows. The data should be shared as much as possible between these two versions.

The reality is that consumer do not care the file packaging technique as long as there is an installer (even better, do not require installation that it is directly executable and setup default value on first run)

By the way, stub, or file bundle, or whatever it is called, is not a new technology, and not PE/window's only.
almost every platform has its way to handle multiple ABI/system backend.

bluemoon wrote:The reality is that consumer do not care the file packaging technique as long as there is an installer

That's true. It would be done just for fun with no real benefits.

bluemoon wrote:even better, do not require installation that it is directly executable and setup default value on first run

I totally agree with this. I hope that this trend becomes more common in general.

A little bit offtopic here: I have always liked that the program comes with a compact stand-alone executable with no additional dependencies expect the ones that are guaranteed to exist on some system. This implies, that the shared libraries are not very much used. Whether this is good or not would be an interesting debate. No need to get tangled with that in this thread (that is reaching its end).

Sorry for a bit of trolling but i begin worrying that rdos wasn't summoned^W attracted by this topic.

Antti wrote:However, I am not to abandon the 16-bit MS-DOS programming entirely. I have already done some custom MS-DOS stubs for PE/COFF executables. Have you ever seen a program that uses this possibility to integrate two versions of the same program? I have only heard of the Regedit that comes shipped with Windows 9X or so.

There was something called RSXNT or RDXNT that allowed you to build dual-DOS-Windows executables with DJGPP. I used to play with it about ten years ago. Unfortunately the only information I can find are broken links.

IIRC the official linker from microsoft (that come with MASM) has a command switch for specify a stub, and the stub itself can be assemble with masm with a special flag.

iansjack wrote:

Hopefully you recognize overkills when you see them.

OK; good joke while it lasted.

You took all of us in, but enough trolling.

...? The man is clearly sincere...

This is wrong on so many levels I'm not sure where to begin. And trust me, I love DOS.
You're simply starting in the wrong end. You don't even have a game idea yet. Platform choice alone will not make it good. You should come up with a great idea that captures the retro look and feel that I suspect you are after. When you have that idea clearly formed, you can start thinking about target platforms. If you're lucky it might be feasible to release a DOS version, but maybe iOS or Android is better and more commercially viable. You'll just have to make that choice when you know what the game is about and it's target audience.

Antti wrote:To be somehow realistic, Windows-, Mac-, Linux-ports of this game are also released and they are developed concurrently with the MS-DOS version. Cross-platform libraries are not used and all the ports are native. This should not be hard to do if these requirement are taken into account from the very beginning. There might be little improvements in graphics and sound but the general feel of the game should resemble the native MS-DOS game.

Of course if you wanted it to be truly realistic, you'd have to write it for the Amiga first, then cut some stuff out and port it to the Atari ST, then cut some more stuff out and port it to DOS. Then make it all fit on 360K 5.25" disks like this one:

http://www.mobygames.com/game/dos/speed ... Id,242975/

bluemoon wrote:IIRC the official linker from microsoft (that come with MASM) has a command switch for specify a stub, and the stub itself can be assemble with masm with a special flag.

I did not understand the special flag thing you mentioned. Is there something special with the "special flagged" MASM compiled executable? I think that any MZ executable can be used as a stub and the MS linker takes care of the PE offset. However, I rarely use MS developing tools in my interesting (read: hobby) projects.

bubach wrote:This is wrong on so many levels I'm not sure where to begin. And trust me, I love DOS.
You're simply starting in the wrong end. You don't even have a game idea yet. Platform choice alone will not make it good. You should come up with a great idea that captures the retro look and feel that I suspect you are after. When you have that idea clearly formed, you can start thinking about target platforms. If you're lucky it might be feasible to release a DOS version, but maybe iOS or Android is better and more commercially viable. You'll just have to make that choice when you know what the game is about and it's target audience.

Foregone conclusion for me but thank you for this pleasant and polite feedback.

adsm wrote:Of course if you wanted it to be truly realistic, you'd have to write it for the Amiga first, then cut some stuff out and port it to the Atari ST, then cut some more stuff out and port it to DOS. Then make it all fit on 360K 5.25" disks like this one:

http://www.mobygames.com/game/dos/speed ... Id,242975/

Yes, that's the way it should have been done! "Comes with the 3.5" floppies" is very amateurish approach.

I would like to give some background information that resulted in this project concept that is the topic of this thread. Those of you how did not read the thread carefully: I already discarded (unactivated) this concept.

When I studied the PE/COFF executable format for my UEFI boot loader, I made my own tool to create a compact executable. Now I only need the "default" GNU toolchain to compile my loader with no support for the "UEFI PE/COFF" format. After I played with the format and created MS-DOS stubs (that are, by the way, very unnecessary there!), I became curious that it would be nice to try some MS-DOS programming also. I was attracted by the relative simplicity of the programming model where you can easily get "something done" very quickly. Not much code is needed to write some pixels to a graphic mode screen etc. Basically, you can start the actual programming very quickly without learning the boilerplate code of some library. In other words, the layer between the hardware and the software is very thin. In yet another words, you have to do everything by yourself. Easy to learn, hard to master.

Too bad that I was too young to start programming when these old technologies were new. Fortunately, there is well enough information available that I can now study.

To end up with the background story, I would like to give a simple question to those of you that have deeper knowledge of Microsoft technologies: why the default "universal" MS-DOS stub header says that the program contains three 512-byte pages with 90 bytes in the last one? Are these some kind of magic numbers?