4 ms·

You overlooked the fact that programming model of windowed/GUI applications is quite complex and very sensitive to non-cooperative code - a thread that frequent

You overlooked the fact that programming model of windowed/GUI applications is quite complex and very sensitive to non-cooperative code - a thread that frequently blocks for 100 ms can cause very unpleasant hiccup. Introduction of OLE/COM interprocess communication mechanism made things worse as one unresponsive application could block other programs and halt their message loops. But it was quite efficient and you didn't have to spin up multiple threads to have multitasking in your application.

lisper 13y ago
> You overlooked the fact that programming model of windowed/GUI applications is quite complex and very sensitive to non-cooperative code - a thread that frequently blocks for 100 ms can cause very unpleasant hiccup. No, I didn't overlook this. But this is 2013. IMO, a multitasking architecture that is "sensitive to non-cooperative code" ought to be considered broken, and so if that's the cause of this problem, that still counts as Microsoft's fault in my book.
- nknighthb 13y ago
  It's now 2014, actually, and you're talking about a problem from 1997, in an OS where backwards compatibility has been an extremely high priority since the 1980s.
  - lisper 13y ago
    > It's now 2014, actually Is that really the kind of discussion you want this to be? > you're talking about a problem from 1997, The last revision of the article is 2002. But your point is well taken. I had assumed this was a current issue. (Maybe it is. I don't have time to dig into those details right now.) > in an OS where backwards compatibility has been an extremely high priority since the 1980s OS X was introduced in 2001, and it could run OS 9 applications, so these kinds of problems can be solved if a company decides it is worthwhile to solve them.
    - nknighthb 13y ago
      > Is that really the kind of discussion you want this to be? Yes. If you're going to chastise people based on what year it is, you damn well better be right about what year it is. > OS X was introduced in 2001, and it could run OS 9 applications OS X booted a modified copy of OS 9 to accomplish that. It didn't fix anything about OS 9. It also wasn't present on Intel Macs, nor on Leopard, the last PowerPC-compatible version of OS X. Nor was it fully compatible -- I always had trouble with it, and have kept older System 7 and OS 9 Macs around rather than put up with it.
- asveikau 13y ago
  In that case I look forward to the lisper UI toolkit, which stays responsive when application code stalls on a UI thread. I'll bet it goes well with the lisper dynamic linker, which I hear completely isolates me from bugs of code living in the same address space. Kidding aside, I can't help but think that you keep going back to that "clearly the mutex is broken" analogy I mentioned earlier. If I read you correctly, it doesn't matter if the Oracle code is breaking the rules set out by the MS documentation, Microsoft should account for all possible bugs past, present and future and prevent them. Seems like that's asking a lot. The other platforms I've worked with don't seem to satisfy this either. What bothers me more, though, is how preemptively dismissive you've been about Win32 while showing something of a lack of knowledge on how it works. I don't think Win32 is perfect. (Ask me about filesystem behaviors some time.) At the same time I have gotten to know it and can appreciate areas where it works well. I would also hope that before making the kinds of comments you are making about any platform, I'd get to know the framework a bit better first.
  - lisper 13y ago
    > I look forward to the lisper UI toolkit I might not be able to show you such a toolkit, but I can certainly show you an operating system that allows you to write a database driver whose behavior is not affected by the user moving the mouse. > it doesn't matter if the Oracle code is breaking the rules set out by the MS documentation Of course it matters. I just couldn't imagine what rule there could possibly be that is both 1) broken by a database driver and 2) reasonable, that could possibly result in said driver displaying the behavior in question. (I can imagine such a rule now because to3m pointed out a reasonable possibility in another branch of this thread.) > how preemptively dismissive you've been about Win32 while showing something of a lack of knowledge on how it works I freely confess to being (at least potentially) prejudiced against Microsoft's technology by my anger at the fact that they reached market dominance by breaking the law. As a result of that prejudice, I have maintained a carefully cultivated ignorance of all things Microsoft -- until recently. In the past weeks I have found myself in a position where I had to do some Windows development for the first time in my career. So I am far from an expert, but I do now speak from firsthand experience when I say that, in my humble opinion, Windows is every bit the horrible monstrosity on the inside as it has always appeared to me to be on the outside. And, BTW, my opinion is shared by colleagues who know a lot more about it than I do. So yes, my opinion on this is not as well informed as it might or should be, but I have not reached in a total vacuum either.

lisper 13y ago

> You overlooked the fact that programming model of windowed/GUI applications is quite complex and very sensitive to non-cooperative code - a thread that frequently blocks for 100 ms can cause very unpleasant hiccup. No, I didn't overlook this. But this is 2013. IMO, a multitasking architecture that is "sensitive to non-cooperative code" ought to be considered broken, and so if that's the cause of this problem, that still counts as Microsoft's fault in my book.

nknighthb 13y ago
It's now 2014, actually, and you're talking about a problem from 1997, in an OS where backwards compatibility has been an extremely high priority since the 1980s.
- lisper 13y ago
  > It's now 2014, actually Is that really the kind of discussion you want this to be? > you're talking about a problem from 1997, The last revision of the article is 2002. But your point is well taken. I had assumed this was a current issue. (Maybe it is. I don't have time to dig into those details right now.) > in an OS where backwards compatibility has been an extremely high priority since the 1980s OS X was introduced in 2001, and it could run OS 9 applications, so these kinds of problems can be solved if a company decides it is worthwhile to solve them.
  - nknighthb 13y ago
    > Is that really the kind of discussion you want this to be? Yes. If you're going to chastise people based on what year it is, you damn well better be right about what year it is. > OS X was introduced in 2001, and it could run OS 9 applications OS X booted a modified copy of OS 9 to accomplish that. It didn't fix anything about OS 9. It also wasn't present on Intel Macs, nor on Leopard, the last PowerPC-compatible version of OS X. Nor was it fully compatible -- I always had trouble with it, and have kept older System 7 and OS 9 Macs around rather than put up with it.
asveikau 13y ago
In that case I look forward to the lisper UI toolkit, which stays responsive when application code stalls on a UI thread. I'll bet it goes well with the lisper dynamic linker, which I hear completely isolates me from bugs of code living in the same address space. Kidding aside, I can't help but think that you keep going back to that "clearly the mutex is broken" analogy I mentioned earlier. If I read you correctly, it doesn't matter if the Oracle code is breaking the rules set out by the MS documentation, Microsoft should account for all possible bugs past, present and future and prevent them. Seems like that's asking a lot. The other platforms I've worked with don't seem to satisfy this either. What bothers me more, though, is how preemptively dismissive you've been about Win32 while showing something of a lack of knowledge on how it works. I don't think Win32 is perfect. (Ask me about filesystem behaviors some time.) At the same time I have gotten to know it and can appreciate areas where it works well. I would also hope that before making the kinds of comments you are making about any platform, I'd get to know the framework a bit better first.
- lisper 13y ago
  > I look forward to the lisper UI toolkit I might not be able to show you such a toolkit, but I can certainly show you an operating system that allows you to write a database driver whose behavior is not affected by the user moving the mouse. > it doesn't matter if the Oracle code is breaking the rules set out by the MS documentation Of course it matters. I just couldn't imagine what rule there could possibly be that is both 1) broken by a database driver and 2) reasonable, that could possibly result in said driver displaying the behavior in question. (I can imagine such a rule now because to3m pointed out a reasonable possibility in another branch of this thread.) > how preemptively dismissive you've been about Win32 while showing something of a lack of knowledge on how it works I freely confess to being (at least potentially) prejudiced against Microsoft's technology by my anger at the fact that they reached market dominance by breaking the law. As a result of that prejudice, I have maintained a carefully cultivated ignorance of all things Microsoft -- until recently. In the past weeks I have found myself in a position where I had to do some Windows development for the first time in my career. So I am far from an expert, but I do now speak from firsthand experience when I say that, in my humble opinion, Windows is every bit the horrible monstrosity on the inside as it has always appeared to me to be on the outside. And, BTW, my opinion is shared by colleagues who know a lot more about it than I do. So yes, my opinion on this is not as well informed as it might or should be, but I have not reached in a total vacuum either.