Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Stygian

8086 C Programming Weirdness

Recommended Posts

So, I've been tinkering around with some C source code for a DOS program from the early 90s and, in the process, I've come across some types of pointers that I never knew existed. The program was intended to be compiled using Turbo (Borland) C++ 2.0 for use with Intel 8086 compatible computers operating in real mode.

So far I've encountered "far" and "huge" pointers and I've been able to find information on these pointer types, but, occasionally, I run into "seg_" pointers. Are there any experienced C programmers here who know what the significance of this pointer type might be (for instance, "void seg_ *pointer;")? More specifically, how many bytes in size is such a pointer?

[Edit] It's _seg, not seg_.

Share this post


Link to post

I'm going to guess those the upper 16 bits of a far pointer. It's fairly common for arrays to be aligned to a segment so that pointer arithmetic works like expected. This means the address of the first element of the array will always have 0 as the offset so there's no need to carry around a 32-bit value.

Share this post


Link to post

@Blzut3
Sounds plausible. Thanks for the info. As I dig deeper into the source code, I keep running into increasingly low-level, 16-bit memory management-related stuff, including inline assembly.

Share this post


Link to post

(Un)fortunately, inline assembly still happens, usually marked by some #ifdefs that miraculously know the current CPU configuration.

Share this post


Link to post
Blzut3 said:

I'm going to guess those the upper 16 bits of a far pointer. It's fairly common for arrays to be aligned to a segment so that pointer arithmetic works like expected. This means the address of the first element of the array will always have 0 as the offset so there's no need to carry around a 32-bit value.

Hey, why didn't you link to this thing you wrote? It seems like this thread was the perfect place for a plug.

Share this post


Link to post

Gez said:
Hey, why didn't you link to this thing you wrote? It seems like this thread was the perfect place for a plug.

Actually, the project was I was working on was to create a Windows port of Hovertank 3d, but it looks like Blzut3 beat me to the punch and, furthermore, he's partly responsible for the source code being released in the first place. Had I known, I would have looked for something else to work on.

I still think the blog is interesting. There really needs to be a definitive guide to porting 16-bit DOS programs to modern operating systems.

Share this post


Link to post
Stygian said:

I still think the blog is interesting. There really needs to be a definitive guide to porting 16-bit DOS programs to modern operating systems.

Well, as long as DOSBox is unsatisfactory, sure.

Share this post


Link to post
printz said:

Well, as long as DOSBox is unsatisfactory, sure.

I find running things in DOSBox very unsatisfactory compared to a native program.

For one thing, it is much slower since it emulates a CPU, video card, sound card, etc....

For another, file system is limited to a certain directory (which is good, I don't want DOS programs able to mess up anything else on my system), but a pain when some file you want to access is somewhere else. Also limited to the 8.3 filenames of DOS.

Share this post


Link to post
andrewj said:

For one thing, it is much slower since it emulates a CPU, video card, sound card, etc....


In theory, software like Oracle VM or VMware should be able to "virtualize" DOS, using only a thin layer between it and the host OS and cancel out those overheads. However, this doesn't work out so well for games and real-time stuff:

I once tried to run Doom in a DOS 6.2 setup in an Oracle VM, only to discover that while the CPU emulation (actually: virtualization) was infinitely faster than DOSBOX, however the VGA and sound emulation were MUCH slower. DOSBOX is really a compromise between a thin virtualization (on a x86 host) and a full-fledged emulator, optimized heavily for VGA and sound card emulator.

If all you need is raw CPU power from a DOS program (e.g. scientific software, old accounting apps and the such) and "correct" behavior for stuff like Windows 3.1 (DOSBOX is notoriously unable to run it), but not necessarily good VGA speed or sound, then a virtual machine might be a better option. But it will almost certainly suck for games or any non "clean" programmed stuff.

andrewj said:

For another, file system is limited to a certain directory (which is good, I don't want DOS programs able to mess up anything else on my system), but a pain when some file you want to access is somewhere else.


Nothing prevents you from mapping your local C:\ drive to be C:\ also in DOSBOX. Of course, it's your responsibility if you end up making everything FUBAR...

andrewj said:

Also limited to the 8.3 filenames of DOS.


Well what did you expect? It's DOS, after all (or it tries to behave like it). If you needed a sort of "better DOS" with frills such as long filenames, FAT32 and USB support, you should try FreeDOS (ofc, running it in a VM intended for "productivity" will almost certainly have poor results for games).

Share this post


Link to post
Gez said:

Hey, why didn't you link to this thing you wrote? It seems like this thread was the perfect place for a plug.

Well it doesn't directly answer the question of what a seg pointer is, but I suppose I should have.

Stygian said:

but it looks like Blzut3 beat me to the punch

I haven't touched Hovertank, so I didn't beat you to it. Although the person who owns the rights to the game is (it's no longer Flat Rock).

I know someone in the ECWolf IRC channel was considering working on a Catacomb 3D port, but I don't know if that will actually happen. As far as I know no one is working on porting Catacomb 1 to my CatacombSDL project. It should be fairly easy to do, the trick is finding the differences between the two games. (Which are minor since Cat2 was basically a C port of Cat1.)

Maes said:

Well what did you expect? It's DOS, after all

Given the premise was that running the games under DOS is undesirable for that reason, I'm not sure what your point is here.

I agree with andrewj, emulation is always undesirable compared to a native binary. Be it DOSBox, Wine, general purpose VM, etc.

Share this post


Link to post
Blzut3 said:

Given the premise was that running the games under DOS is undesirable for that reason, I'm not sure what your point is here.


We are talking about DOS games running either on real hardware or an emulator, right?

Unless there was some magical, yet 100% DOS compatible environment that would somehow make DOS games able to use more than 8.3 filenames that I'm not aware of. OK, there were those "Windows 95 aware" late DOS games and apps which could presumably use FAT32, but those were coded specifically to support that.

Share this post


Link to post
Maes said:

We are talking about DOS games running either on real hardware or an emulator, right?

No we're talking about running games released for DOS as released (emulator or with real DOS) or via a source port (native).

No one denies the reason that the limitations are there, we just reject that DOSBox is a satisfactory solution when the option of a native source port is there because they don't suffer from those limitations.

Share this post


Link to post

@Blzut3

I managed to make Hovertank compile and link using the method described in your blog. So far, if you pass "/VER" as a command-line argument, it prints version info and quits, but, other than that it prints a "FIXME" and fails an assertion. Since I am a novice and a student programmer, I do not know if I will be able to port the game in a timely manner (you may have gotten around to porting it yourself long before I am ever done), but it's still a fun challenge for me.

Porting Catacomb 1 to your CatacombSDL port sounds interesting as well.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×