Advertisement

Issue with Borland C++ 4 MSDOS code compiling.

Started by April 02, 2019 12:38 PM
94 comments, last by UnshavenBastard 5 years, 6 months ago
3 hours ago, 0r0d said:

Problem is that nothing you said are actual reasons why anyone should try to make a DOS game with Borland C++.  These are just rationalizations for doing something that someone decided to do just because they feel like it, because they think it will be fun.  And that's ok, but people have to understand that if they chose to work in such an old and buggy system, then they're on their own and they're in for a world of hurt and frustration.

While I agree with you, I want this experience so that I can figure out the way that graphical programming was done, and I how I could translate DOS code to, say, OpenGL code easier...

3 hours ago, 0r0d said:

Problem is that nothing you said are actual reasons why anyone should try to make a DOS game with Borland C++.  These are just rationalizations for doing something that someone decided to do just because they feel like it, because they think it will be fun.  And that's ok, but people have to understand that if they chose to work in such an old and buggy system, then they're on their own and they're in for a world of hurt and frustration.

While I agree with you, I want this experience so that I can figure out the way that graphical programming was done, and I how I could translate DOS code to, say, OpenGL code easier...

Advertisement

I'd like to help you. From what I can tell you are building an entirely 16-bit x86 real mode application? But you are faced with assembly code in one module that forces you to use protected mode? Can you provide more details on what you are specifically stuck on? Is that module a true 32-bit protected mode or 16-bit protected mode? What DPMIs have you tried? I know you are interested in legacy, but attempting to support 80286 and below processors is pushing the boundaries of legacy somewhat, since we are in 2019 :) If you could perhaps change all your code from 16-bit real mode to protected mode and then use a DPMI you'd be less legacy (but still 2+ decades old). I actually still have a few programs of my own that only run under DOSBOX and use the DPMI supplied in DJGPP's setup (this is what I recommend you pursue next).

Btw, 16-bit x86 real mode applications are still supported on 32-bit Windows or in 64-bit Windows under DOSBOX. If you can find a 32-bit piece of hardware, you can run your code natively, otherwise you need to run under DOSBOX.

11 hours ago, yaboiryan said:

While I agree with you, I want this experience so that I can figure out the way that graphical programming was done, and I how I could translate DOS code to, say, OpenGL code easier...

So what exactly are you doing?

Is it to learn how programs worked in DOS  and similar systems? Because that is nothing like modern Direct3D, OpenGL, etc. It is definitely worth knowing, but it is a different style as you had much more direct hardware access plus older features due to the use of 16bits and the need for more than 64KB of memory (essentially a non-problem for almost all 32bit software, and basically everything in 64bit allowing the use of a "flat" address space). Also like I said, C and assembler were common (both still useful skills).

 

If you can't get an actual DOS machine to use, you can use an emulator to run such programs.

There really is no transition from MSDOS graphics programming to anything modern (say 2005 onwards being "modern").  You'd be FAR better off just learning modern day graphics programming.  You will really get no usable knowledge from learning 16bit MSDOS coding at all, in any modern realm of coding.  You're free to do whatever you want, but realize it's likely just a play project with no real world application.

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

On 4/9/2019 at 5:17 PM, CrazyCdn said:

There really is no transition from MSDOS graphics programming to anything modern (say 2005 onwards being "modern").  You'd be FAR better off just learning modern day graphics programming.  You will really get no usable knowledge from learning 16bit MSDOS coding at all, in any modern realm of coding.  You're free to do whatever you want, but realize it's likely just a play project with no real world application.

I want to learn old programming because I have to overcome more hurdles. This is true when using assembly. It is such a difficult language to learn...

Advertisement
14 hours ago, yaboiryan said:

I want to learn old programming because I have to overcome more hurdles. This is true when using assembly. It is such a difficult language to learn...

I'm sure we can find you modern, useful hurdles to overcome that are more difficult to learn than x86 assembly.  For example, a low latency game engine written in C++ for Vulkan would be both harder and far more useful than playing with DOS extenders.

If you want to raise the bar even further, just do something bleeding edge with that modern technology, like juggling millions of particles or pushing simulation logic into compute shaders.

Omae Wa Mou Shindeiru

17 hours ago, yaboiryan said:

I want to learn old programming because I have to overcome more hurdles. This is true when using assembly. It is such a difficult language to learn...

No more so then most other languages.  There are rules, once you learn the rules and the major functions you're set.  But again, is this for a hobby?  Because if it's for experience for future work you're barking up the wrong tree.  And if you're going to learn assembly, at least learn modern assembly, not 16bit.  I've not really read all your replies here and it's your time to absolutely waste of course, but I fear that is just what you're doing.  If you need help you might be waiting days or weeks for replies to questions.

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

I just want to program a FPS game. I was using techniques from the book Programming A Multiplayer FPS Game with Direct3D, but the punk author copyrighted his code, which is not cool, even though I bought it.

some people.

34 minutes ago, yaboiryan said:

I just want to program a FPS game. I was using techniques from the book Programming A Multiplayer FPS Game with Direct3D, but the punk author copyrighted his code, which is not cool, even though I bought it.

some people.

This is such a colossal waste of time, but that's fine. You do you. But at least have the decency to not castigate someone else for protecting their code under licensing or copyright. Write your own code.

Some people.

This topic is closed to new replies.

Advertisement