3 ms·

As a cs student, I must say that I'm very impressed. A dev kernel from the era where while(true); was absolutely forbidden cause of the lack of preemption in wi

by mackwic 13y ago

As a cs student, I must say that I'm very impressed. A dev kernel from the era where while(true); was absolutely forbidden cause of the lack of preemption in windows. Seems like a piece of History for me. Would you accept to tell us more about what your team did, what were the goals and concerns about your system ?

hga 13y ago
History best viewed as "thank goodness we crawled out of that mud" ... it was not good, not a fun way to program when you had to do any significant task but not freeze the rest of the system; or if you screwed up an accidently went into a hard loop.... In Windows 3.x modulo the DOS boxes allowed by 386s and beyond; they and the Win16 subsystem were preemptively scheduled, and a lot of good software targeting Windows deliberately used those boxes running ancient, decrepit DOS.
chiph 13y ago
I was a contractor, so I worked on several systems for various customers (banks, mostly). There were a few approaches - one was multi-threading, the other was to divide your task up into small enough pieces to not violate the 1/10th sec. rule, and the other was to install another product that gave you Message Queueing. When splitting up your unit of work, you would define your own custom events such that when the event loop came around to processing your events, the granularity was small enough to keep the system responsive. BTW, events were prioritized by the OS, so not all events were treated equally. Same with NT. So you'd think of your application as a state machine, with the transitions being driven by the OS events appearing. Message Queueing (the current darling of the scalability crowd) has been around a lot longer than people realize. :) Also understand that for line-of-business applications, once the screen was done painting and you were waiting for user action, the event loop went into "idle" state. So in most cases you only had to worry about timeouts when you were communicating with a server (database or mainframe).
chiph 13y ago
Also - a book that I haven't seen mentioned in this thread yet is: http://www.amazon.com/Showstopper-Breakneck-Windows-Generation-Microsoft/dp/0759285780/ http://www.amazon.com/Showstopper-Breakneck-Windows-Generati... I haven't seen this edition, but if the comments are correct, try and find an original from 1994 (has a shiny cover with big red letters) to avoid the printing errors. It's written for a general audience, but still has some technical details in it. It's more interesting from a business and personality standpoint - at that level of software development doing things like kicking holes in your office walls becomes a little more acceptable (that would have gotten me fired at any job I've held)
- mackwic 13y ago
  Thank's for the feedback and the book. I'll try to find an original one.

by mackwic 13y ago

hga 13y ago

History best viewed as "thank goodness we crawled out of that mud" ... it was not good, not a fun way to program when you had to do any significant task but not freeze the rest of the system; or if you screwed up an accidently went into a hard loop.... In Windows 3.x modulo the DOS boxes allowed by 386s and beyond; they and the Win16 subsystem were preemptively scheduled, and a lot of good software targeting Windows deliberately used those boxes running ancient, decrepit DOS.

chiph 13y ago

I was a contractor, so I worked on several systems for various customers (banks, mostly). There were a few approaches - one was multi-threading, the other was to divide your task up into small enough pieces to not violate the 1/10th sec. rule, and the other was to install another product that gave you Message Queueing. When splitting up your unit of work, you would define your own custom events such that when the event loop came around to processing your events, the granularity was small enough to keep the system responsive. BTW, events were prioritized by the OS, so not all events were treated equally. Same with NT. So you'd think of your application as a state machine, with the transitions being driven by the OS events appearing. Message Queueing (the current darling of the scalability crowd) has been around a lot longer than people realize. :) Also understand that for line-of-business applications, once the screen was done painting and you were waiting for user action, the event loop went into "idle" state. So in most cases you only had to worry about timeouts when you were communicating with a server (database or mainframe).

chiph 13y ago

Also - a book that I haven't seen mentioned in this thread yet is: http://www.amazon.com/Showstopper-Breakneck-Windows-Generation-Microsoft/dp/0759285780/ http://www.amazon.com/Showstopper-Breakneck-Windows-Generati... I haven't seen this edition, but if the comments are correct, try and find an original from 1994 (has a shiny cover with big red letters) to avoid the printing errors. It's written for a general audience, but still has some technical details in it. It's more interesting from a business and personality standpoint - at that level of software development doing things like kicking holes in your office walls becomes a little more acceptable (that would have gotten me fired at any job I've held)

mackwic 13y ago
Thank's for the feedback and the book. I'll try to find an original one.