Solution for Remote Access to and from Win 3.x?

[Shintaro1969]

Hi,

I was wondering what solution(s) exist to remote access another Windows version from Win 3.x?

There is PcAnywhere, and I think VNC, but finding a 16-bit VNC seems to be a challenge.

Is there an RDP client? There is MSTSC on XP, anything like that for Win 3.x?

Cheers,
Craig

[vbdasc]

Offtopic: There is RDP client for Windows 95 from Microsoft, called RDP client version 5.2 . It's relatively easy to find. I've never seen one for 16-bit Windows, although I've seen mentions of it here and there.

P.S. http://toastytech.com/guis/remotets.html says that it exists, though still no link

P.P.S. There is something called "16-bit TS client" on the Windows NT 4.0 Terminal Server CD. It might be RDP client for Windows 3.1, or not.

[adun]

If I recall correctly there should be a folder on the Windows 2000 cd (or was in in the Resource Kit?) called "TSCLIENT" that contains RDP clients:
16 bit for windows 3.x
and
32 bit for Windows 9x and NT 3.5x / NT 4.0

[DOS]

For remote access *to* Windows 3.x, I think what you really need is software for remote access to DOS that supports graphics modes, although some of them might have special performance enhancements for Windows. I don't ever recall any remote access software that only worked in Windows 3.x, but then stopped when you exited to DOS, although that's not to say none existed.

Off the top of my head:
- pcAnywhere
- Commute from Central Point's PC-Tools
- https://josh.com/tiny/: I haven't tried this but have heard of it quite a bit. I'm not sure if it actually supports Windows 3.x but I suspect it might.

[Shintaro1969]

For remote access *to* Windows 3.x, I think what you really need is software for remote access to DOS that supports graphics modes, although some of them might have special performance enhancements for Windows. I don't ever recall any remote access software that only worked in Windows 3.x, but then stopped when you exited to DOS, although that's not to say none existed.

Off the top of my head:
- pcAnywhere
- Commute from Central Point's PC-Tools
- https://josh.com/tiny/: I haven't tried this but have heard of it quite a bit. I'm not sure if it actually supports Windows 3.x but I suspect it might.

Doh!
I downloaded PC-Tools about a year ago when I was looking for a replacement for XTree, but never looked any further because I thought Norton Commander was good.

If people are interested, here is a 10 minute guide to PC-Tools Ver.8:
https://archive.org/details/10minutegui ... 0kray_n1s7

Tiny looks good, I'll give it a go.

[DOS]

Oops, your mentioning version 8 of PC-Tools reminds me that I know Commute was in version 7, but I'm not sure if it was in 8 or 9 - I think it got removed.

[Shintaro1969]

Oops, your mentioning version 8 of PC-Tools reminds me that I know Commute was in version 7, but I'm not sure if it was in 8 or 9 - I think it got removed.

I am messing around with 8.0 now. Commute is in it.

[Fork]

I've been looking for something to do this as well, and whilst I can't offer a good solution I can certainly tell you to avoid pcAnywhere! I tried both version 2.0 and 8.0 on Windows 3.11 (running as the Host, so I could connect to it from my regular Windows 10 PC) and whilst it technically worked it would cause the CPU to ramp up to 100% almost immediately - I could hear the CPU fan going crazy after a minute or so. And this was without me even connecting from my Win10 PC - just sitting idle it would cause the CPU in my DOS/Win311 laptop to skyrocket!

[DOS]

I've been looking for something to do this as well, and whilst I can't offer a good solution I can certainly tell you to avoid pcAnywhere! I tried both version 2.0 and 8.0 on Windows 3.11 (running as the Host, so I could connect to it from my regular Windows 10 PC) and whilst it technically worked it would cause the CPU to ramp up to 100% almost immediately - I could hear the CPU fan going crazy after a minute or so. And this was without me even connecting from my Win10 PC - just sitting idle it would cause the CPU in my DOS/Win311 laptop to skyrocket!

Do you have a way to monitor CPU usage in Windows 3.x, or are you running it on bare metal so you know from the fan speed it went to 100% usage?

I think that in the days when Windows 3.1 was current, my CPU was always at 100%, I didn't know anyone who cared about CPU utilisation, and if I even had a CPU fan it ran at a constant speed and I couldn't hear it I realise that people lucky enough to have laptops might have cared about some of these things, but maybe pcAnywhere wasn't designed to run the host software on a laptop? I imagine that on the host end it might need to run at 100% due to polling the screen for updates.

[vbdasc]

I think that in the days when Windows 3.1 was current, my CPU was always at 100%, I didn't know anyone who cared about CPU utilisation, and if I even had a CPU fan it ran at a constant speed and I couldn't hear it I realise that people lucky enough to have laptops might have cared about some of these things

I believe that back then most laptops and even some desktops came with APM API, which was supported in Windows 3.1 and later (not sure about 3.0) and when APM support was enabled in Windows, then the busy loop in the kernel that made CPU utilization to be 100% was replaced by an APM "idle" call, which in turn called the HLT instruction, and possibly performed some other tricks to save power. Technically, while the CPU is executing the HLT instruction, awaiting interrupts, the CPU utilization is 0%. So, not everyone in the Windows 3.x world ran their CPUs at 100% Unfortunately, many APM implementations were buggy, and Windows 3.1 itself had a nasty bug in its APM handling, which meant that power management didn't really become an ubiquitous thing before Windows 95.

Unfortunately, it seems than many 16-bit Windows programs don't care about conserving power and use various anti-idle techniques like polling PeekMessage() loops, which can explain the behaviour that the poster above you describes.

[DOS]

I believe that back then most laptops and even some desktops came with APM API, which was supported in Windows 3.1 and later (not sure about 3.0) and when APM support was enabled in Windows

I'm not sure if my desktop at the time I was running Windows 3.1 had APM support, but since Windows Setup doesn't seem to use APM unless you explicitly request it in the "machine type" (or whatever it's called) selection, I never would have thought to try anyway, and I imagine it's the kind of thing that not many people with desktops would have been aware of.

Windows 3.1 itself had a nasty bug in its APM handling

What was that bug? I couldn't find anything about it on an old TechNet CD.

Unfortunately, it seems than many 16-bit Windows programs don't care about conserving power and use various anti-idle techniques like polling PeekMessage() loops, which can explain the behaviour that the poster above you describes.

I've certainly seen code like that, and just to avoid confusion, the intent in that code wasn't to prevent the machine from being idle (even if that is what it causes, and the SDK makes it clear that it's the wrong thing to do too), I think it was just easier to port code that originally had its own main loop which occasionally checked for keypresses to use PeekMessage() rather than to rewrite it to be truly event-driven.

[vbdasc]

What was that bug? I couldn't find anything about it on an old TechNet CD.

http://www.os2museum.com/wp/windows-3-1 ... -with-apm/

I've certainly seen code like that, and just to avoid confusion, the intent in that code wasn't to prevent the machine from being idle (even if that is what it causes, and the SDK makes it clear that it's the wrong thing to do too), I think it was just easier to port code that originally had its own main loop which occasionally checked for keypresses to use PeekMessage() rather than to rewrite it to be truly event-driven.

Yes, and the fact that despite Microsoft's warnings, using GetMessage() loops didn't have any discernible advantage on non-APM configurations (which were the majority), didn't help either. People knew to not believe everything that Microsoft said, even back then.

[DOS]

http://www.os2museum.com/wp/windows-3-1 ... -with-apm/

Thanks!

Yes, and the fact that despite Microsoft's warnings, using GetMessage() loops didn't have any discernible advantage on non-APM configurations (which were the majority), didn't help either. People knew to not believe everything that Microsoft said, even back then.

Haha, yes, for sure!