4 ms·
I used a few apps with the captive Windows runtime back in the day. It was highly frustrating because the app it was bundled with worked great, but if you want
by rogerbinns 8y ago
I used a few apps with the captive Windows runtime back in the day. It was highly frustrating because the app it was bundled with worked great, but if you wanted to do anything else (eg view other files) then Windows wouldn't let you because it wasn't the full product.
As a user the bundled Windows wasn't perceived as a benefit, since it consumed so much more hard disk space and had higher memory requirements etc. The driver situation was often dire too since established apps had established drivers, while early Windows had whatever few Microsoft had written. Microsoft was also obviously pushing the Windows agenda, after many delays and much competition as outlined in earlier articles in the series.
In case anyone wants to fix it, I also have a bug report from the one time I used Windows 1 as a kid. I used the paint program and went to save. A standard file dialog didn't exist as part of Windows until 3.1 (1992), so before then each app was on its own. Paint gave a single line edit control where you typed in the whole pathname (no browsing or similar). Back then DOS had a 64 byte pathname limit but the dialog let you keep entering characters, so I did. When I hit save, nothing happened except brief blips of the hard drive light. I had to reset the machine and found that this buffer overflow had resulted in most of the entries in the root directory being deleted! A quick disk edit tool and they were fixed (a flag is set on directory entries to say deleted so you just had to undo the flag providing you didn't create new files to overwrite these entries).
An intriguing product from the era was Desqview/X. You got a full blown X server and so could direct Unix programs to display on DOS. It could also export DOS programs to other X servers. If it had succeeded, then in this alternate reality apps would run on unix and PCs would be good for games and accessing those "real" apps. https://en.wikipedia.org/wiki/DESQview#DESQview/X https://en.wikipedia.org/wiki/DESQview#DESQview/X
- iforgotpassword 8y ago> I used a few apps with the captive Windows runtime back in the day. It was highly frustrating because the app it was bundled with worked great, but if you wanted to do anything else (eg view other files) then Windows wouldn't let you because it wasn't the full product. In other words, working as intended. I mean, that's basically what you got with old DOS apps. You could spawn a new command.com from within the app if you were lucky, but that's not nearly the same as multitasking. You had a stack of programs running and had to completely exit the second one again to get back to the first. So windows didn't really take anything away but gave you a pretty good GUI.
- rogerbinns 8y agoI don't recall if this is accurate, but an example would be wanting to make a note in a text file. Under Excel and captive Windows you would have to save and quit, exit Windows, start your note app under DOS, take the note and then repeat the sequence in reverse order (perhaps minutes). Under a DOS app, you hit the hot key for your TSR[0], made the note and continued (a few seconds). As the series mentioned, being a power user under DOS was very productive. Lotus 1-2-3 especially had a notable menu/macro system, as did WordPerfect etc. GUI environments are not very useful for one program. They have far higher system requirements, and perform slower than native text environments. And they especially do not play nice with others. This is why there was so much scepticism at the time amongst those paying money for hardware and software. Of course new customers and more of them were just on the horizon as the series will soon reach. [0] https://en.wikipedia.org/wiki/Terminate_and_stay_resident_program https://en.wikipedia.org/wiki/Terminate_and_stay_resident_pr...
- dragonwriter 8y ago> GUI environments are not very useful for one program. Yes they are, which is why lots of DOS apps used one-off GUI environments at the same time that Windows captive and runtime apps became an additional way to acheive the same thing without building your own GUI from scratch. > And they especially do not play nice with others. That's not a GUI issue, that may be a “captive version of a desktop environment” issue that affected the captive Windows environment; there's nothing inherent about one-app GUI environment that makes it not support any of the (hacky and unreliable, mostly, because DOS wasn't built as a multitasking environment) multitasking options that DOS apps worked with as well as non-GUI apps.