Hi there. ^^ I'm afraid VB 1 applications need Protected-Mode (80286+).
Maybe an old version of CA-Realizer will do, however, not sure.

On the bright side, though, Turbo Pascal for Windows (TPW) applications are Windows 3.o RM compatible (8086+).

The Windows compiler in Borland Pascal 7 (Turbo Pascal 7) is a descendant of TPW.
So maybe its utilities (form designer etc) can be used by TPW projects, too.

An early Beta of Windows 3.1 can run in Real Mode, still, too.
It's useful for its Super VGA drivers, maybe. They may work on an XT with V20 CPU or 80186..
Personally, I think that's the most advanced Windows that can run on XTs, still.

Problem is, Windows 3.1x took the lead by storm after its release.
Windows 3.0 compatibility in applications quickly declined.

Technically, Windows 3.0 MME was also capable, but had dropped Real Mode support.
It also lacked many new API functions that Windows 3.1 applications expected.

Same goes for Windows 3.1 Real Mode kernal (Beta), maybe. It doesn't feature all the advanced API calls.
Maybe just a few new ones over its Windows 3.0 counterpart.

Edit: ACTOR 3.0 and Gupta SQL Windows may also run on Windows 3.0, still..
CA dBFast for Windows, too. Maybe FoxPro 2.5 (Windows).

__
Another "problem", I think, was that in Windows 3.0 era both the 8086 and 80286 were considered less important.
The focus was primarily on 386+ systems and DOS extenders.

That's why early compilers/dev tools tried to "pimp" (edit: to enhance) Windows for 386 usage (Watcom with WIN386 comes to mind).
This was started by Windows /386, I think, which glorified the 80386 processor and its wondrous capabilities.

But by the time Windows 3.1 was released, the IT industry had apparently realized that 16-Bit code wasn't that bad, actually.
OS/2 2.x and 3.x still had 16-Bit legacy code in place, because it was okay.

Then new 386 memory managers like QEMM were Windows 3.1 compatible, too.
So Windows was neither needed for improvement memory management (Windows /386 was an EMS provider, as well), nor did it cause any trouble.

And a lot of dated 286 PCs still ran Windows 3.1 well enough, so they didn't have to be scrapped yet.
- Windows for Workgroups 3.10 even was able to run on 286 PCs still and use existing resources of other PCs.

By ~1992, Windows itself had gotten quite capable, too, with WinMem32 and Win32s being an future option for high-performance 386 programs.

So many compilers/applications in the day used plain 8086/80186 code and let Windows 3.1 handle things.

When Chicago/Windows 95 was in the horizon, separate Win32 development tools became available, anyway (Alpha, MIPS, i386 etc).

All in all, the performance improvements were rather being provided by Windows 3.1 itself (ASM routines vs C ones to speed up a few things), optimized Windows drivers, Fast Disk feature, Smart Drive etc.

The increase in available RAM memory and hard disk space had further eased the situation.

Jo22 wrote on 2023-09-10, 03:15:

Hi there. ^^ I'm afraid VB 1 applications need Protected-Mode (80286+).
Maybe an old version of CA-Realizer will do, however, not sure.

It's a pity.

Jo22 wrote on 2023-09-10, 03:15:

On the bright side, though, Turbo Pascal for Windows (TPW) applications are Windows 3.o RM compatible (8086+). […]
Show full quote

On the bright side, though, Turbo Pascal for Windows (TPW) applications are Windows 3.o RM compatible (8086+).

The Windows compiler in Borland Pascal 7 (Turbo Pascal 7) is a descendant of TPW.
So maybe its utilities (form designer etc) can be used by TPW projects, too.
...

Yes, I heard about Turbo Pascal for Windows and that's good news.

I was asking because Windows 3.0 is the latest available version of Windows that somehow works on HP 200LX. Don't know why I pay so much attention to this cute little nonsense ... Maybe because it is cute.

Then I guess it's worth to switch my attention to its "older brother", NEC Mobile Gear, which is a cute little nonsense too, but just a little bit bigger one and with 486 CPU on board, and to leave HP 200LX in a DOS world to which it really belongs.

ThinkpadIL wrote on 2023-09-10, 17:07:

I was asking because Windows 3.0 is the latest available version of Windows that somehow works on HP 200LX.
Don't know why I pay so much attention to this cute little nonsense ... Maybe because it is cute.

Ah, I see. Makes sense. Maybe CA Realizer does work here, it was a Visual Basic alternative. It mentions Windows 3.0 as requirement, nothing else.

Hm. In theory, a hacked/modified VB Runtime (vbrun100.dll etc) might make things work on Windows 3.0 RM.
The Visual Basic applications themselves use P-Code and are techically processor-independant.
It's the runtime who is providing a virtual machine, comparable to Java/Chip-8, maybe.

If only we knew if there was some beta version of Visual Basic or a demo version (working model, incl. DLLs)..
If there was, chances are there might have been still some compatibility with Windows /386 or Windows 2.x or something. And in turn, XT era hardware.
So we could borrow an earlier version of vbrun100.dll.

Jo22 wrote on 2023-09-10, 17:50:

Ah, I see. Makes sense. Maybe CA Realizer does work here, it was a Visual Basic alternative. It mentions Windows 3.0 as requirem […]
Show full quote

ThinkpadIL wrote on 2023-09-10, 17:07:

I was asking because Windows 3.0 is the latest available version of Windows that somehow works on HP 200LX.
Don't know why I pay so much attention to this cute little nonsense ... Maybe because it is cute.

Ah, I see. Makes sense. Maybe CA Realizer does work here, it was a Visual Basic alternative. It mentions Windows 3.0 as requirement, nothing else.

Hm. In theory, a hacked/modified VB Runtime (vbrun100.dll etc) might make things work on Windows 3.0 RM.
The Visual Basic applications themselves use P-Code and are techically processor-independant.
It's the runtime who is providing a virtual machine, comparable to Java/Chip-8, maybe.

If only we knew if there was some beta version of Visual Basic or a demo version (working model, incl. DLLs)..
If there was, chances are there might have been still some compatibility with Windows /386 or Windows 2.x or something. And in turn, XT era hardware.
So we could borrow an earlier version of vbrun100.dll.

Well, it seems that it really doesn't worth an effort and the only practical option is a Turbo Pascal for Windows.

ThinkpadIL wrote on 2023-09-10, 19:12:

Well, it seems that it really doesn't worth an effort and the only practical option is a Turbo Pascal for Windows.

Hm. Maybe I can find the old disk set of Realizer.. My dad has it stored somewhere, I vaguely remember.
If I've found it, I'll try if it works in Windows 3.0 Real Mode and write back. ^^

Another option is to try out a flavor of PC GEOS.
It has very good Real-Mode compatibility, there was even Basic development kit (New Basic?).
Unfortunately, I'm a layman here. User Caluser2000 used to have run GEOS on his XT PCs, I remember.

The problem with XTs is (was) that they were deemed to be very slow, I suppose.
That's why they weren't being a real consideration for anything complex (CAD/CAM, DTP, software development).

Not that they're weren't technically able to do things, but.. Let's imagine how workflow was being affected.

If every keypress took half a second to be registered, if a compilation took 5 minutes each.
Developers simply couldn't progress with their work at that rate.

Edit: Speaking of, Rise of the Dragon (EGA) can run on an PC/XT with CGA,
but the experience isn't exactly fun.
I ran it on both a real 4,77 MHz setup and an 16 MHz setup (PCem).
It crawled and looked totally ugly, even via composite. 😥

By contrast, any 80186 PC ran circles around an 8086/8088 PC (Tandy 2000, '83, 640x400 res, was used during MS Windows 1.x development).

According to my books, by 1988 the 286-based PCs were already the typical baseline configuration for graphical applications.
XT style PCs were being described as "little PCs" for lightweight work.

So it makes sense that higher end development tools dropped support for XT class systems.

As a host system, I mean. Targeting smaller systems for the applications is another thing.
That way, they could more efficiently allocate memory or handle big chunks of data.

Turbo Pascal for Windows did essentially go that route. It doesn't work in Real-Mode, but its compiled applications will.
These applications also don't use P-Code, so no complex virtual machine has to run during execution.

Edit: I'm sorry if that sounds too negative.
I totally understand your wish for running a Windows 3.0 development system on your HP.

Personally, I'm also tinkering with CGA and XTs (and Hercules).
There's my Siemens Nixdorf 8810 M35 which has on-board CGA..

I've installed a NEC V20 and an MGA card (Hercules compatible) for a secondary monitor (works for Windows).
An EMS card will follow soon, so larger programs can run.

It's meant as a future development PC for my other hobbies.
VB DOS is one of the IDEs I'm planning on running on that thing.
Anyway, that's a bit too off-topic now, maybe.
What I meant to say is that I can relate to to this.

If you like to tinker with things, that beta I talked earlier is certainly a new fun toy, as well.
It can run Minesweeper from final Windows 3.1x, something that Windows 3.0 can't.

Anyway, please don't despair. The XT PC community is as healthy as ever. 🥳
I'm sure there might be experienced people who can modify vbrun100.dll or find a solution.
Maybe those over there at vcfed.org forums have an idea? 😃

Jo22 wrote on 2023-09-10, 23:29:

Hm. Maybe I can find the old disk set of Realizer.. My dad has it stored somewhere, I vaguely remember.
If I've found it, I'll try if it works in Windows 3.0 Real Mode and write back. ^^

That would be very interesting to know.

Jo22 wrote on 2023-09-10, 23:29:

Another option is to try out a flavor of PC GEOS.
It has very good Real-Mode compatibility, there was even Basic development kit (New Basic?).
Unfortunately, I'm a layman here. User Caluser2000 used to have run GEOS on his XT PCs, I remember.

I guess it must be GeoWorks Ensemble 1.X, cause version 2.0 and above already demanded 286+ if I understood correctly.

ThinkpadIL wrote on 2023-09-11, 13:59:

Jo22 wrote on 2023-09-10, 23:29:

Hm. Maybe I can find the old disk set of Realizer.. My dad has it stored somewhere, I vaguely remember.
If I've found it, I'll try if it works in Windows 3.0 Real Mode and write back. ^^

That would be very interesting to know.

Good new, I've found it! ^^
Bad news, it's version 2, though. Not version 1. 🙁

It mentions Windows 3.0 as requirement, but.. here it only works with my Windows 3.0 installation in DOSBox.
In PCem, I can merely get it to run on Windows 3.0 if I borrow a few DLLs from Windows 3.1 Beta (commdlg.dll, shell.dll, olecli.dll etc).
Not sure why. In Windows 3.0/DOSBox, the files aren't located in 'system' folder. Hm. Strange.

Anyway, Realizer, as such does work. But if it runs in Real-Mode, not sure.
It doesn't fit into conventional memory (about 350KB left to applications).
Even with EMS available (as seen in "About" dialog in Program Manager), the out-of-memory issue persists.

So yeah, the development system probably can't run on an XT anymore. 🙁 🤷

Edit: Screenshots added.

ThinkpadIL wrote on 2023-09-11, 13:59:

Jo22 wrote on 2023-09-10, 23:29:

Another option is to try out a flavor of PC GEOS.
It has very good Real-Mode compatibility, there was even Basic development kit (New Basic?).
Unfortunately, I'm a layman here. User Caluser2000 used to have run GEOS on his XT PCs, I remember.

I guess it must be GeoWorks Ensemble 1.X, cause version 2.0 and above already demanded 286+ if I understood correctly.

Probably true, yes. Though it may still run with a NEC processor.
Ensemble stayed Real-Mode compatible throughout all of its life.
The main reason XT support was dropped was for performance reasons, I believe.
If Turbo XTs with 16-Bit slots, 16 MHz and SVGA graphics had been released, the developers surely hadn't "dropped" XT support.

Edit: In practice, all this was possible.
- SVGA cards can work in XTs, if they support 8-Bit operation
- The latest NEC V20/V30 reached 16 MHz, officially
- 16-Bit slots are possible with the 8086/NEC V30, merely the address range past 1MB isn't available.

The last point is interesting insofar, because some 8086 based systems (Olivetti M24 etc) had a PC bus with a separate 16-Bit extension.
In theory, it's possible to wire these extra lines to the 16-Bit part of the ISA bus.
So devices which merely had used 16-Bit i/o, but no AT-specific features (second DMA controller, higher IRQs) would work on such an "Super XT".
Unfortunately, it made little sense at the time not to just use an 80286 instead.

Still, some higher-end NEC chips (NEC V41/V51, Vadem VG230 etc) did go that route, essentially.
They had integrated all XT relevant components, not so much unlike the i80186.
By todays definitions, these chips were early SoCs (system on a chip).

Edit: The VG-330 even supports Geoworks, fascinating.

"Built-in x86 compatible 16-bit, 32MHz NEC V30MX processor offers a high performance single-chip solution.
Supports GUI solutions from Geoworks, PenRight! and other DOS based applications. [..]"
Source: http://www.amphus.com/chips/singlechip/330_01.asp

Jo22 wrote on 2023-09-15, 05:18:

Good new, I've found it! ^^ Bad news, it's version 2, though. Not version 1. :( […]
Show full quote

Good new, I've found it! ^^
Bad news, it's version 2, though. Not version 1. 🙁

It mentions Windows 3.0 as requirement, but.. here it only works with my Windows 3.0 installation in DOSBox.
In PCem, I can merely get it to run on Windows 3.0 if I borrow a few DLLs from Windows 3.1 Beta (commdlg.dll, shell.dll, olecli.dll etc).
Not sure why. In Windows 3.0/DOSBox, the files aren't located in 'system' folder. Hm. Strange.

Anyway, Realizer, as such does work. But if it runs in Real-Mode, not sure.
It doesn't fit into conventional memory (about 350KB left to applications).
Even with EMS available (as seen in "About" dialog in Program Manager), the out-of-memory issue persists.

So yeah, the development system probably can't run on an XT anymore. 🙁 🤷

It is quite obvious that XT machine is barely enough (and in most cased not enough) for development of a software intended to work with Windows 3.0.

More interesting question is if a software developed with Realizer will run on XT machine with Windows 3.0 working in Real-Mode?

Not sure if its a valid option for you, but there is VB 1.0 for DOS as well.

gaffa2002 wrote on 2023-09-15, 15:12:

Not sure if its a valid option for you, but there is VB 1.0 for DOS as well.

It is for development of DOS programs, not Windows, so I guess it's not.

ThinkpadIL wrote on 2023-09-16, 03:32:

gaffa2002 wrote on 2023-09-15, 15:12:

Not sure if its a valid option for you, but there is VB 1.0 for DOS as well.

It is for development of DOS programs, not Windows, so I guess it's not.

Got it, the suggestion is because Windows 3.x runs on top of DOS, and it was not uncommon for programmers at the time to write DOS programs intended to run from within/outside Windows, specially for systems without protected mode available.

Jo22 wrote on 2023-09-10, 03:15:

On the bright side, though, Turbo Pascal for Windows (TPW) applications are Windows 3.o RM compatible (8086+).

Is this true for both TPW 1.0 and 1.5? Edit 3: It is, although TPW 1.5 provides some Windows 3.1 features and other things which aren't compatible with real mode, so those mustn't be used to ensure real mode compatibility.

The Windows compiler in Borland Pascal 7 (Turbo Pascal 7) is a descendant of TPW.
So maybe its utilities (form designer etc) can be used by TPW projects, too.

Its form designer is just Resource Workshop. It's apparently a newer version, but it's 1.02 so I don't imagine it's much newer!

I suppose you could use any resource editor that can create resources for Windows 3.0, preferably one that can manage a Pascal constants/identifiers file for you although I don't think that's critical (you could do that part manually or maybe convert from a C one), but Resource Workshop is the nicest such tool I'm aware of anyway.

For what it's worth, Resource Workshop 4.5 from Borland C++ 4.5 still has an option for generating Windows 3.0 resources.

The Borland Pascal 7 documentation has a somewhat vague list of improvements because it's comparing against both Turbo Pascal 6 and Turbo Pascal for Windows. Here are the things that I think could be useful for Windows 3.0 development. Hopefully there's nothing here which was really in TPW anyway and they just weren't clear about that. To be clear what I'm suggesting is that one could build and test with BP7 and TPW in parallel, but try to do as much as possible in BP7.

New IDE features:
ObjectBrowsers - find and cross-reference symbols
Syntax highlighting ⭐
SpeedBar (toolbar) ⭐
Undo/redo (multi-level) ⭐
Tools menu for running arbitrary tools ⭐
Local menus (right-click context menus) ⭐
Saves symbol information to speed up and simplify some things?
(I put a ⭐ on things where I though that the fact that these are new features really dates the product 😁)

Edit: I just found a screen shot of Turbo Pascal for Windows 1.5 and it clearly has syntax highlighting and a toolbar. Maybe the differences above are from TPW 1.0.
Edit 2: The major changes in Turbo Pascal for Windows 1.5 vs. 1.0, according to InfoWorld 20 Apr 1992, are including Resource Workshop instead of Resource Toolkit (from Whitewater, I think), and Windows 3.1 support.

Language additions, RTL changes, new units: these are of no use, except perhaps if the new units have source provided and are implemented without using the language and RTL additions

New compiler directives: Some of these are specific to other new language features, but these could be useful - one could build and test using BP7 to get these extra checks:
Type-checked pointers
Overflow checking for integer arithmetic

ObjectWindows: They refactored the WObjects unit into four other units, so some conditional inclusion is required to build against both TPW and BP7, but that shouldn't be too hard.

New tools: I have no idea if these run in real mode, but maybe they'd be useful for testing/debugging before building with TPW. Possibly could just find Windows 3.0 real mode equivalents, although I wonder if WinSpector/Dr Watson are actually able to function in real mode.
WinSight (window spy)
WinSpector (like Dr Watson)

Updated tools::
Turbo Debugger
Turbo Profiler
Turbo Assembler: I guess if this has useful improvements, what it generates should still work with Windows 3.0 in real mode because all the memory management is up to the user anyway

Edit: ACTOR 3.0 and Gupta SQL Windows may also run on Windows 3.0, still..
CA dBFast for Windows, too. Maybe FoxPro 2.5 (Windows).

FoxPro made me think of Microsoft Word, which had WordBasic. I assume there was some version which would have run in real mode? I can't remember much about it; not sure how powerful it was.

ThinkpadIL wrote on 2023-09-15, 14:49:

It is quite obvious that XT machine is barely enough (and in most cased not enough) for development of a software intended to work with Windows 3.0.

I assume an XT might be sufficient to run Microsoft Programmer's Workbench and compile Windows applications using Microsoft C/C++ 6.0 or 7.0, which could all be done from DOS; I think you could run them in a DOS prompt in Windows, although maybe not on your machine. It seems like it would be pretty painful to have to keep starting and exiting Windows, but I imagine some people actually did this, so it would probably be an authentic, very retro experience! I'm not sure it's an experience I'd want for myself though, I don't even want to try writing a Windows GUI application in plain C 😁

gaffa2002 wrote on 2023-09-16, 19:18:

Got it, the suggestion is because Windows 3.x runs on top of DOS, and it was not uncommon for programmers at the time to write DOS programs intended to run from within/outside Windows, specially for systems without protected mode available.

I was going to mention that DOS applications can use the Windows clipboard so they can be integrated with Windows in a somewhat nice way, but then I remembered we're talking about real mode where - if I understand correctly - DOS applications must always be full-screen, and I doubt the clipboard integration works there either 🙁

^From what I remember, the Windows SDK for Windows 2/3 was very memory hungry, too.
In my DOS VMs, I had to use 386 Memory Managers like QEMM to free as much conventional memory as I could.
I also had to increase space for environment variables for command.com,
because MS C 6 and the SDK used so many "SET" statements in autoexec.bat.

Windowed DOS applications.. That's an interesting topic! 😃
Windows 2.x had the ability to do that, not only in the /386 editions.
Since the kernal itself was just another 16-Bit DOS program, it still had a Real-Mode 'grabber' for video
(though /386 edition had different/better/incompatible video driver format despite this).
In Windows 3.0, the ability was lost. The 386 Enhanced Mode kernal was needed all the time now.
On the other hand, commercial DOS applications were quite feature-rich and worked best in a window on a 386, anyway.

Edit: I remember were I read about it, it was in this forum topic.
Coincidentally, it's also about Windows 3.0 on XT/CGA, so it's not too off-topic. Phew. 🙂

Edit: @doshea Thank you very much for the tips! 😃
My father had started with TPW 1.0, which also was available on a cover disk of a magazine (functional demo).
So that's what we had experience with. We later got TPW 1.5, but didn't require the added functionality most of the time.

doshea wrote on 2023-09-17, 01:11:

I assume an XT might be sufficient to run Microsoft Programmer's Workbench and compile Windows applications using Microsoft C/C+ […]
Show full quote

ThinkpadIL wrote on 2023-09-15, 14:49:

It is quite obvious that XT machine is barely enough (and in most cased not enough) for development of a software intended to work with Windows 3.0.

I assume an XT might be sufficient to run Microsoft Programmer's Workbench and compile Windows applications using Microsoft C/C++ 6.0 or 7.0, which could all be done from DOS; I think you could run them in a DOS prompt in Windows, although maybe not on your machine. It seems like it would be pretty painful to have to keep starting and exiting Windows, but I imagine some people actually did this, so it would probably be an authentic, very retro experience! I'm not sure it's an experience I'd want for myself though, I don't even want to try writing a Windows GUI application in plain C 😁

gaffa2002 wrote on 2023-09-16, 19:18:

Got it, the suggestion is because Windows 3.x runs on top of DOS, and it was not uncommon for programmers at the time to write DOS programs intended to run from within/outside Windows, specially for systems without protected mode available.

I was going to mention that DOS applications can use the Windows clipboard so they can be integrated with Windows in a somewhat nice way, but then I remembered we're talking about real mode where - if I understand correctly - DOS applications must always be full-screen, and I doubt the clipboard integration works there either 🙁

My question was actually whether Windows programs written in Microsoft Visual Basic 1.0 will work in Real-Mode on Windows 3.0. They haven't to be written on XT machine though, cause XT machines are too slow even to run them comfortably.

I see no sense running DOS programs on Windows 3.0 on XT machines. You always can run them in pure DOS instead.

ThinkpadIL wrote on 2023-09-17, 06:30:

My question was actually whether Windows programs written in Microsoft Visual Basic 1.0 will work in Real-Mode on Windows 3.0. They haven't to be written on XT machine though, cause XT machines are too slow even to run them comfortably.

I'll try to check Realizer's compiled programs, too.
But so far, any emulation with Windows 3.0 just hangs when I tried (in Real-Mode).
But that's maybe just a bug, not sure.

I tried to make EMS available, which limits the choices of emulators here.
If only PCem had a reliable machine type with chipset EMS, that is Real-Mode friendly (it technically has one machine, at least, but it's rather 'beta').

So far, EMM386+MemMaker and QEMM made Windows 3.0 run unstable (unlike Windows 3.1, which supports VCPI, DPMI etc).

The most reliable solution would be to use a vintage PC with a LIM4/EEMS compatible EMS board.
That's what Windows 2.03 had shipped drivers for (Intel AboveBoard, AST RAMPage).

Sure, a chipset EMS would also have been a possibility here, but it's more limited often.
For example, page frame is 64KB instead of 256KB, which Windows 3.0 wants to see.

It's all a bit tricky. Also, Realizer 1.0 might have been more lightweight, perhaps.
I believe that Realizer 2.0 was an updated version with Windows 3.1 enhancements, not unlike TPW 1.5 was.

Edit: Screenshots attached.

ThinkpadIL wrote on 2023-09-17, 06:30:

I see no sense running DOS programs on Windows 3.0 on XT machines. You always can run them in pure DOS instead.

It has more to do with user experience… a lot or people didn’t know or care if the application was windows native or not, they just wanted to click an icon and see it working.
For an XT machine, windows 3.0 basically works as a glorified, very bloated frontend for running DOS programs IMHO.
Anyway, I’m not trying to convince you to make a DOS application because it’s clear already that this is not what your experiment is about.

ThinkpadIL wrote on 2023-09-17, 06:30:

I see no sense running DOS programs on Windows 3.0 on XT machines. You always can run them in pure DOS instead.

Hi, is this topic still "a thing" (so to say)?
Because I had thought about this problem in the past months.

If you don't need Windows as such, but just a graphical BASIC, you can have a look at Locomotive Basic v2.
It's part of the Amstrad/Schneider PC1512 and PC1640 disk set. Maybe even localized.

The GEM system supplied is version 2, I think. But you can run any higher version, if you like.
Even ViewMax 1.0 from DR DOS 5, I think. It has icons for networks, too.

If you like, GEM Desktop 1.2 can be used along with GEM 2 or 3.
It was the latest version of the old Desktop, before that l*wsuit change had to be made.

If you don't like GEM or GEOS and prefer Windows..
I think I know of a few other programs that can run on XTs.

There's one simple interpretive language that seems to be Basic-ish and runs on Windows 2.x. And some version of Pascal.

Last, but not least, there's also Turbo Pascal for Windows demo that can compile 8086 EXEs.
If C language is also okay, have a look at MS Quick C for Windows 1.0; it's 8086 friendly, too and runs on Windows 3 (not on DOS).

I know, all of it is sort of a stretch, I know..

Thing is, I'm afraid, an XT class system barely qualified as a developer's PC. Ever. 😢

Even back in the 1980s, real developers (real men) either used an x86 cross-assembler on a powerful workstation
or had an early 80386 PC (say, 12 to 16 MHz). Like, say, the famous Compaq Deskpro 386.

Even ATs were a big sluggish when it comes to software development.
While they can run most stuff, they were facing their limits early on.

Systems with NEAT-like motherboard chipsets or EMS memory boards were a must-have, I believe.

Otherwise, the compilers and development software didn't fit in memory.
As far as DOS is being concerned, I mean. OS/2 1.x and its software perhaps hadn't such tight memory issues.

Seriously, getting MS C Compiler 6.0 to run flawlessly on an 80s DOS system alone is tricky.

For example, the PATH variables for MS C and the rest of the Windows SDK takes up some memory, so that batch files must be used to set up variables on demand.
Having everything in autoexec.bat all time requires increasing variable memory for command.com, but even that's close.
So uploading DOS, drivers and stuff into UMBs and loading remaining parts of DOS itself into HMA is just a small part of the fun.

That's why MS Quick C for Windows was such a relief, no more DOS memory trouble during compilation! 🥲

gaffa2002 wrote on 2023-09-17, 15:46:

It has more to do with user experience… a lot or people didn’t know or care if the application was windows native or not, they j […]
Show full quote

ThinkpadIL wrote on 2023-09-17, 06:30:

I see no sense running DOS programs on Windows 3.0 on XT machines. You always can run them in pure DOS instead.

It has more to do with user experience… a lot or people didn’t know or care if the application was windows native or not, they just wanted to click an icon and see it working.
For an XT machine, windows 3.0 basically works as a glorified, very bloated frontend for running DOS programs IMHO.
Anyway, I’m not trying to convince you to make a DOS application because it’s clear already that this is not what your experiment is about.

To be fair, though, I like the idea of being able to play GnuChess on an XT w/ Windows 3.
I mean, I've started out with an AT, a 286 PC, and ran Windows 3.1 back in the day (90s) instead..

But *if* my story had been different and I had been given an used XT first, I would have been very grateful for a copy of Windows 3.
While it was still very basic and limited on an XT, it would have been good enough for some of the classics.
GnuChess, Aforce, Lander 3, Klotz, and a few more.

Looking back at the time, I think I would have invested in a cheap VGA card and a cheap mouse for my imaginary XT. Maybe some multi i/o card w/ RTC, too.
An EMS memory board was out of question, of course, because it was a rare collector's piece by 1990-1993 standards, already.

The best thing I could have gotten still was a plain RAM card, as being published w/ schematics by c't magazine.
Since it covered whole 1MB range, it could serve as an UMB card.

Here's a picture: Re: 80x86/Vxx PC emulators with x87, EMS, UMBs and no artificial 640KiB limit ?

That VGA-equipped XT would have made for a nice Windows 2.x PC, too, I assume.
Playing Klotz was certainly possible, after all.

Playing a chess game via modem or serial port against my dad, too, maybe.
Running a three-wire RS232 null-modem cable through the whole house was possible.
Up to 25m are possible, depending on the baud rate. Alternatively, other chess games could be played on DOS anytime.

Ok, technically, it was possible to use AppleTalk+PhoneNet PC Card with an XT and have some networking over a cheap two-wire connection, too..
Because, the software had claimed "Windows" support in addition to ordinary DOS support.

Or I've could have had run LittleBigLan instead, which was a very affordable little network softwaree at the time..

Edit: Sorry, I'm getting carried away a bit again.
Edit: Formatting fixed (on PC).

Edit: I've attached the Basic-ish interpreter, it seems to have been be Freeware.
There's nothing that says otherwise. The whole archive merely contains the executable and some samples.

Edit: TPW demo can be found here. It has compiler switches in a menu for 8087 and 80286 code generation.
By default, plain 8086 code is being generated (Win3 RM friendly).

Update. A few more programming applications, for Windows 3.
Profan still exists, also in English and more recent versions.