Coming through a hazy three decade fog is the notion that you might want to stick WIN in front of it instead of START, but not super sure.

Yes, the following .BAT is likely to work:

THROTTLE to slow it down
WIN TEMIM.EXE to run Windows with the game
THROTTLE to speed it up after exiting Windows

I also vaguelly recall some utility to run Windows EXEs from the VDM in Windows 3.x, but can't tell what exactly it was...

Sadly, putting WIN in front of the program I want to run while Windows is already running means it complains that I'm already running Windows "You are already running Enhanced mode Windows".

Sleaka_J wrote on 2024-08-09, 09:10:

Sadly, putting WIN in front of the program I want to run while Windows is already running means it complains that I'm already running Windows "You are already running Enhanced mode Windows".

I think that suggestion was something intended for you to run from DOS, not within Windows. It would slow down the CPU, then start Windows, which would automatically run your game, and when you exit Windows (I'm not sure if it would exit when the game exits) it'll revert the slowdown. It might be a bit painful waiting for Windows to start up and shut down with the CPU slowed though!

Sleaka_J wrote on 2024-08-08, 12:23:

I know that Windows 9X solved this problem by adding the "START" command to run Windows programs from a DOS prompt. I don't think there's an equivalent in Win3.x

Grzyb wrote on 2024-08-08, 14:35:

I also vaguelly recall some utility to run Windows EXEs from the VDM in Windows 3.x, but can't tell what exactly it was...

There are two tools like that included with Microsoft and Borland's compiler products. Borland's is called WinRun and is included in for example Borland C++ 4.5, and Microsoft's is called WX (a better keyword to search for is "wxserver" though - that's part of the solution).

Another option would be a Windows-based scripting language like WinBatch (for example Google for "site:cd.textfiles.com winbatch" to find old shareware versions).

I'd use SetMul here because it's not a TSR. I'm not sure how loading a TSR in Win3.1 interacts with the rest of the system, particularly under 386-enh mode.
So make a batch file and do:
SETMUL L1D
TEMIM.EXE (make sure to use the proper path)
SETMUL L1E
and create a shortcut to it in Program Manager.

If that doesn't work, you can create a shortcut to just run SETMUL. Double-click it to slow things down, then run the game from its original shortcut. Then another shortcut to restore speed.

doshea wrote on 2024-08-14, 09:39:

Borland's is called WinRun and is included in for example Borland C++ 4.5

That must have been it!
I recall there was some Borland's stuff installed on that Windows 3.1 machine...

Note to self to try it again some time - it's more convenient to run programs from something like Norton Commander, than from File Manager.

wbahnassi wrote on 2024-08-14, 12:17:

I'd use SetMul here because it's not a TSR. I'm not sure how loading a TSR in Win3.1 interacts with the rest of the system, part […]
Show full quote

I'd use SetMul here because it's not a TSR. I'm not sure how loading a TSR in Win3.1 interacts with the rest of the system, particularly under 386-enh mode.
So make a batch file and do:
SETMUL L1D
TEMIM.EXE (make sure to use the proper path)
SETMUL L1E
and create a shortcut to it in Program Manager.

If that doesn't work, you can create a shortcut to just run SETMUL. Double-click it to slow things down, then run the game from its original shortcut. Then another shortcut to restore speed.

Throttle isn't a TSR either and I'm using it in tandem with SETMUL.

http://www.oldskool.org/pc/throttle/DOS

I came up with a different solution that isn't elegant, but acceptable. So, if I want to slow down the PC, I double clock on a PIF (so the DOS prompt runs in a window) that calls a BAT file and pauses after slowing the system down. That way I can minimise the window and the system remains slow for The Even More Incredible Machine. When I'm done, I restore the minimised window and press any key and it restores the speed of the PC. Behold...

@ECHO OFF
THROTTLE.EXE 7
SETMUL L2D
ECHO Minimise your DOS Window . . .
PAUSE
SETMUL L2E
THROTTLE.EXE 0

Like I said, it slows down Windows 3.1 enough for The Even More Incredible machine to run at "normal" speed.

doshea wrote on 2024-08-14, 09:39:

I think that suggestion was something intended for you to run from DOS, not within Windows. It would slow down the CPU, then start Windows, which would automatically run your game, and when you exit Windows (I'm not sure if it would exit when the game exits) it'll revert the slowdown. It might be a bit painful waiting for Windows to start up and shut down with the CPU slowed though!

I was trying to avoid that. I wanted to stay in Windows. In my post above, I came up with something that still runs in Windows 3.1. It "works", but I'd like find a one double click solution.

doshea wrote on 2024-08-14, 09:39:

There are two tools like that included with Microsoft and Borland's compiler products. Borland's is called WinRun and is included in for example Borland C++ 4.5, and Microsoft's is called WX (a better keyword to search for is "wxserver" though - that's part of the solution).

Another option would be a Windows-based scripting language like WinBatch (for example Google for "site:cd.textfiles.com winbatch" to find old shareware versions).

I will give that a go. Thanks for mentioning it!

wbahnassi wrote on 2024-08-14, 12:17:

I'm not sure how loading a TSR in Win3.1 interacts with the rest of the system, particularly under 386-enh mode.

Good point - lucky the solutions being used aren't TSR ones! If you load the type of TSR that displays a popup when you hit a key, that works within that DOS window just fine. However, I imagine that if you load a TSR that tries to hook the timer interrupt and then hogs the CPU a bit to try to slow the machine down, it might slow it down a bit, but not necessarily to the same extent it would under plain DOS, because Windows should only give that DOS window a slice of the available CPU time as set in the .PIF file. The combination of the timer interval and Windows' time slice might cause the slowdown to be jerky/bursty.

Another option would be a Windows program which hogs the CPU a bit. My not-yet-released fork of XLISP-PLUS that I use for automating Windows inadvertently does that when it's trying to sleep, because of the way it was originally implemented (if I recall correctly it uses PeekMessage() when a lisp function is running rather than a normal Windows event loop). How well that would work would depend on how the game is written - since Windows applications are cooperatively multitasked, if the game doesn't pass control back to Windows very often, then another program trying to hog the CPU might not get to do that very frequently, causing the game to be a bit jerky.

It's annoying what doesn't work in a Win3x DOS prompt on the one hand, and really surprising what DOES work on the other hand. I had a 386SL20 notebook in 1996, limited to 4MB physical RAM, and for giggles one day, I copied over DN3D demo and launched it under windows 3.1 .... annnnnnd evennnnntualllllly it raaaaaannnnnn, I mean it was running, super super slow, reducing the viewport to a postage stamp gave you the ability to "navigate" at about 5fps. HDD was thrashing like hell of course, because guess what, it was 3/4 running off virtual memory swapfile. Also involved was possibly the win3.x FPU emulator, which couldn't have been helping the speed any.