I can only speak for my experience as a kid. I am sure others will share a very different experience than mine that will probably help you more.

Today, I am a web developer. But to be honest, I HATE the back-end programming I have to do at work, I am now more focused on the front-end stuff instead of back-end stuff. I honestly hate things like React and Angular. So I am going to find some time to learn Swift UI and start doing some apps for iOS/macOS if possible thanks to Mac Catalyst.

But, back when I was a kid... my favorite programming stuff was QBasic. While I started doing things with QBasic, my dad was a ninja with Turbo Pascal and Turbo C. My very first QBasic programming was something that simulated a "cash machine" (or ATM is the right word here?) just for the fun of it. He eventually became a very successfull programmer and is now retired. Guess what? He taught me, now I am the one who is teaching him to do web design stuff. Funny how the world changed, no?

I can't speak for C++, Turbo Pascal or anything else like that, I can only speak for my experience with QBasic.

Actually, I wanted to have a dig back into QBasic - 30 years later, I forgot almost everything I had learned from it. So I set up both DOSBox and Apple IIe emulators to start it all over again... one day. I have two very, very basic PDFs for QBasic starters, it's a complete copy of the very same books I had when I was a kid (9 years old if I am not wrong) and was starting to learn programming. Neither me or my dad knows where we left the original books. If someone wants these PDF books, I can share them. They are from Usborne, I think...

Really interested in where this thread will go! 😀

I was trying to set up some "process" that would allow me to write Pascal code in Sublime Text (not fully fledged IDE, but syntax highlighting is good enough for me), then compile it and run it directly in Dosbox, all with one command / keyboard shortcut. Through combination of custom build system and few batch (.BAT) files it should be doable. I'm somewhat close but it all seems too "hackish" at the moment 😀

I have messed around with Open Watcom, and eventually settled upon using Sublime as the text editor and having OW cross-compile from my development OS (Linux) to DOS. This way you can do C or C++.

This will end up being a fairly subjective thread... All we can tell you is what tools we use honestly. I think a good starting point based on your requirements would be DJGPP and just write the code in whatever IDE/text editor floats your boat on your modern computer. If DJGPP sounds bad then maybe go with open watcom or a later visual c++ for win 9x, but I have limited experience compiling dos binaries there so can't say how user friendly it is regarding 16 bit dos code

Get a network card and set up ftp or an smb1 network. Write the code on your modern pc, compile natively right on the dos pc. Rinse and repeat.

I write plenty of code this way just using JOE editor.. or geany if I'm feeling fancy.. samba share enabled on linux, save, spin my chair.. compile

Learning how to use far pointers and seg:off and memory models is annoying but its really not that difficult to grasp now that you probably have a bit more knowledge than you may have had as a kid, but I agree flat memory models are the way to go! DJGPP should be easier to use, once you figure out the minor quirks such as where video memory is mapped.

sledge wrote:

Really interested in where this thread will go! 😀

I was trying to set up some "process" that would allow me to write Pascal code in Sublime Text (not fully fledged IDE, but syntax highlighting is good enough for me), then compile it and run it directly in Dosbox, all with one command / keyboard shortcut. Through combination of custom build system and few batch (.BAT) files it should be doable. I'm somewhat close but it all seems too "hackish" at the moment 😀

Using bat files to compile isn't hackish at all IMO. I do the same thing for my projects.. example; to compile but not link a C project with MS C/C++ why type cl -AM -Zi -c -Fc -Gs -G2 filename.c when I could just write a batch file and say comp filename.c... It's really just writing your own pseudo makefile without using make.

My only suggestion is to make it two commands if you intend to build a library. One for compiling, one for linking... save yourself some time on slow old machines 😜 .. Though I guess on DOSBox it won't matter so much

Thanks for responses few points to discussion so far:

1. Its still all about C/C++, i know, i know.. when i was kid, if you wanted to be real programmer you had to use C++ with ASM optimizations.. and its still mostly true today for games and its core engines stuff, but there is possibility to become gameplay coder.. and here you can use some skill demanding languages as Lua in CryEngine / C# (Unity3D).. i even in prehistory saw Java scripting lang for games (Vampire: Redemption) or Python (Vampire: Bloodlines).. there are now even some visual GUI programming tools (Unreal 4) for me personally make real gameplay stuff was much more interesting, but low level engine - graphics, physics etc.. Last time i tried to that low level stuff was actually in DOS, where fastest putpixel, own timers, mouse handlers, fonts and picture loaders and were the kings..
   But, but.. if you dont want to make games, linux kernel,drivers etc.. there should be know something better. Could someone with good dos C++ skill just try that Python for Dos package - http://www.caddit.net/pythond/ ? Its possible to create exe with it, there some python to exe tool, but i dunno if will works with Dos? Give us some quick info, if is any good? Are any other lazy programmers alternatives?
2. I though that Pascal would be way how to avoid pointers, but i had some disscusion with FalcoSoft and he pointed that Pascal also support them and there are probably essential for some deeper stuff.
   He also pointed out that Pascal is not good enough because of runtime speed is myth and same with 64k memory limit.. - At least i though these things are limits of Pascal, when i was learning it.
3. Is someone some good explanation how to understand / use that that mythic 64k memory with Pascal (im not sure it applies to TurboC or not) in DOS? Because i far i know here is place when DOS extenders (DOS/4G, DPMI server, cwsdpmi.exe) come to play and at least most of newer Dos games were using them.
   I was always to scared by this stuff to even study it, on other than user level.
4. I wrote about Dos virtual machine, emulators etc.. but as someone pointed above, maybe better enviroment for Dos program debugging would be Windows 9x/9x virtual machine.. if DOS programs are there working fine, networking is much easier to make here working, maybe you can run some debugger window beside of Window with running application etc.. I know that there are even some native executables Dos debuggers (as Insight, Microsoft CodeView), but its from my perspective one more level (I theory with them you can found old games are crashing on some machines and fix it on ASM level and there is few people to able to do it.. that is particularly great to make some old games running on faster machines).

I'm a C guy, I like open watcom to build in dosbox.

FreePascal has a 64k unit limit with the native targeted DOS compiler (presumably as a result of 64k segments inherited from the 8086). Individual modules have to be organized to fit under the 64k limit which places an upper limit on the size of arrays and other data structures you can use (minimum one per module). FPC targeted against the GO32 extender doesn't have this limitation.

If you want to try something a little different, I recommend you dig into Forth.

Personally, I liked the IDE of QuickBasic 3/4.x and Turbo Pascal 6 quite a lot.
Back in the days before XP I spent a lot of time in rebuilding simple circuits mentioned in electronic's books.
More than often, they had got sample programs written in both GW-Basic and Turbo Pascal.

Especially the STICK() and OUT statements of GW-Basic/QBasic/QuickBasic (and PDS 7/VB DOS/Turbo Basic/Power Basic) were handy,
making thinkering a lot of fun without worrying about the details of syntax, conditions etc of C languages.
Anyway, I also liked Mix Power C then. Using a BASIC to C transpiler, I was able to enjoy little C adventures without too much headaches. 😄

Edit: Not sure if this is OT or looks too narcissistic (not intended as such), but if you're curious, have a look at this thread:
Using the game port as a switching output ? It's a good sample of what I liked to thinker with (simple circuits).
Edit: The linked short clip also contains that somewhat odd BASIC-C transpiler, and many failed compiles due to memory shortage. 😊

Is someone some good explanation how to understand / use that that mythic 64k memory with Pascal (im not sure it applies to TurboC or not) in DOS? Because i far i know here is place when DOS extenders (DOS/4G, DPMI server, cwsdpmi.exe) come to play and at least most of newer Dos games were using them.

Various memory limits apply to every real mode (16-bit) DOS executable:
1. In real mode DOS the maximum addressable memory is 1MB (in practice usually maximum 640KB is available)
2. Depending on the used memory model various 64KB limits also apply because of 64K segments.
These limits are not inherently language dependent and can vary with different implementations. These limits affect both your mentioned Turbo C/C++ and Turbo Pascal environments and also more modern tools that target 16-bit real mode DOS like Free Pascal 8086 cross compiler or Digital Mars C++ compiler for 8086.
E.g under the Tiny memory model (that is used in case of COM files) all your data and code have to be less than 64KB overall. It does not matter if you use Pascal or C or anything else.
https://wiki.freepascal.org/DOS
https://digitalmars.com/ctg/ctgMemoryModel.html
To overcome these various memory limits your target platform has to be at least 16-bit protected mode introduced with the 80286 or rather 32-bit protected mode introduced with the 80386. Your mentioned DOS extenders all use 32-bit protected mode with flat memory model and in theory 4GB maximum available memory.
You can find Pascal (Borland Pascal 7 - only 16-bit protected mode, Free Pascal) and C/C++ (Open Watcom, DJGPP) and even Basic (FreeBASIC) compilers that support 32-bit protected mode under DOS (so neither various 64K limits nor 640KB overall limit) but these require at least a 80386 to work.

gdjacobs wrote:

FreePascal has a 64k unit limit with the native targeted DOS compiler (presumably as a result of 64k segments inherited from the 8086). Individual modules have to be organized to fit under the 64k limit which places an upper limit on the size of arrays and other data structures you can use (minimum one per module). FPC targeted against the GO32 extender doesn't have this limitation.

in case of FreePascal DOS 8086 cross compiler you can use the {$HUGECODE on} directive to somewhat overcome the single module 64K limit.

But this 64K 'module' (source file) restriction also applies to Turbo C and Turbo Pascal since code of a single module must fit inside of one code segment. This is true even if you're using large (Turbo Pascal's default) or huge memory model.
Similarly, even though the huge model in Turbo C permits static data to be more than 64KB total, in each module it still must be less than 64KB thus also limiting the size of individual data structures to 64KB.

Correct me if I'm wrong, but IIRC HUGECODE automatically splits modules according to the 64k limit prior to the compiler run. The 64k limit for arrays and other primitive data types remains, though. So, it allows the automatic application of the workaround, but the limit still remains.

If you need bigger data structures, using an extender is probably your best best, although it's presumably possible to alter the descriptor table and go unreal mode.

What about using Expanded Memory, does it also have got the same limits when used in older compilers ?
- Im asking, because I heard PDS Basic 7.x supports that (in contrast to QuickBasic).

gdjacobs wrote:

Correct me if I'm wrong, but IIRC HUGECODE automatically splits modules according to the 64k limit prior to the compiler run. The 64k limit for arrays and other primitive data types remains, though. So, it allows the automatic application of the workaround, but the limit still remains.

I have said:

in case of FreePascal DOS 8086 cross compiler you can use the {$HUGECODE on} directive to somewhat overcome the single module 64K limit.

{$HUGECODE on} directive has nothing to do with limits of arrays, structures or any other data segment related stuff. It can help to overcome code segment related limits so you can have bigger units/modules/source files with more code. That's all.

I have just mentioned this since you explicitly wrote about unit size related problems in case of real mode Free Pascal compiler:

gdjacobs wrote:

FreePascal has a 64k unit limit with the native targeted DOS compiler (presumably as a result of 64k segments inherited from the 8086)

This is the exact problem that can be solved with the help of {$HUGECODE on} directive.

Jo22 wrote:

What about using Expanded Memory, does it also have got the same limits when used in older compilers ?
- Im asking, because I heard PDS Basic 7.x supports that (in contrast to QuickBasic).

Both EMS (Expanded) and XMS (Extended) memory can be used with old compilers (they work with Turbo Pascal/C, unfortunately I do not know PDS Basic) to overcome 640KB total usable memory limits but none of them can help to overcome the 64K limits for arrays and other primitive data types and code segment related unit/module size problems in case of old compilers targeting 16-bit real mode DOS.

Falcosoft wrote:

{$HUGECODE on} directive has nothing to do with limits of arrays, structures or any other data segment related stuff. It can help to overcome code segment related limits so you can have bigger units/modules/source files with more code. That's all.

I was going by this information from the literature.

Units and programs exceeding 64KB of code […]
Show full quote

Units and programs exceeding 64KB of code

Although the medium, large and huge memory models support up to 1MB of code for the whole program+units, there's still a limit of 64kb code per pascal module (i.e. unit or program). If this limit is exceeded, you can overcome this by splitting the unit or program that exceeded 64KB into smaller units, so that each of them stays within the 64KB limit. But there's also an easier solution. You can put the following directive in the module that exceeds 64KB:

{$HUGECODE on}

This forces each procedure and function to be in a separate segment. Note that since the code of the unit is no longer in a single segment, this also disallows mixing near and far procedures in the same unit, so in this mode, 'near' and {$F-} are ignored.

Using {$HUGECODE on} does not count as using a different memory model, because you can freely mix units with {$HUGECODE on} and {$HUGECODE off} in the same program.

My take on this was that any static data or pointer offsets would have to be within the segment of the parent procedure, but I guess there's some juju involved that you're more familiar with.

gdjacobs wrote:

My take on this was that any static data or pointer offsets would have to be within the segment of the parent procedure, but I guess there's some juju involved that you're more familiar with.

Hi,
I suspect there's a misunderstanding that can be noticed even in your first post:

FreePascal has a 64k unit limit with the native targeted DOS compiler (presumably as a result of 64k segments inherited from the 8086). Individual modules have to be organized to fit under the 64k limit which places an upper limit on the size of arrays and other data structures you can use...

I think you mix up 2 different issues, 2 different 64K limits (code vs. data). The bold statement is only true(ish) in the Tiny memory model where CS (code segment) = DS (data segment). Otherwise in other memory models the 64K 'limit on size of arrays and other data structures' (DS related) is independent from the 64k unit limit of code(CS related) since CS != DS.
As your quote from the documentation says {$HUGECODE on} directive has only meaning in medium, large and huge memory models where code can be larger than 64K. This directive has nothing to do with data limits (it does not matter if the used memory model supports data larger than 64K or not) .
E.g. in medium or large memory model you can solve your code size problem with {$HUGECODE on} or splitting your code (since larger than 64K overall code is supported) but still you can have problems with more than 64KB overall static data/global variables even if you use {$HUGECODE on} or split your units into small pieces since data is restricted to a single 64KB segment regardless of how you reorganize your code/units. So this sentence of yours has no much sense in medium, large and huge memory models:

My take on this was that any static data or pointer offsets would have to be within the segment of the parent procedure

The segment of any procedure's code (CS) is never the same as the segment of static data/global variables (DS), and even never the same as the segment of a procedure's local variables (SS).
Also because of the above depending on the used memory models you can have 2 types of default pointers: Data pointers and Code pointers. And depending on the used memory model they can be either near or far by default independently from each other.

Falcosoft wrote:

The segment of any procedure's code (CS) is never the same as the segment of static data/global variables (DS), and even never the same as the segment of a procedure's local variables (SS).
Also because of the above depending on the used memory models you can have 2 types of default pointers: Data pointers and Code pointers. And depending on the used memory model they can be either near or far by default independently from each other.

Aha, I didn't realize code and data don't coexist within a segment. Presumably this is by convention. From a program control standpoint, I'm guessing it's safest to update the program counter and code segment register simultaneously by a JMP or CALL which, of course, maps to calling a subroutine.

It's becoming a bit more understandable, then, although I'm still not clear how the compiler would translate an array location (base pointer + index) to a different data segment efficiently.

In the past, I actually did some development work directly in DOSBox (using Turbo Pascal's IDE), but I won't ever do that again. For now (using DJGPP/C++/Allegro), I've settled on using Notepad++ on my Windows 10 PC, saving the source files into a directory inside my DOSBox virtual hard drive, and running a make command from inside DOSBox. It works, but it's still not optimal. In general, I have yet to find something that pleases me 100%. Some of the things I've considered:

• DOSBox, even at max speed, builds very slowly compared to even a standard virtual machine. I actually use a very old DJGPP toolchain (g++ 2.9.4, Allegro 4.2) so it could be worse, but compiling even a single source file takes a few seconds. There are also ALT-tab issues I run into with both vanilla DOSBox and a couple of the unofficial forks - weird things happen like being unable to gain focus without ALT-tabbing, being unable to leave focus, or other strangeness. There's no scrolling buffer so I have to log messages to a text file if I want to read things, and it's very easy to hang or crash DOSBox if you do something even a little stupid writing code targeting protected mode.
• PCEm/86Box would be great (and would provide a pile of test configurations to run on, to boot!) but the only way to get files in or out of either of those is to use some kind of disk image. I suppose I could rig something to assemble and mount a floppy disk image whenever I make a change to a file, but it's more effort than I want to put into it. Folder as drive support in either of these is my most wanted feature by a mile.
• Running Windows 98 in a VMWare VM would also work pretty well, since I would then still have access to my Windows 10 environment and the VM could access my network mounts (which I could host my repos on), but it has a major issue in that changing to DOS mode doesn't work right - the keyboard and mouse stop working. Most things can be done without having to exit into DOS mode, but if I get far enough along that doing so may be required, then I'd have to abandon that plan and think of something else.

For now, I've just accepted that if I want to write software for DOS, then I'm going to have to live with the least bad of a number of pretty bad options.

C is a good place to start for any platform and DOS is no exception. There are tons of editors or IDEs out there for C, it's a matter of taste: some people are masochists and stick to emacs or vim but I tend to do the code on a moder PC using zerobrane for lua and visual studio code for everything else.

root42 has a great video tutorial series on coding C for DOS by the way: https://www.youtube.com/watch?v=DestaWfHDIk&l … ThlL48G9y4rJx1X