Emulators writing replacement os, drivers, dlls, & translation wrappers is probably the most active dos/win16/win32 programming , and doing stuff like in emulation app to access emulator settings. I always thought a dos app for emulator configuration that communicated through port addresses would be cool, write it in DOS Turbo Pascal, always liked that IDE and quick compile. Replacing Windows 98 vxds for emulation would be cool too(virtual roland and yamaha synths only like 9x, and eax & a3d more at home in 9x too) though qemu has pretty much solved running 98 I think. Back porting support to 9x would also be something to do , but again, qemu.

yes

Win95-targeting Win32's easy to hang onto with mingw gcc 4.7.2

Plasma wrote on 2022-06-23, 04:36:

yes

Thank you, Forums are difficult to come across now.
There is the MASM32 forum. They have a 16 bit sub-forum. Very knowledgeable guys.

leileilol wrote on 2022-06-23, 05:04:

Win95-targeting Win32's easy to hang onto with mingw gcc 4.7.2

After a lot of searching and trying to find the solution that will fit with what I want to do, I chose Microsoft C/C++ 7.0. I want to use the tools from that era (1992'ish).
I did think about Borland, Symantec, Watcom, and Code Warrior.

Besides, I am not a very good coder, so I have some catch-up to do. A couple of subjects at University in the late 1990s does not equal the ability to code, by any stretch of the imagination.

On a side note, there are so many great books. I find Ray Duncan, Andrew Schulman and Matt Pietrek to be really great Authors.

Plasma wrote on 2022-06-23, 04:36:

yes

mind blown good link 😀

Sure. It's just fun to tinker with QB45/VB Classic and Delphi! 😃
There's a lot of existing sample code for tinkering with hardware. USB, Parallel, Serial, Gameport...

QB45/VDOS
https://www.youtube.com/watch?v=KE648YNe2Ag

VB6
https://www.youtube.com/channel/UCM_rzw6WcXib … rch?query=Crane
https://www.youtube.com/watch?v=gW6IuC8L6D0
https://www.youtube.com/watch?v=DXGWvsKmJ0k

Edit: ^These were merely my own little projects.
There's a lot of sample code on the net for QBasic/QB64, TurboBasic/PowerBasic, Turbo Pascal..
Maybe C languages like Turbo C, even, not sure.
A few years ago, I still had a collection of bookmarks about these.

I occasionally have a crack at it. Several months ago I was slowly working my way through the Programming Windows 3.1 book using Borland C++ 4.5 which as far as Windows 3.1 based IDEs go is pretty nice. I've got a copy of Borland Pascal 7 which I'd like to find an excuse to use for something too. Tried Visual Basic 3 a month back but I'd forgotten just how basic it is.

My challenge so far hasn't been tools or resources - even when I limit my self to legally acquired stuff (no "abandonware"). Its coming up with ideas for projects. Things to build that actually make sense on a vintage computer or would make my vintage computing easier. Its hard simply learning how to program for some platform without actually having some project in mind to apply that to.

So far all I've built is two very simple DOS utilities. One fetches my IP address from the Novell TCP/IP stack and outputs it to the console (because the DHCP results usually flash by too fast during startup), and other tries to figure out if New Zealand daylight savings is in effect so I can pass the right UTC offset to the NTP client on startup - once I've ironed out some bugs my DOS machines will handle daylight savings correctly. At least as long as I'm not using the computer at 2am on the days the clocks go forward/backward.

A while back I found in my archives a very rough early SDK for the 32bit DOS Netware client which might make building client-side NLMs (protected mode TSRs in extended memory managed by NIOS) possible. Might be fun to play with that but it doesn't include any documentation or other bits for the TCP/IP stack so that kind of rules out the most interesting projects I can think of. Might have been neat to build some sort of background file transfer server but if I'm limited to IPX that makes building a client for a modern operating system difficult.

davidrg wrote on 2022-06-23, 22:59:

My challenge so far hasn't been tools or resources - even when I limit my self to legally acquired stuff (no "abandonware"). Its coming up with ideas for projects. Things to build that actually make sense on a vintage computer or would make my vintage computing easier. Its hard simply learning how to program for some platform without actually having some project in mind to apply that to.

So far all I've built is two very simple DOS utilities. One fetches my IP address from the Novell TCP/IP stack and outputs it to the console (because the DHCP results usually flash by too fast during startup), and other tries to figure out if New Zealand daylight savings is in effect so I can pass the right UTC offset to the NTP client on startup - once I've ironed out some bugs my DOS machines will handle daylight savings correctly. At least as long as I'm not using the computer at 2am on the days the clocks go forward/backward.

yes indeed - it's thinking of a project that isn't just a test or a (bad) game! there are things like drivers and so on that would be useful but this can get complex quickly

also, other than more specialised systems type programming, most things have been done several times over

i remember creating a dos application to split files so they could be carried in various floppies - only to find that it had been done lots of times, and better too! 😀

I never tried to get into the win16/32 programming api beyond a few calls, instead relying on vb or delphi for the ui

UI programming has gone from platform specific text mode, platform specific graphical mode to a kind of internet/mobile generalised UI approach these days. layers upon layers

gerry wrote on 2022-06-28, 07:30:

i remember creating a dos application to split files so they could be carried in various floppies - only to find that it had been done lots of times, and better too! 😀

Ah, yes but I bet you learnt a lot along the way.

I have no asperations of creating some groundbreaking app, Just code and learn things that interest me. If I do create something, I'll post it. Maybe someone else will find it interesting.
For example, I am interested in how DOS/Win 3.x processes and memory work. There are so many companies that made commercial products, that it would be silly of me to think I can do better.

Or maybe, if there is existing source and people could improve it/port it to other versions of Windows?

CraigAB69 wrote on 2022-06-30, 22:58:

Ah, yes but I bet you learnt a lot along the way. […]
Show full quote

gerry wrote on 2022-06-28, 07:30:

i remember creating a dos application to split files so they could be carried in various floppies - only to find that it had been done lots of times, and better too! 😀

Ah, yes but I bet you learnt a lot along the way.

I have no asperations of creating some groundbreaking app, Just code and learn things that interest me. If I do create something, I'll post it. Maybe someone else will find it interesting.
For example, I am interested in how DOS/Win 3.x processes and memory work. There are so many companies that made commercial products, that it would be silly of me to think I can do better.

Or maybe, if there is existing source and people could improve it/port it to other versions of Windows?

I did learn some things about DOS memory doing that its true

about source - there's a lot out there for dos and win16 but comparatively little when compared to newer platforms and internet things, old commercial applications have probably long lost their sources too

i do like the occasional port of some old code to a new platform or the other way round. Often the actual original executable runs fine in dosbox or a vm anyway, but its a challenge to port it to windows, or .net or html5 + script even

CraigAB69 wrote on 2022-06-30, 22:58:

For example, I am interested in how DOS/Win 3.x processes and memory work. There are so many companies that made commercial products, that it would be silly of me to think I can do better.

Hi! It depends in parts on the kernal types.

Real and Standard-Mode kernal use 64KB chunks, because that was the segment size of the 8086.

80286 was more flexible, technically, but that feature wasn't used.

The 386 Enhanced-Mode kernal uses 4K chunks, but normal Win16 programs don't realize this. It happens transparently.

Then, each kernal has different sources for memory.

Real-Mode uses Conventional Memory and EMS (64KB and 256KB frame size), which Windows programs can fully use (unlike on Windows 2.0).

Standard-Mode uses XMS to access Extended Memory, but actual memory management is done by Windows itself. There's some VCPI 1.0 compatibility, too.

Technically, there are two Standard-Modes on Windows 3.1.
One is handled by DOSX and KRNL286, the other one is part of KRNL386.
The first one is executed on 286 PCs automatically, the second one on 386 and higher.
KRNL386 provides it by disabling VXD support and not using Virtual Memory.

386 Enhanced Mode uses XMS to access Extended Memory, but can also provide DPMI memory.

Now, on Windows 3.1 on OS/2 2.11 or Warp 3 (Win-OS/2),
Windows became a DPMI client.
Instead of using XMS, it was getting DPMI memory from OS/2.

Some documents about memory management I found can be found here:
Re: Viewing the Upper Memory area

And here's some description of Windows 2.x compatibility bits.
Re: Wine on newer windows OSes?

Of course, there's much much more.
The books of Charles Petzold and others may have more information.

Jo22 wrote on 2022-07-02, 00:34:

Some documents about memory management I found can be found here: Re: Viewing the Upper Memory area […]
Show full quote

Some documents about memory management I found can be found here:
Re: Viewing the Upper Memory area

And here's some description of Windows 2.x compatibility bits.
Re: Wine on newer windows OSes?

Of course, there's much much more.
The books of Charles Petzold and others may have more information.

Thanks for those links.

I am working through a couple of books at the moment:
https://archive.org/details/Advanced_MS-DOS_P … tion_Ray_Duncan
https://archive.org/details/microsoftcc7comp0000murr

I have Petzold's book on Win 3.1 programming.
But I personally think that Andrew Schulman, Ray Duncan and Matt Pietrek are better. I have a few of these guys' books now.
I use the Internet archive for searching through the book, but prefer to read the physical book.

I thought you all might enjoy this TSR.

I just got an XT board (PIM-TB10-Z), and don't have an XT keyboard and the converter hasn't arrived yet. Thankfully, this board boots anyway even after a keyboard error, so we can play with a boot floppy and serial ports.

Boot floppy with CTTY COM1 in autoexec.bat works (your serial cable must connect DSR to DTR for it to work), but anything nontrivial bypasses DOS TTY calls and will use the VGA screen and BIOS keyboard calls. So, I wrote a small kludge of a TSR that takes characters coming into COM2: at 2400 baud, and injects them into the keyboard buffer. This doesn't support function keys or arrow keys because it's so minimal, but it is enough to get into TOPBENCH's realtime benchmarking screen (launch topbench, type B, then type R). It's of course not full serial support; you still have to look up at the VGA output to see what you're doing. And it's as brief and small as possible, missing very important features like refusing to install a duplicate copy of itself if it is already resident.

1        ; nasm -fbin -o serial.com serial.asm
2        cpu     8086
3        bits    16
4        org     100h
5        ; initial execution from the command line starts here
6resident:
7saved_ax:
8        jmp short nonresident
9saved_dx:
10        nop
11        nop
12saved_ds:
13        nop
14        nop
15        ; handle IRQ 3 - com2 interrupt
16int0bh:
17        mov     [cs:saved_ax],ax        ; reclaim space by overwriting jmp
18        mov     [cs:saved_dx],dx
19        mov     [cs:saved_ds],ds
20        ; read the character from COM2:
21        mov     dx,2f8h
22        in      al,dx
23
24        ; load the ASCII code into the keyboard buffer
25        ; the entire keyboard buffer is thrown out and replaced with this
26        ; one character--so whatever is reading the keyboard buffer better
27        ; be fast. per The Peter Norton PC Programmer's Bible, it's ok
28        ; to use zero as scan code as that happens whenever the user types
29        ; an Alt+NumPad code. but it does mean arrow and function keys aren't
30        ; supported unfortunately. to support them would require more
31        ; sophisticated code to convert multi-byte escape sequences
32        mov     dx,40h          ; bios data segment
33        mov     ds,dx
34        xor     ah,ah        
35        mov     [1eh],ax        ; keyboard buffer
36        mov     word [1ah],1eh  ; buffer head position
37        mov     word [1ch],20h  ; buffer tail position
38        
39        ; send end of interrupt to the PIC
40        mov     al,20h
41        out     20h,al
42        mov     ds,[cs:saved_ds]
43        mov     dx,[cs:saved_dx]
44        mov     ax,[cs:saved_ax]
45        iret
46
47        ; everything below here gets thrown out and doesn't cost memory
48        ; once the initial command line execution finishes.
49nonresident:
50        ; free environment segment
51        mov     ah,49h
52        mov     es,[2ch]
53        int     21h
54
55        ; set baud rate to 2400
56        mov     dx,2fbh
57        mov     al,80h
58        out     dx,al
59        mov     dx,2f8h
60        mov     al,30h

61        out     dx,al
62        inc     dx
63        xor     al,al
64        out     dx,al
65
66        ; line control - 8-N-1
67        mov     dx,2fbh
68        mov     al,03h
69        out     dx,al
70
71        ; modem control - DTR, RTS, OUT2 all on
72        inc     dx
73        mov     al,0bh
74        out     dx,al
75
76        ; interrupt enable - only want IRQs for RX'ed characters
77        mov     dx,2f9h
78        mov     al,01h
79        out     dx,al
80
81        ; ask DOS to replace existing IRQ 3 handler with ours
82        mov     ax,250bh
83        mov     dx,int0bh
84        int     21h
85
86        ; tell the PIC to unmask IRQ 3
87        in      al,21h
88        and     al,~08h
89        out     21h,al
90
91        ; test by writing an 'A' to the other side
92        mov     dx,2f8h
93        mov     al,41h
94        out     dx,al
95
96        ; terminate and stay resident                                                  
97        mov     dx,nonresident
98        int     27h

CraigAB69 wrote on 2022-06-23, 04:18:

I was just wondering if anyone was still writing code (games/apps) for DOS/Win16/Win32 (DOS - Win 98)?

I sort of am. In the last few years I've:
- Started on a tool which shows block device information in DOS because I wanted to know what geometry was being presented for some devices; I think there are plenty of closed-source tools that could do this but I wanted to know which call was returning what information.
- Written a small tool to detect if running in DOSBox, and to kill it in a different way from a reboot so that an external wrapper script can decide whether to restart DOSBox (for reboot) or exit (for what is intended to be a shutdown). I'm sure lots of DOSBox forks support reboot and shutdown but I would prefer to stick with vanilla and this was a nice way to finally write my first pure assembler tool.
- Made major changes to an old open source Lisp interpreter so I can use it for doing GUI automation in Windows 3.1, NT 3.1+ and 9x/Me.
- Started on a Borland C++ 4.5 IDE plugin which embeds the same Lisp interpreter and made it customisable via Lisp like Emacs.

I never seem to finish anything though 😁 I was close to done with the DOSBox thing and thinking about releasing it, but then forgot about it because it was serving my needs sufficiently!

CraigAB69 wrote on 2022-06-30, 22:58:

I have no asperations of creating some groundbreaking app, Just code and learn things that interest me. If I do create something, I'll post it. Maybe someone else will find it interesting.
For example, I am interested in how DOS/Win 3.x processes and memory work. There are so many companies that made commercial products, that it would be silly of me to think I can do better.

The problem with just about any existing application for these old operating systems is they're almost always commercial or shareware. I'm not interested in spending money on some old software unless it's something I used back in the day and want to experience again, and would prefer to avoid "abandonware" or using some shareware which the author wanted people to register (although there's a chance they might be happy to give it away for free now if you can track them down). I realise some people don't really care about that stuff and that doesn't bother me, but it bothers the admins on this site, so making free or open source versions of old tools could still be useful for people who don't want to use "abandonware" and also people who don't know what they're looking for.

For example, there was your thread looking for something like Process Explorer for Windows 3.x - I've sometimes wanted the same thing too, it'd be nice if there was a good option that was free we could point people to! I'd use it myself because sometimes I'd like to see a list of tasks and their handles when debugging the work I did on that Lisp interpreter to support interacting with tasks/processes.

In a similar vein, in this thread something like Process Monitor but for Windows 9x would have been useful, but all I could find was a commercial application which might be available on an old warez CD.

I'd be happy to point anyone who was interested at relevant documentation if they wanted to work on those sort of tools, and also help with code issues. I've come across quite a few Microsoft Knowledge Base articles with information on how to do these things since I guess it was hard to figure out from their regular documentation, and they often included some code snippets.

CraigAB69 wrote on 2022-06-23, 05:54:

leileilol wrote on 2022-06-23, 05:04:

Win95-targeting Win32's easy to hang onto with mingw gcc 4.7.2

After a lot of searching and trying to find the solution that will fit with what I want to do, I chose Microsoft C/C++ 7.0. I want to use the tools from that era (1992'ish).

That's not the best choice if you ask me because of this:

CraigAB69 wrote on 2022-06-30, 22:58:

I have no asperations of creating some groundbreaking app, Just code and learn things that interest me. If I do create something, I'll post it. Maybe someone else will find it interesting.

If you want make your application open source or free software someday it's better to rely on tools that others can use too to compile your code.
The same applies to support libraries. Otherwise your code might have a vendor lock-in. You might put your code under a free license, but you can't do the same with the proprietary 3rd party libraries your using.
There have been many programs where the author was annoyed afterwards that he didn't use a freer version to develop them from the start.

That's why it is better to use free software and open source libraries for projects like this.
FreeDOS 1.3 ships with a version of DJ GCC version 4.7.1 (form 2012) and the WatcomC compiler 1.9 from 2002.

FED is a quite good text editor for programming in DOS and is shipped with FreeDOS too.

Another reason to use a more modern compiler is the programming language itself. For C, some older compilers will require K&R style. Modern compilers will teach you modern C.
In addition, if you no longer want to develop directly under DOS but rather a new OS, you can use new compilers as cross-compilers to create your DOS binaries.
Here too, it is an advantage if the libraries used are also available on the new OS thanks to open source and the use of modern C helps here too.

CraigAB69 wrote on 2022-06-23, 04:18:

Is there a forum for that kind of thing?

There is also the FreeDOS mailinglist.
There are still things in the FreeDOS project that could be implemented or extended in existing software of that project.

Very much so, when I have the time. Mostly interested in DOS/Win16/Win32.

Over the last xmas period I started writing a MOD player for DOS (targeting 286 and lower). It's working really well. It plays back almost all MODs with a pretty good degree of accuracy. Atm on my 286 it can do 22050Khz 8bit mono Sound Blaster. This version is mostly C with some assembler inner loop optimization. But I can optimise more by rewriting a large part in 100% assembler. Maybe xmas this year if I don't have other things on my mind.

Tools I use: Open Watcom 2 and JWasm [1], DOSBox and real hardware (various).

Vogons seems to be mostly hardware/software related. For programming questions I go to VCF forums: https://forum.vcfed.org/index.php?forums/vint … programming.30/

[1] https://www.japheth.de/JWasm.html

I'm not writing games or anything useful... I'm poking and prodding this thing until it does something worth documenting... so I can run back here with it and bragpost. Then sit back and wait for the 20 new YT videos of guys who suddenly and mysteriously discovered the same thing.

Gonna be waiting a long time, so far no success.

Exploit wrote on 2023-11-13, 08:51:

If you want make your application open source or free software someday it's better to rely on tools that others can use too to c […]
Show full quote

If you want make your application open source or free software someday it's better to rely on tools that others can use too to compile your code.
The same applies to support libraries. Otherwise your code might have a vendor lock-in. You might put your code under a free license, but you can't do the same with the proprietary 3rd party libraries your using.
There have been many programs where the author was annoyed afterwards that he didn't use a freer version to develop them from the start.

That's why it is better to use free software and open source libraries for projects like this.
FreeDOS 1.3 ships with a version of DJ GCC version 4.7.1 (form 2012) and the WatcomC compiler 1.9 from 2002.

FED is a quite good text editor for programming in DOS and is shipped with FreeDOS too.

Another reason to use a more modern compiler is the programming language itself. For C, some older compilers will require K&R style. Modern compilers will teach you modern C.
In addition, if you no longer want to develop directly under DOS but rather a new OS, you can use new compilers as cross-compilers to create your DOS binaries.
Here too, it is an advantage if the libraries used are also available on the new OS thanks to open source and the use of modern C helps here too.

good advice in general

there is something interesting about using an old dev tool, for instance some of the DOS 16 bit compilers from the 80's early 90's - but as a rule the same thing can be accomplished in a more updated set of tools that can also be run on a more modern setup and tested in dosbox etc, and then be shared more widely. this is especially true for projects that benefit from being open source - like drivers etc. for personal hobby projects i think its ok to use anything, just recognise the limitations

i've certainly been tripped up when migrating back and forth between old and new compilers on things like c89 v newer c standards, early c++ variations and even things like implementation limits on array size and specifics like that - although, as long as it isnt too difficult to solve, its kind of interesting to find differences too!