wrote:wrote:Programmers, can one of you start working on the basic framework of the code?
🤣
You sound like my project managers - "Progammers, go do stuff"
Haha. I know the feeling.
wrote:Actually, I had this as well. I was so eager to start writing something I did not think first. I picked the tools that are simpl […]
Actually, I had this as well. I was so eager to start writing something I did not think first. I picked the tools that are simply not pleasant to work with. I used Turbo C (the freely downloadable version from Borland Museum), and I just began the coding, running the Turbo C in DosBox. But I did not think first if that was the right C compiler, or even if C language was right for this. I had to learn how to call BIOS interrupts in Turbo C, while these would have been better as inline assembly routines (can't do that unless compiling from command prompt). I ended up with just some functions that are not well structured or anything; it's just spaghetti code that does the job 😀
Oh and having Turbo C manage a project with multiple C source files, I still don't know if there's a button to rebuild all the C files and link the executable. I constantly ran into trouble when editing something in some other C file which was not the main project file or something like that.
So now if I wanted to change even to another C compiler, the code would need some kind of rewrite.
I really should try modern Free Pascal compiler to cross compile non-386 DOS executables in Linux.Oh, and as I did not have anything planned and was just writing code with the flow, there's also no documentation 🙁
I can post here what I have if you want, but it is not much.
I haven't actually tried the versions from the Borland Museum, but I downloaded a copy of Borland C++3.1 back in the early 2000's to do some work on the Wolf3D codebase. Its IDE allows you to manage project files that contain a list of the source files and also has "build" and "build all" options for compiling. Inline assembly is also supported. I've seen many download links for that compiler in the Wolf3D community, but I'm not sure if they're legal.
I don't actually use the BC IDE to write or edit code, though. I use Visual Studio to edit the C files and then fire up BC to compile the code.
If you're looking for a free alternative with the ability to cross-compile DOS executables from Windows or Linux, give Open Watcom a try. The guy who created Retro City Rampage used Open Watcom to create the DOS port of the game.
wrote:I haven't actually tried the versions from the Borland Museum, but I downloaded a copy of Borland C++3.1 back in the early 2000's to do some work on the Wolf3D codebase. Its IDE allows you to manage project files that contain a list of the source files and also has "build" and "build all" options for compiling. Inline assembly is also supported. I've seen many download links for that compiler in the Wolf3D community, but I'm not sure if they're legal.
I don't actually use the BC IDE to write or edit code, though. I use Visual Studio to edit the C files and then fire up BC to compile the code.
Yes, you can even compile a project from the commandline, so no need to actually go into the IDE, load the project, and select the build option from a menu.
wrote:If you're looking for a free alternative with the ability to cross-compile DOS executables from Windows or Linux, give Open Watcom a try. The guy who created Retro City Rampage used Open Watcom to create the DOS port of the game.
Yes, I've been using OpenWatcom 1.9 for a while now. It's good for regular integer stuff. Generates considerably faster and more compact code than Turbo C++. It's also a more modern dialect of C/C++, so you actually get stuff like the stdint.h headers.
Downside is that it's a bit buggy, especially with floating point code. One issue I've found (and fixed) is that executables that use floating point will just lock up on an 8088 system without an FPU, because there's a bug in the FPU detection routine that deadlocks your system.
Another issue I've run into, but haven't quite worked out yet, is that some of my float code gave wrong results in OpenWatcom, while the same code was stable in both Turbo C++ 3.1 and Visual Studio 2010. So I think in some cases it just generates wrong float code for some reason.
