cluberti

Wait to see what transpires today or tomorrow at WPC 2009 in New Orleans. If it goes RTM today or tomorrow (or even Wednesday), expect it to be announced there.

You forget IE6 was released way, way back in 2001 (3 years before Firefox 1.0, fwiw). It was the most standards-compliant browser of it's day, with the only other real clients available en masse being Opera and Netscape (which was crap by this point). I'm not saying IE6 was perfect (like keeping the broken 5.x CSS2 layout, etc), but it was the most standards-compliant browser available in it's day, in late 2001. At that time no shipping browser really supported CSS2 in any real, meaningful way (other than IE, Opera had decent CSS2 support, but even then not as much as IE6), and DOM2 wasn't ratified until 4 months before the IE6 beta if my memory serves, meaning IE6 didn't have support for it either (and to be fair, it took a few years for the others to get support for it as well, Opera 6 or 7 in 2003, again if I remember; a little fuzzy on the versions).It's the 6 years Microsoft sat on IE6 without changing much of anything, and the fact that IE7 wasn't really a big leap in compliance with standards at the time either, that makes IE6 (and to a point, IE7) so "bad". Ultimately, I think people complaining about IE6 "sucking" and not being standards-compliant aren't complaining that it *was* horrible, they're complaining that it's still a pain to continue to support along with better browsers. I, for one, would love it if Microsoft would drop support for "old" browsers at 5 years (when the OS it shipped on leaves mainstream support, for example) rather than 10, because the way the web moves a 10 year old browser really *is* crap to have to support. Or, even better, treat it as a service pack - 24 months after the next one releases, drop mainstream (unpaid, non-premier) support for the old browser and "force" people to upgrade.

Noise indeed.

It takes about the same amount of time with Word 2003, and on the same hardware, XP takes about 2.7 - 2.9 seconds (yes, I've timed it with a debugger and a stopwatch). These are same hardware, latest drivers for both XP and Vista, and straight installs, SP and hotfix installs to the latest patch levels for both, and a defrag and a reboot before testing for both. XP is *not* that much faster when it comes to loading apps, assuming Vista isn't loaded down (as XP would not be). Yes, there's extra process overhead and ASLR (if the process opts in), but these should not add SECONDS to a process start, only milliseconds.

Probably lots of different versions, or the control has a lot of entry points (each exposed COM interface needs a class ID).

Well, assuming it's the same web code and the same machine attached to both cable and DSL (and from your description, this is correct), consider your cable provider may have a crap routing table to get you to the back-end destination. Consider running a tracert to the DNS name or IP address of the backend server from both the cable and DSL, and I'll bet you see a HUGE difference. I used to have problems with Netflix when I switched to Time Warner cable in my area, and it turns out they were sending me to California, then Chicago, then Florida, THEN to New York where Netflix's streaming servers were (instead of a more... um... direct route - I was in North Carolina at the time...). Needless to say, once they took care of this little routing "glitch", it was just as fast as my previous internet provider.

Windows hasn't had CTRL+ALT+Arrow key functionality built-in, as far as I know, ever. This would definitely be a video driver thing, not a Windows thing.

Well, technically that's true, because it's a folder and there's already a "folder" in the taskbar (Windows Explorer), which would be used anyway to open said folder. I understand what you mean (a direct link to a folder), but technically it's behaving as expected. Whether or not that's good, is probably up to the beholder. But for the sake of consistency, it is at least expected behavior.

Never got a new dump. Honestly it looks a lot like Symantec may be the culprit from further analysis with Mr Snrub and myself, but without pool tagging it's going to be hard to say for certain. It's definitely an IRP leak, which seem to mostly track back to USB devices or FILE objects which are being held up by symevent.sys (hence only POSSIBLY Symantec - could be a bad driver too).

Replmon?

If you've got lots of customization to do, you could look into using MDT + WDS (2003 SP1 or SP2 server, or 2008 server required) instead of RIS. MDT is a lot faster, and WinPE will give you more control over the load process.

At this point, I'd be harassing the OEM to RMA it for a new chip. If it's DOA like that, it's not worth risking a part that wouldn't last as long as a "good" part even if you do get it "working".

You mean like this?

No, 7269 and counting.

The problem I see for something like a ChromeOS is that this isn't the typical Google market. They still make their money on search, and they're the king there because the product is good, and they were the first to provide a good product in that space. The desktop/netbook/whatever OS market is vastly different, and I see this being just like the Android push - a good idea on paper, but once it's out there it'll fizzle. It's not like going into the web search, or even the mobile phone/smartphone market - this is the OS market, where Microsoft (and to a lesser extent, apple) rule. Linux hasn't made a dent in Microsoft's share, and it could be argued that Apple's dent hasn't made any real movement in the market at all (they're stuck at ~10%, with no real signs of changing any time soon). Google's ChromeOS might be great, but it'll make about as much a splash long-term as Linux has.

Assuming after the setting is reset, your local group policy is still set to 'Enabled', run rsop.msc to see what policy is setting it. If the local policy isn't (or wasn't the only policy setting it), you should be able to use rsop.msc (as I mentioned previously) to find it. Otherwise, you can try to run gpresult /z to try and find the culprit once the setting is disabled again.

Look into "roaming profiles" on the Microsoft site.

No, it really is the OS build string + binary build number. All binaries that are actual "Windows" binaries take the OS build number (because they're built out of this particular branch of the Windows tree) plus their own build sequence numbers, if they exist, above and beyond the OS build number.

LOL

Somewhere I read that Microsoft would really like all of us using nothing more than "dumb terminals" with a simple shell interface (probably Microsoft Bob-like!) that would connect to Microsoft and only to Microsoft. We would rent use of an O/S from them, which would reside on their servers. No CD's of software to buy or be pirated. All the software we would use would be rented from them and reside on their servers. Outside of a simple shell interface, our computers would be dumb terminals with not even our own data stored on them. We would pay yearly fees for the rental of the O/S, Microsoft Office, etc. Microsoft would control EVERYTHING, all our data would pass through their hands and there would be no privacy, no using older operating systems or software. If we did not pay our yearly rental fees, BOOM! everything would become unaccessible and we would have nothing more than a useless dumb terminal. Wow, tinfoil hat much? Not you, but whomever wrote that (and whomever would believe it would work, too, I guess... ).

You could runas cmd.exe as a separate user, which would allow you access to using command-line tools to modify permissions. I don't think you can shellexecute explorer windows as a separate user though.

Yes, I edited it by hand from a standard user profile I used as a template to begin with, but I've been moving more and more to reg add and reg delete calls in script to set some simple things, and use local (or domain) group policies to set most other things. I've not run into permissions problems that you say you're seeing, but I've not been overly hackish either, and didn't change a whole heck of a lot from the defaults (hence why I've been trying to move away from it - I'm currently testing a build that uses nothing but a logon script and group policy to make changes, which is working fairly well so far).

A quick test might be to take it to a machine that you've verified it works in, and try both the pass-thru card and the add-in card to see if you get the same behavior. Assuming you've got basically the same installation of XP at work and at home, it's possible it could be a configuration issue but it's less likely. At least we know the HDDs themselves are fine, but I'd make sure both the cards you're using work in "known good" hardware first before saying they're not the problem. Unfortunately, you are still left with the possibility that the motherboard or chipset is at fault, but again without further digging it's hard to say.

I'm not sure who said the /integrate switch will work on anything less than Vista, but /integrate works via slipstreaming into a WIM file (and it has to be a Vista or greater .WIM, too). /integrate expects the Vista package manager, which it won't find on XP or Server 2003.Also, that error (0xe0000102) you see comes from setupapi, which basically means "not found". It's looking for files and a setup catalog that would exist on Vista, but won't on XP, hence the failure. You'll have to do as a previous poster said and use one of the manual integration methods, or a premade add-on pack. You cannot natively slipstream IE8 into XP:

Not to mention the Vista driver model for certain devices (like video and audio cards) isn't the same, so a *true* Vista driver for either of these won't work on XP at all (for example). If you have XP drivers, it would be far better to use those. At best, the drivers won't work in XP at all, at worst your XP installation will be unstable or won't work at all.