Help needed with OS/2

[Ampera]

To me, this is the glory of building retro PCs. Not only is it a history lesson for me, as I am not old enough to have experienced any of these machines, it allows me to make machines that would have been incredibly, or at least decently high end for the time at a now cheap price.

[NivagSwerdna]

TBH I think you are both right it depended on the setting.  So for high-end (Architects and the like were adopting high end graphics very rapidly at the time) and more standard applications were at a lower resolution.  I remember developing an application for a room which contained just over 1000 PCs (!) in 1995... pretty sure they were VGA.

[tooki]

SVGA and XGA were available but relegated to expensive high end systems then (a video card and suitable monitor for those resolutions would have been expensive in 1994). You'd also need a PC with a PCI bus (which essentially meant you had a cutting edge Pentium) or VESA bus (which meant a high end 486) in order to support that video card. (Higher resolutions and color depth required more throughout than ISA could provide).

The claim about bus throughput was repeated here before... it's simply wrong. No PC refreshes its video output over the bus, they are not Apple ][s in disguise.
By 1992, video cards supporting 1024x768 at 256 colors were affordable. They could be purchased for less than $150 with 1MB of VRAM as a 16-bit ISA card. A 15" monitor capable of displaying that resolution cost $400-700 depending on brand. The PCI bus wouldn't be released for two more years.
Other components like CPU and RAM were the primary contributors to cost.

You've forgotten inflation. Those figures would be around double that in today's money. I'm glad you could afford it, but my family couldn't.

$1 in 1994 is $1.65 in today's dollars. So nothing to sneeze at, but certainly not double. But either way, whether a graphics card cost $150 or $250, it's still reasonably affordable, it's not like we are talking about it costing thousands.

[Ian.M]

Back in the first half of the 90's we were running Windows 3.1 on a 386DX/25 system with crappy standard VGA on the motherboard, with a IBM 8514/A compatible card in it to give us 1024x768x16 or 256 colours on a large hi-rez multisync monitor (which I remember had 5 BNC sockets for the colours and syncs) so we could access a technical document system on CD-R  (using a 2x speed SCSI caddy CDROM drive) and get enough resolution on-screen to be able to avoid having to go wild printing out diagrams or futz around too much with the magnifier function.  I *think* it used Acrobat Reader for document display, but it might have been something proprietary.   Due to the high resolution, it soon became the preferred machine for doing the accounts in Excel, and then we treated it to a FAX modem (and faxed the boss's signature to it) so we could do paperless quotes and ordering!

[Zero999]

SVGA and XGA were available but relegated to expensive high end systems then (a video card and suitable monitor for those resolutions would have been expensive in 1994). You'd also need a PC with a PCI bus (which essentially meant you had a cutting edge Pentium) or VESA bus (which meant a high end 486) in order to support that video card. (Higher resolutions and color depth required more throughout than ISA could provide).

The claim about bus throughput was repeated here before... it's simply wrong. No PC refreshes its video output over the bus, they are not Apple ][s in disguise.
By 1992, video cards supporting 1024x768 at 256 colors were affordable. They could be purchased for less than $150 with 1MB of VRAM as a 16-bit ISA card. A 15" monitor capable of displaying that resolution cost $400-700 depending on brand. The PCI bus wouldn't be released for two more years.
Other components like CPU and RAM were the primary contributors to cost.

You've forgotten inflation. Those figures would be around double that in today's money. I'm glad you could afford it, but my family couldn't.

$1 in 1994 is $1.65 in today's dollars. So nothing to sneeze at, but certainly not double. But either way, whether a graphics card cost $150 or $250, it's still reasonably affordable, it's not like we are talking about it costing thousands.

My first PC, monitor, keyboard, mouse etc. and all cost around £400, or £750 in today's money, according to the this calculator, so I wasn't that far off when I said double (whatever the inflation rate was for the dollar, is irrelevant to me as I'm in the UK). It was a 386SX 25MHz, 4MB RAM and had a VGA card. I suffered that for a couple of years, then we upgraded the video card to a Trident and RAM to 8MB, so I could run M$ Encarta 96, which needed 8-bit colour or greater to run. I wanted to get a better PC so I could run Doom but wasn't allowed. Perhaps we were just poor?

A year later, we had more money and got a P200 with 32MB of RAM and a 4MB graphics card, which could run Quake and I was very happy. 

It's my shortening of MS-DOS 7.1 by the China DOS Union.


Basically, it was made by the CDU as a hacked apart copy of the ACTUAL DOS 7.1, which is just the kernel? version of 95B/98SE (think the NT version number for modern Windows). It has full LFN and FAT32 support, but enabling either of those is notoriously buggy. It breaks tons of stuff,  and it's not exactly kosher nor legal (They even dare to put it under a GNU GPL licence, wonder how well that would stand up in any court anywhere)

I still maintain the statement, that for the average desktop user outside of some REALLY weird use case, FAT32 on DOS is never really a good idea. If your desktop PC has more space than DOS can handle, then it's time to switch over to something better.

FAT32 was necessary because DOS was still a large component of Windows 95 to ME and hard drives were growing beyond what FAT16 could handle. It enabled larger partition sizes, yet kept the all important DOS compatibility.

That Chinese DOS sounds like a PoS and shouldn't be used.

My personal issues with FreeDOS and CDU DOS is with compatibility with anything using a FAT32 partition. Especially programs like windows, and other things that need direct drive access, FAT32 breaks it.

If you're taking about Windows 3.x, then it's not surprising it doesn't support FAT32 because it wasn't invented until Windows 95. I suspect any problems you have will be down to 32-bit disk access being turned on, which accessed the disk directly, but I imagine it would cause problems for file systems not supported by Windows 3.1. Try running windows in standard, rather than 386 enhanced mode, by typing win /s at the command prompt. If the disk access is slow, then load smartdrv.exe before loading Windows.

[timb]

SVGA and XGA were available but relegated to expensive high end systems then (a video card and suitable monitor for those resolutions would have been expensive in 1994). You'd also need a PC with a PCI bus (which essentially meant you had a cutting edge Pentium) or VESA bus (which meant a high end 486) in order to support that video card. (Higher resolutions and color depth required more throughout than ISA could provide).

The claim about bus throughput was repeated here before... it's simply wrong. No PC refreshes its video output over the bus, they are not Apple ][s in disguise.
By 1992, video cards supporting 1024x768 at 256 colors were affordable. They could be purchased for less than $150 with 1MB of VRAM as a 16-bit ISA card. A 15" monitor capable of displaying that resolution cost $400-700 depending on brand. The PCI bus wouldn't be released for two more years.
Other components like CPU and RAM were the primary contributors to cost.

Yeah, I think it's *you* who's got their timeline significantly off now.

PCI was released in 1992, though it was primarily only available on boards with high end server chipsets. In the home/small business segment it was a lot slower to gain adoption. That started happening in mid-1994 with the release of new chipsets for Pentium based systems.

Also, I can't find any $150, 1MB VRAM video cards capable of that  resolution in 1992. Care to link me to a catalog or advertisement showing some?

Also,  monitors are a different story. Sure, your $400 monitor might be able to do 1024x768, but only at 50Hz. Great if you want a migraine, not so much for actually doing work.

Finally, yes, in graphics modes (non-text modes/outside of DOS) the PC *does* have to refresh the video data over the bus. How the hell else would it update the frame buffer to redraw the screen, magic?

From Wikipedia:
"In the early 1990s, the I/O bandwidth of the ISA bus was becoming a critical bottleneck to PC graphics performance. The need for faster graphics was being driven by increasing adoption of graphical user interfaces in PC operating systems."

If a 16-bit non-DMA ISA interface was good enough, the VESA Local Bus (VLB) would have never been developed. Keep in mind, this was a time *before* consumer 3D acceleration, so the need to tie the video card directly to the 486's memory/processor bus was purely for 2D acceleration (or software based 3D in games and CAD).

[helius]

Also, I can't find any $150, 1MB VRAM video cards capable of that  resolution in 1992. Care to link me to a catalog or advertisement showing some?

These questions can be very tedious. If you adopt a less confrontational tone, you're more likely to get the references you want.

Here is a card capable of 1024x768 at 256 colors, released in 1991, and sold for $145.23 in 1992: The ATI VGA Wonder XL 1MB. At the same time, you could also buy the Diamond SpeedStar 24 for $159, or an Orchid ProDesigner IIs for $149.

Also,  monitors are a different story. Sure, your $400 monitor might be able to do 1024x768, but only at 50Hz. Great if you want a migraine, not so much for actually doing work.

You could buy a Panasonic C1395 for $429 [from the same issue]. It has a refresh rate of 60Hz at 1024x768. On a 14" screen this is not an excessive flicker for most people. For a hundred dollars more, you could go for NEC or MAG which were better quality. Keep in mind that in the days before EDID, monitors had to support whatever refresh rate the video card output. 1024x768@60ni was a standard SVGA rate, 50Hz was not. There was a 43Hz interlaced mode (on the 8514/A), but it had become largely obsolete by the 1990s.

Finally, yes, in graphics modes (non-text modes/outside of DOS) the PC *does* have to refresh the video data over the bus. How the hell else would it update the frame buffer to redraw the screen, magic?

What I would call "magic" or perhaps "slight of hand" is the tactic that uses a technical term, like frame buffer, in direct opposition to its accepted meaning. The frame buffer is just what it says, a complete buffer of the entire display. Even when the CPU is halted and the bus is frozen, it continues to supply the display at the bandwidth required for video refresh. So, the CPU and the bus are not involved in the refresh process at all. Q.E.D.

Wikipedia can be very poorly written, witness this amazing paragraph:

"Video cards always have a certain amount of RAM. This RAM is where the bitmap of image data is "buffered" for display. The term frame buffer is thus often used interchangeably when referring to this RAM.

Video card RAM is necessary to keep the entire screen image in memory. The CPU sends its data to the video card. The video processor forms a picture of the screen image and stores it in the frame buffer. This picture is a large bitmap. It is used to continually update the screen image."

Large, deep visuals have been output for the better part of 30 years from machines with much slower busses than ISA, like Q-Bus and VME.

[Halcyon]

Come on guys, there is a lot of knowledge between each of you, let's just leave it at that. It need not be a pissing contest about who was "more correct".

[Ampera]

Come on guys, there is a lot of knowledge between each of you, let's just leave it at that. It need not be a pissing contest about who was "more correct".

I think I am the most correct.

OS/2 is rubbish.

[timb]

Also, I can't find any $150, 1MB VRAM video cards capable of that  resolution in 1992. Care to link me to a catalog or advertisement showing some?

These questions can be very tedious. If you adopt a less confrontational tone, you're more likely to get the references you want.

Here is a card capable of 1024x768 at 256 colors, released in 1991, and sold for $145.23 in 1992: The ATI VGA Wonder XL 1MB. At the same time, you could also buy the Diamond SpeedStar 24 for $159, or an Orchid ProDesigner IIs for $149.

I wasn't trying to be confrontational, I was genuinely curious which cards you were talking about. Thanks for gathering some links!

What I would call "magic" or perhaps "slight of hand" is the tactic that uses a technical term, like frame buffer, in direct opposition to its accepted meaning. The frame buffer is just what it says, a complete buffer of the entire display. Even when the CPU is halted and the bus is frozen, it continues to supply the display at the bandwidth required for video refresh. So, the CPU and the bus are not involved in the refresh process at all. Q.E.D.

Yes, when the screen is just sitting there, displaying a static image, sure, the CPU isn't involved. However, that's just one, very narrow use case. What about when you're dragging a window around the screen? Or playing a full color game at resolutions above 320x240? Once you get out of text mode and into GUIs, you get to a point where every pixel is redrawn 60+ times per second, at higher and higher resolutions and color depths.

Also, keep in mind too that sometimes GUI programs would actually use the frame buffer as their screen buffer, by reading back portions directly from video RAM (instead of keeping a full working copy in the system memory). This essentially doubles the bandwidth required. (Read, modify, write.)

Again, why would they design an extension to the EISA bus designed specifically for video cards (VLB), in a time before consumer 3D cards were available, if regular old ISA was good enough? Answer: They wouldn't. They needed a way to connect the 486 CPU and memory bus directly to the video card's frame buffer at higher speeds than regular ISA allowed, for maximum performance.

[Zero999]

Yes, when the screen is just sitting there, displaying a static image, sure, the CPU isn't involved. However, that's just one, very narrow use case. What about when you're dragging a window around the screen? Or playing a full color game at resolutions above 320x240? Once you get out of text mode and into GUIs, you get to a point where every pixel is redrawn 60+ times per second, at higher and higher resolutions and color depths.

That's true. Remember when moving a window around you just saw the outline of the frame moving and not the whole window? Modern OSes often revert to this mode when using a generic unaccelerated driver.

Also, keep in mind too that sometimes GUI programs would actually use the frame buffer as their screen buffer, by reading back portions directly from video RAM (instead of keeping a full working copy in the system memory). This essentially doubles the bandwidth required. (Read, modify, write.)

Nowadays it's different but back then it was common. Try doing a flood fill on an image larger than the window on Paint Brush in Windows 3.1. You'll notice that the flood fill operation won't worn on areas off screen. It's because it works on the area in the video buffer.

Again, why would they design an extension to the EISA bus designed specifically for video cards (VLB), in a time before consumer 3D cards were available, if regular old ISA was good enough? Answer: They wouldn't. They needed a way to connect the 486 CPU and memory bus directly to the video card's frame buffer at higher speeds than regular ISA allowed, for maximum performance.

Yes, shifting the data back and forth was time consuming. One of the advantages with VGA mode X is the video buffer could have more than one page: 3 at 320x240 and 2 at 320x400, which sped things up. It also enabled 4 pixels of the same colour to be written to the buffer by only writing 1 byte of memory.

[Howardlong]

That's true. Remember when moving a window around you just saw the outline of the frame moving and not the whole window? Modern OSes often revert to this mode when using a generic unaccelerated driver.

It still does when you RDP into a box. You can also switch it off as part of the Performance options in the system control panel applet Advanced tab. Most of the visual effects are frankly just developer chrome nonsense and add nothing to end user productivity.

[Zero999]

That's true. Remember when moving a window around you just saw the outline of the frame moving and not the whole window? Modern OSes often revert to this mode when using a generic unaccelerated driver.

It still does when you RDP into a box. You can also switch it off as part of the Performance options in the system control panel applet Advanced tab.

Sorry, I'm not familiar with those terms. Do they refer to Winblow$? If so, I don't know, since I only use that at work and don't do any configuration.

Most of the visual effects are frankly just developer chrome nonsense and add nothing to end user productivity.

I largely agree, though find it much easier to move windows around, if I can see the contents, especially at higher resolutions. I remember using Linux on a live CD which booted with a generic driver, in some odd resolution and found the window frame difficult to see when dragging it around.

[timb]

That's true. Remember when moving a window around you just saw the outline of the frame moving and not the whole window? Modern OSes often revert to this mode when using a generic unaccelerated driver.

It still does when you RDP into a box. You can also switch it off as part of the Performance options in the system control panel applet Advanced tab.

Sorry, I'm not familiar with those terms. Do they refer to Winblow$? If so, I don't know, since I only use that at work and don't do any configuration.

Most of the visual effects are frankly just developer chrome nonsense and add nothing to end user productivity.

I largely agree, though find it much easier to move windows around, if I can see the contents, especially at higher resolutions. I remember using Linux on a live CD which booted with a generic driver, in some odd resolution and found the window frame difficult to see when dragging it around.

RDP is Remote Desktop Proctologist; Microsoft's take on VNC.

Though I have to admit, RDP has always been pretty good. Where VNC is essentially just sending highly compressed screenshots to the client (plus a virtual mouse and keyboard device), RDP is highly integrated into the OS. It creates a "virtual video card" of sorts that transmits draw commands and/or H.264 video to the client. This has a side benefit of allowing multiple users to remote into a single machine and each log into their own, unique desktops (even while someone is physically logged onto the RDP host machine).

Technically you can do that too on Linux with a special version of VNC (it essentially replaces the X-Windows server with a VNC service). However, like most other implementations of VNC, it provides poor image quality and isn't nearly as responsive as RDP.

RDP also transmits sound (through a virtual audio device unique to each user logged in), syncs the clipboard between the client and server and is damn fast. Image quality and responsiveness are good enough that you can easily play games remotely without noticeable lag.

Remote Desktop has always been one of the things Microsoft did right, in my opinion. As always, the proprietary nature kept it from being widely used outside of Microsoft's sphere of influence. (Only in the last few years did they finally release a client for iOS and macOS; there are open source implementations, but they use the older versions of the protocol and are reverse engineered, so not 100% stable. AFAIK there's no open source server.)

Apple integrated an enhanced version of VNC into macOS that provides some of the benefits of RDP (clipboard syncing, a virtual screen to allow multiple users to log in, remote scripting support, etc.) through what they call Apple Remote Desktop, or ARD. The one nice thing about that is it's still fully backward compatible with the vanilla VNC protocol, so you can get remote access to your system from basically any platform of the last 20 years (including an original Palm Pilot, which is nice if you wake up and find yourself in 1999, I guess.)

Edit: Uh, that's Remote Desktop Protocol, not Proctologist; damn autocomplete! Though, that would make for an interesting robot. They do robotic surgery already, why not a remote colonoscopy!

# assman@analcheck:~ ssh rectumroboto@hospital.med

[Halcyon]

RDP is Remote Desktop Proctologist; Microsofts take on VNC.

 

[tooki]

RDP predates MPEG-4 by many, many years. And the whole point is that it doesn't stream the screen buffer at all: RDP streams screen drawing (GDI)* commands, which are then executed on the terminal. For most things, this is far more efficient and responsive. This is similar to X Windows on UNIX.



*Does anyone know whether RDP has been updated to do the same with modern WPF graphics?

[Ampera]

I love RDP, and I wish it was better available on other platforms. It easily beats out VNC in every respectable way, unless you for whatever reason need pixel perfect accuracy, and you have a network made of solid steel.

[alm]

I agree that remote X and RDP would be a better comparison (sending rendering primitives over, rather than images), although you would obviously need to tunnel X over something like SSH to get any security (which SSH conveniently supports out of the box). I believe VNC is more like pointing a webcam at your screen and streaming the video. Its advantage is that it requires little on the side of the client so it can run both client and server on pretty much anything, including a Java applet back when that was still a thing.

[timb]

RDP predates MPEG-4 by many, many years. And the whole point is that it doesn't stream the screen buffer at all: RDP streams screen drawing (GDI)* commands, which are then executed on the terminal. For most things, this is far more efficient and responsive. This is similar to X Windows on UNIX.



*Does anyone know whether RDP has been updated to do the same with modern WPF graphics?

Actually, current versions do stream the screen buffer using an H.264 transport in certain modes. (Anything that requires 3D acceleration, watching videos in WMP, etc.)

You're correct that originally it was essentially compressing and sending the GDI commands. That has changed over the years and been blended with other technologies.

[Rick Law]

I love RDP, and I wish it was better available on other platforms. It easily beats out VNC in every respectable way, unless you for whatever reason need pixel perfect accuracy, and you have a network made of solid steel.

RDP wasn't really a Microsoft creation.  Microsoft licensed the technology from Citrix and deployed a dumb down version of Citrix remote as Microsoft Terminal Server (I think it started with Server 2000 or Server 2003).

Had RDP stayed a Citrix product, Citrix might have expand into to other OS'es.  Citrix as remote access was slowly being killed by the less capable (but cheaper) Terminal Server.

[hendorog]

I agree that remote X and RDP would be a better comparison (sending rendering primitives over, rather than images), although you would obviously need to tunnel X over something like SSH to get any security (which SSH conveniently supports out of the box). I believe VNC is more like pointing a webcam at your screen and streaming the video. Its advantage is that it requires little on the side of the client so it can run both client and server on pretty much anything, including a Java applet back when that was still a thing.

From a performance perspective, RDP is much faster than X over a link with any latency - like a WAN.
Performance wise, FreeNX/NX Server is the most comparable to RDP for linux. It radically improves the performance of X over a WAN.

[Howardlong]

I love RDP, and I wish it was better available on other platforms. It easily beats out VNC in every respectable way, unless you for whatever reason need pixel perfect accuracy, and you have a network made of solid steel.

RDP wasn't really a Microsoft creation.  Microsoft licensed the technology from Citrix and deployed a dumb down version of Citrix remote as Microsoft Terminal Server (I think it started with Server 2000 or Server 2003).

Had RDP stayed a Citrix product, Citrix might have expand into to other OS'es.  Citrix as remote access was slowly being killed by the less capable (but cheaper) Terminal Server.

It's even further back than that, NT4 had a terminal services version. Citrix had some sort of agreement with Microsoft around the WinFrame technologies. Citrix used there own ICA protocol rather than RDP though. I believe Citrix was also available on NT3.51, but I didn't use it then. It was a hugely popular way of deploying fat clients and client/server applications over slow WAN links.

As a technology, unlike Terminal Services, Citrix WinFrame and subsequently MetaFrame also added a degree of sandboxing and remote application desktop integration supporting mutilple end users on a single server. It was kludgy, but it worked (most of the time). It was certainly a difficult task to troubleshoot on production systems, and on the 32 bit back ends of the time, even Intel/Microsoft add ons like PAE and AWE to get around the 4GB RAM limitations of 32 bit weren't enough.

As time went on, disk and particularly RAM became much cheaper, 64 bit was introduced, and virtualisation became much more popular including full remote desktop enabling hot desking and remote working.

Nowadays remote desktop for end users is considered old hat as it doesn't work offline for the fraction of end users who think the world will end if they can't write emails and create content 24/7. So the world is moving to cloud based solutions with local sync such as Office 365/Onedrive which, for anyone who's used it, will know has its own limitations, primarily to do with syncing, availability, and a testing/change control process that doesn't include the customer.