Skip to main content
added more info in response to info given
Source Link
Thomas
  • 3.9k
  • 20
  • 26

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.

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.

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.

Source Link
Thomas
  • 3.9k
  • 20
  • 26

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.