2

I wrote a batch file which sends some files over a serial port in Windows 3.1, using kermit.exe.

The problem is: when the user switches between apps, the kermit batch will freeze till the next time they switch back into it.

What can I do to have it running independently?

Improve this question
4
  • 3
    I'm not sure it's really possible to do serial communication reliably in the background in Win 3.1 but in the Control Panel under 386 Enhanced, there are settings for multi-tasking where you can specify that programs run in the background. Also, using hardware handshaking on the serial line may be more reliable than software handshaking since Win3.1 might miss a software handshake in the data stream.
    – Tim Locke
    Commented Feb 29, 2020 at 19:15
  • 3
    It may also be helpful, if you find that input characters are being dropped when doing serial transfers in the background, to make sure you're using a 16550 UART which has 16 bytes of internall buffering. Without one, or if you're losing characters anyway, your other option is to reduce the bit rate of the interface.
    – cjs
    Commented Mar 1, 2020 at 7:13
  • It might be worth mentioning what kind of hardware you're running Win3.1 on?
    – bjb
    Commented Mar 2, 2020 at 19:45
  • 1
    Unless especially made to, MS-DOS applications (which yours seams to be) do not receive any processing time when moved into background in Windows 3.x. You will need to use a Windows version of Kermit to work the way you want.
    – Raffzahn
    Commented Apr 5, 2020 at 12:10

1 Answer 1

Reset to default
3

Windows 3.1 uses what is called co-operative multitasking (vs. pre-emptive multitasking used today).

What this means that that each app is supposed to co-operate by using the CPU time it needs and then releasing the CPU for other apps.

Time slices revolve around the main message loop. A typical Win 3.1 program will have a loop that peeks for messages, and if it receives one, process it and then release the CPU for other apps to poll that message loop.

If your app is not part of this mechanism, or doesn't implement it properly, it will not execute when other apps are using the polling the loop. Alternatively, it is possible that the other apps you mention hog the cpu.

This is why in those days, a poorly written app would block the other apps.

Even timers were signalling through that message loop. There were a few processes inside the OS that were interrupt driven, but I don't recall the serial link being one of them.

As to why this happens with that specific app, we'd have to look at its processing loop. It was usually very primitive and even with the disassembly only you can quickly see how the logic was implemented.

Edit:

As the comment points out that the OP is using MS-DOS Kermit, under Window 3.1, here are more details:

As the MS-DOS programs were not using the Windows API, they were run pre-emptively in a separate context and were generally unaware they were run under windows. In that context interrupts are virtualized and queued, to be passed on when the MS-DOS program gets a time slice. That alone can be an issue with serial communication if buffers are not large enough. There were a few ways to force a program to release its time slice, etc but nothing helping the OP here. Also, time slices were a bit irregular and some OS calls were significantly delaying them.

The solution to this issue is through PIF files. They are documented here: https://www.smsoft.ru/en/pifdoc.htm

A MS-DOS application can be launched with matching PIF file. These files are used by Windows 3.1 to describe how the MS-DOS application is to be run in its virtualized context.

This discussion (http://ftp.math.utah.edu/pub/ibmpc/kermit/msvibm.pif) is about having a PIF file for Kermit; the second message in that thread seems to indicate a similar problem as the OPs with some troubleshooting steps.

Improve this answer
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .