Problem with XP scheduler?
in [Win32 Kernel]
|
From: Paul Baker [MVP, Windows Desktop Experience] on 14 Jan 2010 17:09 You should realise that even if you are only running the system, pre-installed services and Windows Explorer as the shell, you may still be executing "potentially evil" third party code that did not ship with the OS, especially shell extensions and Browser Helper Objects. Try AutoRuns from SysInternals if you want an eye-opener. Paul "tanix" <tanix(a)mongo.net> wrote in message news:himg88$jsn$2(a)news.eternal-september.org... > In article <OlI#ogMlKHA.5020(a)TK2MSFTNGP02.phx.gbl>, "Alexander Grigoriev" > <alegr(a)earthlink.net> wrote: >>I think explorer doesn't keep the icons preloaded. Every time it needs to >>redraw the desktop, it scans the desktop folder and reads all the icons. >>If >>the files fell out of cache, that will cause disk access. Win9x used to >>have >>shell icon cache file, but it was getting corrupted often, supposedly >>because of lack of proper synchronization in the code. > > The point is that desktop needs to be managed by the OS. > No matter what some app does, it should not affect the OS managed > things, such as desktop. > > I have no clue which "evil" apps I have, but I do see these desktop > redraws quite a bit and that happens not when I am running some > program, but when I am using the OS related programs such as > explorer. > > No matter what I do in ANY of my explorer windows, and I typically > have 4 to 6 of them opened at the same time so I can quickly move > things around and open files in those directories, > it should NOT cause the entire desktop redrawing. > > And I bet MS knows about this situation for years. > But, for some strange reason, it is not getting fixed, > which means to me that this issue is so fundamental, that they > can not even fix it, no matter what they do. > > Which, in turn means, there are some scheduling issues that > cause the events to get routed to the wrong client in some > cases. I can not speak for MS. The OS guys can shed some light > on it. But I really do not appreciate THIS kind of thing > happening to me, especially when I deal with operations that > may produce hundreds of thousands of files and modify my > major archives or move things around to the places I do not > even know. Because I do not know what exact event was mishandled. > >>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message >>news:e11KsmHlKHA.5604(a)TK2MSFTNGP04.phx.gbl... >>> Paul Baker [MVP, Windows Desktop Experience] wrote: >>> >>>> I don't think you're talking about the screen buffer. I think you're >>>> talking about the desktop window being invalidated and therefore >>>> receiving a WM_PAINT message, and possibly a WM_ERASEBKGND message. >>>> Then >>>> it has to redraw itself. I have never seen this happen when you click >>>> the >>>> "+" in the folders pane in Windows Explorer. Certainly, it is not the >>>> usual case. There is some other condition causing it, almost certainly >>>> unrelated to the OS. >>> >>> >>> Well, I don't recall if its the "+" but I must admit I have seen many >>> times where "out of the blue" for some apparent reason, there is a >>> desktop >>> refresh where all the desktop ICON go blank and and refresh themselves. >>> It can be 1 to 2 seconds and yes, at times, it appears to take a lot >>> longer and everything stops until it is finished. >>> >>> Why? >>> >>> I have my ideas of course, but I have not spent the time to pin-point it >>> down to any particular action. I'm not defending or condone the >>> direction >>> this thread has taken, but no doubt, it happens and you can't help but >>> have that momentary thought to wonder what you just do or what did the >>> system do that cause it. If any thought was put into it, was the idea >>> that Windows is just getting more overhead, doing more and it when it >>> comes to refreshing the desktop, there is some contention somewhere that >>> slows it down. I will say that after upgrading to XP SP3 in the last >>> week >>> of December, I thought I noticed things were slower but it appears to be >>> ok "back to normal" again. I am one that don't like anything slow. >>> >>> I should note, I have 50% or more of my desktop filled with ICONS :) And >>> I >>> pretty good/fast (not cheap) graphic cards. >>> >>> -- >>> HLS >> >> > > -- > Programmer's Goldmine collections: > > http://preciseinfo.org > > Tens of thousands of code examples and expert discussions on > C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP, > organized by major topics of language, tools, methods, techniques. >
From: Paul Baker [MVP, Windows Desktop Experience] on 14 Jan 2010 17:10 Yes, there are a number of ways a library can inject itself into most processes. Paul "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ezF98PPlKHA.1536(a)TK2MSFTNGP06.phx.gbl... > tanix wrote: > >> No matter what I do in ANY of my explorer windows, and I typically >> have 4 to 6 of them opened at the same time so I can quickly move >> things around and open files in those directories, >> it should NOT cause the entire desktop redrawing. > > > Explorer is just another application. Try replacing it with something > else at least to compare. I've seen clones out there. > >> And I bet MS knows about this situation for years. >> But, for some strange reason, it is not getting fixed, >> which means to me that this issue is so fundamental, that they >> can not even fix it, no matter what they do. > > > Tanix. I still say that you might have something going on in your system. > > Why? > > Precisely for the reason you stated - its so fundamental there would be > millions of reports. No one would like to see their system behave as you > describe. No one, and IMO, this would not be something MS would ignore. > > But I have not seen or heard of the severe annoying level you are > describing. Therefore IMO, I think it is machine related or you have some > explorer registered hook that is interfering. > > I recall several years back I found an interested DLL hook at CodeProject > that registered a hook into explorer. If I remember, it allowed you to see > the REGISTRY in the Explorer window. I don't recall if it did things with > the DESKTOP ICONS but it was so annoying and it was differently changing > the behavior of system, slow if I remember that I had to get rid of it. It > was hard to remove but finally did. > > -- > HLS
From: Paul Baker [MVP, Windows Desktop Experience] on 14 Jan 2010 17:11 Windows Explorer is not part of the Kernel AT ALL. It would be better to say it's not technically part of the OS, it's a shell. Paul "tanix" <tanix(a)mongo.net> wrote in message news:hinshm$akl$1(a)news.eternal-september.org... > In article <#lKYp5SlKHA.4408(a)TK2MSFTNGP04.phx.gbl>, "Alexander Grigoriev" > <alegr(a)earthlink.net> wrote: >> >>"tanix" <tanix(a)mongo.net> wrote in message >>news:himg88$jsn$2(a)news.eternal-september.org... >>> In article <OlI#ogMlKHA.5020(a)TK2MSFTNGP02.phx.gbl>, "Alexander >>> Grigoriev" >>> <alegr(a)earthlink.net> wrote: >>>>I think explorer doesn't keep the icons preloaded. Every time it needs >>>>to >>>>redraw the desktop, it scans the desktop folder and reads all the icons. >>>>If >>>>the files fell out of cache, that will cause disk access. Win9x used to >>>>have >>>>shell icon cache file, but it was getting corrupted often, supposedly >>>>because of lack of proper synchronization in the code. >>> >>> The point is that desktop needs to be managed by the OS. >>> No matter what some app does, it should not affect the OS managed >>> things, such as desktop. >>> >> >>Desktop is an application (explorer.exe), no worse no better than other >>apps. > > True. With one exception, which is applicable to this specific case. > Explorer is a part of the OS package. Yes, it is a user app, just like > any other and not a part of kernel proper. > > But... > > If there are some issues with explorer, then there are more than enough > reasons to suspect the issue is much more profound than it looks on > the surface. > > I do think that because of not stricltly async nature of event > processing as a result of optimization, we do observe such unpleasant > behavior of clicking on something and getting a totally inappropriate > event processed as far are what user would expect to happen. > > How many times task switch occurs per second or per anything is > irrelevant. What is relevant that there seems to be a forced > synchronization with the mouse click events. That is what I see in > terms of user interaction while using the standard OS programs. > And to me it looks like a bad design/optimization. > > Looks to me if things were not artificially synchronized, > this problem would be orders of magnitude less severe. > > There seems to be an issue with event routing under certain > circumstances. > > -- > Programmer's Goldmine collections: > > http://preciseinfo.org > > Tens of thousands of code examples and expert discussions on > C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP, > organized by major topics of language, tools, methods, techniques. >
From: Alexander Grigoriev on 14 Jan 2010 22:53 "m" <m(a)b.c> wrote in message news:uuFwl7XlKHA.1824(a)TK2MSFTNGP04.phx.gbl... > > All of this inherited from Win16 and, except for the performance > optimization of using the KM component win32k.sys, has nothing to do with > the NT kernel - it is the foundation of GDI and every UI element on modern > Windows (well there is GDI+ too) > Not quite. Because of Win16 cooperative multitasking (essentially single thread), SendMessage is always in line. The only difference is that it may cause stack switch.
From: Hector Santos on 14 Jan 2010 23:01
m wrote: > Agreed - the problem that tanix is having is not on his machine, but in > his head: his expectations are not consistent with either the OS's > implementation or canonical OS design. The problem is that he doens't read well. :) I suggested to replace EXPLORER for COMPARISON to see of the problem is related with the stock explorer shell. He took that to mean to permanently replace Explorer. Go Figure. -- HLS |