• Please review our updated Terms and Rules here

Early Windows Programming

There was a Program Manager for Windows 2 released through the Microsoft BBS. Got enough press for me to notice and download. It was a bit memory intensive so not a good choice for the 640K machines.
 
I'd love to hear some discussion on the memory manager and multi tasking mechanics of early Windows. I like hearing about how early OSes handled multi tasking in a pre-MMU environment.

I'm sure it's similar to how the Mac did it, with the event loops being the ad hoc task scheduler, but curious how the memory manager works as well. The Mac and Apple IIGS Memory managers and linkers are kind of interesting in that regard (with a lot of similarity to how it was done in UCSD Pascal).
 
"There was a Program Manager for Windows 2 released through the Microsoft BBS."

I'm just not clear about what a "program manager" actually does. What kinds of things do you do with it?
 
Program Manager is the desktop for windows 3.x (and I guess there was an add in for 2.x).

The older versions just had what looked like a file browser and you’d run your executable file.

With program manager you get icons that you can customize and move around and even have groups of programs, so all of your office stuff can be in one group, etc. It’s a much more modern or finished feeling.
 
"There was a Program Manager for Windows 2 released through the Microsoft BBS."

I'm just not clear about what a "program manager" actually does. What kinds of things do you do with it?

Program Manager is a program launcher where clicking an icon executes an application. It was part of the joint IBM/MS OS/2 PM and Windows 3 interface.
 
Ah, I think I'm following you now. That's not something that's ever been important to me. IMHO: There's very little functional difference between icons on a "desktop" and executables in a folder; The former feels like an unnecessary duplication of the latter's functionality and, in point of fact, it's usually implemented as a folder anyway.
 
But from a programming standpoint, a shortcut repository is easy to create. By the time one has read half the Petzold book, one would know how to create a dialog box and display an icon. The dialog box would allow for the entering of any command line information. Clicking the icon could offered as a trigger to WinExec. At which point, one has a very rudimentary tool.

The Program Manager as seen in Windows did have a number of bells and whistles like premade icons for DOS apps and DDE links so setup programs could add entries.
 
But from a programming standpoint, a shortcut repository is easy to create.
It can be as simple as a folder of .BAT files. You don't need to code anything at all to do that.
 
I'd love to hear some discussion on the memory manager and multi tasking mechanics of early Windows. I like hearing about how early OSes handled multi tasking in a pre-MMU environment.

I'm sure it's similar to how the Mac did it, with the event loops being the ad hoc task scheduler, but curious how the memory manager works as well. The Mac and Apple IIGS Memory managers and linkers are kind of interesting in that regard (with a lot of similarity to how it was done in UCSD Pascal).

Windows multi-tasking was the message passing loop with each application sequentially given a chance to process its message. That was modified by timers. Each timer would give the program an additional message processing chance at a set interval.

Memory management did the usual relocate and discard to free space to load new memory but there were restrictions. Dos applications or data structures that needed multiple consecutive segments could not be moved and greatly limited memory management. Code segments could be discarded and would be reloaded from the original application file on disk. Unless good care was taken in the structure of the code segments, it was challenging to get multiple programs running at once because the available pool of space is so small.
 
I'd love to hear some discussion on the memory manager and multi tasking mechanics of early Windows. I like hearing about how early OSes handled multi tasking in a pre-MMU environment.

I'm sure it's similar to how the Mac did it, with the event loops being the ad hoc task scheduler, but curious how the memory manager works as well. The Mac and Apple IIGS Memory managers and linkers are kind of interesting in that regard (with a lot of similarity to how it was done in UCSD Pascal).

Early Windows used cooperative multitasking meaning that programs yielded control to the operating system between handling events. During long periods of computation, programs may play nice by calling Yield once in awhile.

Real mode memory management is not unlike an implementation of segmented protected mode in software. Instead of actual addresses, Windows returned a handle to an allocated memory block. The program must "lock" the memory before it can be used. Locking served two purposes: it converted the handle to an address and it locked the memory in place so that it will not be moved. Programs should lock memory blocks as little as needed so that memory can be moved around as blocks are allocated and freed.

The program code is broken up into many small segments which are loaded into memory as needed and discarded when not. An elaborate set of "thunks" were implemented for handling the transfer of control from block to block when doing intersegment calls, jumps or returns.

Much of this was greatly simplified by hardware support when Windows moved to protected mode; it all went away with the 32-bit flat memory model.

There was a book which went into all of these gory details; I think it may have been the first edition of Programming Windows by Charles Petzold. Later editions dropped all of that coverage when it was obsoleted by protected mode.
 
Conversely, there was GlobalWire which was like GlobalLock but intended for long durations. GlobalWire moved the data structure to the lowest possible address keeping as far out of the way as possible.
 
There was a Program Manager for Windows 2 released through the Microsoft BBS. Got enough press for me to notice and download. It was a bit memory intensive so not a good choice for the 640K machines.

I looked into this. It may have only been a beta release. I believe it's also MIA, and there are people looking for it. Do you still have a copy?
 
os2museum the message system here is broken for new users (and some not-so-new users too). I see your message. It was originally blank. I can read it now, but it seems my messages to you are now blank. I’ll try to contact you outside of this site.
 
Is there some documentation (DDK) on how to write a graphics driver for Windows 1.x or 2.x?
 
Is there some documentation (DDK) on how to write a graphics driver for Windows 1.x or 2.x?

The OEM Binary Adapation Kit has what MS provided. The documentation is minimal. Tutorials non-existent. At least, a good selection of sample drivers were included.
 
I looked into this. It may have only been a beta release. I believe it's also MIA, and there are people looking for it. Do you still have a copy?

Didn't turn up in the previous processing of archive disks. Still have more to work on. If I find it, I will be providing it.
 
os2museum the message system here is broken for new users (and some not-so-new users too). I see your message. It was originally blank. I can read it now, but it seems my messages to you are now blank. I’ll try to contact you outside of this site.
Yes, I realized that's what was happening. Later I found that I could actually read your message in the notification e-mail the forum software sent, but in the forum messaging interface it's just blank. You could try leaving a comment on my site or e-mail to mnecasek at yahoo dot com. Thanks!
 
Well, to be honest....any "minimum requirements" coming from M$ are pretty much a joke.

I ran a PC/XT (640K Ram + 2MB LIM) with Win 3.0 and Geoworks 1.x/2.x blew the doors off it for speed and usability. Now that was a real GUI.
Indeed. DRDoS 6.0 and GeoWorks Ensemble Pro 1.2 was what I had on my new 286/16 clone system back in the early '90s. 2.x was a bit slower because they changed the code base, but still faster the MS Windows 3.x on the same system. I have GeoWorks Ensemble Pro 1.2 on my current Redstone XT Turbo /EGA box.
 
Last edited:
Back
Top