cluberti

If that is indeed the machine, and I'm guessing it is, Vista may not be a good choice. Especially if it's the Celeron version with 512MB of RAM - Vista will not be kind to that hardware.I would also suggest XP embedded or Linux for that hardware as a POS system, as recommended by the vendor.

Or it may not be a video driver leak issue at all - again, you've not shown me ANY data, at all, to back up your claims. What process is the leak in? Is it private bytes, working set, virtual bytes? How quickly or slowly? I asked these before, and yet you've not answered or provided any data. second personal attack. Banned. And yes, I replied with some further info because you write thinking you know what you're talking about, but it's obvious you've never actually seen source code or written any, let alone for Windows or IE. Then you're an id*** (yes, I'm attacking you now, but only in self-defense), because Microsoft is a BUSINESS in a CAPITALIST economy. Go to college and take economics 101 and read up on "profit" and "shareholders" for starters. Yes, I read your drivel. I even replied to your quoted sections in my post, and the fact you can't see it even more shows your lack of logic. Also, you again show your lack of ability to post with a sense of politeness, respect, or even veiled "I'm trying to fake it" sincerity in pretending to be polite, but I've already banned you considering you were warned to tone it down. Because you've shown YOU DO know nothing.

To start, no, I'm not leaving driver problems at the door. First, ATI drivers are some of the worst, and Microsoft doesn't make drivers - the inbox drivers are just repackaged/stripped down vendor drivers, for what it's worth. Second, you've not said anything that makes me think this *isn't* a driver problem - just because you have problems across multiple driver versions doesn't mean somehow you've magically tried to fix anything, if the problem exists across all vendor driver packages. Also, since you're the only one here (thus far) that's complained of the problems you have, and since the Vista code on my workstations is the exact same as yours, it would tend to lean towards NOT being a Vista code problem. Your logic is specious, at best. As far as "removing" DX10, it "works" after vlite'ing on Vista because you can't remove the kernel or DWM components of DX10 (it's not a monolithic package anymore, it's split into parts into the OS - I've already told nuhi about this, but as it seems he's not updating vlite anymore, it's a moot point). For what it's worth, I do "check my sources", and I'm not saying anything inaccurate. Not true - the html engine (webbrowser control) comes out of wininet.dll, urlmon.dll, ieframe.dll, and mostly shdocvw.dll depending on what features you're using - all IE binaries. If you *remove* these, you *break* the webbrowser control engine. Please don't argue with me on this, I've actually written code that uses the WBC and I've seen the IE codebase. I know what it is and isn't, and it's obvious you do not. How far back should Microsoft pay to code, test, and maintain features they plan on releasing in newer OSes? Just because you want them, or found a way to hack enough of it on XP to make it "work" doesn't mean it can, or should, be done en masse. Microsoft is a business, not a charity - when it becomes too expensive to dev or maintain a product, they'll kill it off (5 - 10 years based on lifecycle, of course). First, we again have another problem you have (lag) that I can only repro on my ATI 3650 machine and not my nVidia 9800 box. Driver issue, whether you want to believe it or not. Second, features like patchguard, WIM imaging, language-neutral binaries, native OS search engine, and yes, the graphical candy are all things that I think a lot of us who use(d) Vista like. I have to reiterate, just because you do not like them doesn't make them suck, or bad, or trash, or any other derrogatory term you'd care to dream up to describe them.At this point, you're out for what you are - a Vista basher because *you* had problems with it the rest of us don't, and it also seems you're just upset Microsoft doesn't support Windows 2000 anymore or provide Windows for free, including updates, forever. I'm leaving the thread open because I'd rather see the discussion continue, but try to keep things you discuss to areas you actually have knowledge on. Trying to teach me how the IE engine runs, or what DX10 is, is silly. You're free to your opinions, but you're still wrong. Lastly, your personal attacks to my post and lack of respect for others on these boards (in clear violation of the forum rules) have drawn my ire, so consider yourself warned in accordance with said rules. I did not call you out directly in any way, just answered your questions concisely and completely as I could - yet, you felt the need to make personal remarks about my knowledge, even though you have no idea who I am, what I do, or what my experiences are, so you couldn't possibly make the judgements you have. Tone it down or you'll find yourself banned without further warning.

BTW, I'd still disagree with you that 9x was the original Windows - you forget that NT 3.1, 3.5 and 3.51 were actually out in the Win 3.x timeframe, were 32bit native, and predated Win9x (which was still 16/32bit hybrid) by 2 full years . I'm just nitpicking, of course, the post is fine. I just feel the need to reply to posts that state 9x was the original or true Windows, when it was in fact predated by NT 3.1 by 2 years (and 9x never became true 32bit, making it impossible to port to 64bit and thus one of the major reasons the NT line went forward instead of the 9x kernel - you can't run 16bit code on a 64bit processor when it's in native 64-bit mode). Again, 9x was a fine OS in it's day, but there are technical reasons (and business reasons, of course) why it died as it did.

Those haven't existed for awhile, although it is correct. Also, Windows (since SP2, at least) has a firewall enabled at least on the host to mitigate these. Obviously Vista and Win7 do a far better job at this than 2000 or XP did, which I'd also agree to.

http://www.msfn.org/board/index.php?showtopic=116471 ?

HP's support site has an article on how to go about fixing this so you don't get warnings for the recovery volume. However, if you just want to make the problem go away without making any real changes to your Vista machine, simply open disk management (diskmgmt.msc) and remove the drive letter for the recovery partition (it's only useful from the recovery key in the BIOS anyway, so Windows does not need to "see" it as a drive letter at all).

Well, OK, only because they're using the APIs that don't exist on 9x systems anymore. However, 9x is still a flat memory model with no security, meaning any user-mode app can write to the kernel (and vice-versa), making security impossible. Sure new viruses don't target the >1% of users still using 9x, because there's no return on investment. It doesn't make you immune to anything, only immune to people wanting to take the time to test code on an OS that has no marketshare - with a flat memory model, you are inherently *in*secure. This is true security through obscurity, and while it may serve, it's not because you're immune, it's because your marketshare is irrelevant.However, if ME works for you, stick with it. I see no reason not to, if it meets your needs. True, but you'd have to get the malicious code onto your box to hide itself in the first place, which actually is irrelevant of filesystem. As mentioned above, getting malicious code onto 9x is far easier than a properly-configured NT-based system (running as a user rather than admin), but I know folks run 9x because it works for them. I just hate to see comments that are wrong - 9x has no security, and NTFS is not "insecure" any more than a system with FAT32 in this regard. The malicious code to place an ADS on an NTFS file system got there because it was able to bypass user security (as usual, the security hole is the user, not necessarily the system or the filesystem it runs on top of).I'm guessing the speed factor is fairly moot as well - if you're really hammering your hard drives so often that it matters, then yes, FAT32 for that drive (or ExFAT, or NTFS on a fast RAID volume, if security and file permissions are required or files larger than 4GB).

Deceptive seems a bit harsh, but remember NT4 and Win9x were *different* kernels - obviously both NT and 9x had the same shell (and NT 3.5x and 3.1 had the same shell), but they were still pretty different kernels underneath. I'd say Microsoft chose to go with NT-based systems because (1) they were natively 32bit (and with NT4 and up, could be compiled natively 64bit as well), (2) they did not have a flat memory model but per-process and per-user security, and (3) they were easily portable to other platforms (which was important at the time for NT4 and 2000 and still is to a lesser extent today, to support running on things like Alpha, MIPS, RISC, and Itanium - 9x was always intel x86-only). I can see you like the 9x systems, and I'm not bashing 9x (it was a good OS in it's day, and still is to a point today), but statements like this are patently false and inflamatory for no good reason I can think of. From a business and security perspective, it makes sense to go with the NT-based kernel vs the 9x (flat) kernel for both security and a fairly CPU architecture-agnostic codebase (WinCE, WiMo, WinEmbedded, etc). Because there's a difference between caching a 64bit pointer in a process space with a 4GB max limit versus trying to actually cache the actual stream data without running out of process space.It'd have to be debugged to say for sure, but it seems from your observations that this is indeed an overflow in the fact that the file just can't be cached enough in the 4GB (minus loaded modules and drivers) space before hanging. Perhaps the larger byte sizes actually make it more efficient over the network with the way the stack is tuned in 9x? I haven't tried network copy tests from or to a 9x box in years, but it seems logical that a properly-tuned box for LAN traffic would handle a 64K file stream far better than a 512byte file stream, and could size TCP windows accordingly to transfer more data more quickly, thus minimizing the chance for a buffer backup large enough to hang the 9x box.

In your blind rage, it seems, you've missed something vitally important - to get DX10 to run on XP, they would have had to backport the whole DWM window manager from Vista to Server 2003 AND XP (explained later), the new WDDM 1.0 video driver model, and tested it across all supported XP and Server 2003 versions at the time (home, pro, tablet, MCE, and embedded for XP, and Server 2003 web, standard, enterprise, and datacenter, and likely the x64 variants of both as well). Not only would this have been a huge undertaking for what was already a very late OS (they "rebooted" the whole codebase to run on Server 2003, making it less than easy to backport code from Server 2003's code that ultimately ended up in Vista's DWM window/shell manager, meaning they'd have to backport it twice - once to 2003, then again back to the XP variant of that codebase at the SP2 level) and would likely have made Vista even later to release, but how costly would it have been for an OS that was already 5 years old? Not only that, but to get the WDDM 1.0 spec, they'd have had to backport a whole host of the new kernel as well in the same manner. Ultimately, this is *not* as simple or easy as you've deluded yourself to believe. It's a huge cost (in both code and testing, not to mention maintenance) for very little return on investment (and the possibility that most users at that point are getting all of that work, for free, as the vast majority of folks running XP had likely already paid for their Windows XP copyies at that point in late 2005 / early 2006), and it's also going to detract from sales of your new flagship OS as well, making it even less palatable for management and stockholders. Honestly, if removing IE is your biggest problem with Win7 (and you could conceivably use the "E" variant available in the EU if this is such a big deal), the other problems *can't* really be that bad, can they? Also, care to expand? This is very vague. Also, nuhi has a right to employment wherever and whenever he chooses (although I don't know if he works for Microsoft or not, but if he did, that's his choice to pay his bills and feed his kids, etc). Seems you've got a burr in your saddle and I'm unsure as to why - again, your complaints and problems in this thread are vague, so perhaps I'm missing something, but it seems you've got something against Microsoft in general clouding your judgement. Yes, because if removed more apps based on the webbrowser control or the browser engine (say, the Windows help engine, for starters, and Microsoft passport/LiveID login) fail miserably with no way to fix it (these things break with the E editions now, which *does* have IE removed, but hopefully those will be "fixed" before RTM). To wit, Windows 2000 needed 650MB at minimum (not 400MB as you claimed), whereas Windows NT4 needed ~120MB. Going by your logic, you should also chastise Windows 2000 for such huge "bloat", even though in the 2000 timeframe a large HDD and a good deal of RAM to hold the "bloat" was expensive - a Maxtor 20GB 7200 RPM IDE hard disk was ~$250 in late 2000 when Windows 2000 released, making it ~$14.50USD per gigabyte, whereas a 1TB (yes, that's right, a TERABYTE) hard disk can be had for less than $100USD (~10¢USD/GB). It's just not a valid, or fair, comparison. You paid far more for the same space in 2000, and this would only make any real comparison sense if you could even actually viably expect to run Vista on Windows 2000-era hardware, which would be fairly absurd (you couldn't run 2000 on NT 3.51/Win3.1-era hardware either, which was approximately the same jump backwards in years and versions as Vista is to Windows 2000). Try to see things in perspective rather than simply taking the one point of view, and you'd see your comparisons aren't really logical or fair. Funny, I'm not getting those. What kinds of leaks, perchance? I had a problem with Vista RTM leaking in audiodg.exe, but that was an audio driver issue fixed by realtek, not Microsoft. I'm not saying you're wrong, but I've not heard of any leaks in Windows with either SP1 or SP2, so a little more info on what and why you see it as a Vista problem would clarify your statment. It's very vague and quite blanket on it's face. Again, funny, but I routinely copy 100+GB files across local drives and across the network, and I never see that. More info, again, please, because it seems like less a Windows problem and more a driver or config issue. That's a really good idea - cut off your nose to spite your face, so to speak. Your problems reek of driver issues, and Linux isn't going to magically make your life better - I run Mac, Linux, and Windows Vista and Win7, and I'd take Windows over the others for a variety of reasons every time. In fact, I'd drop the Mac and Linux boxes if I could, but for now I need to keep them running and actively use them. Probably a few things - one, Windows 2000 was basically NT4 with plug-and-play and directx slapped on, so it's codebase was pretty old (technically, XP prior to SP2 was pretty old as well, and most people find it still runs very slick on older hardware - it's buggy, insecure, and doesn't do much in the way of security or features, but it's a virtue some people want - hence the popularity of the xLite suites). Two, Vista prior to SP1 *was* buggy and bloated compared to XP, but SP1 has fixed most of these problems. I think Vista will be a flop in history, but it does pave the way for Windows 7 which (on Vista-era hardware and newer) run just as well for most folks as XP did circa SP2 in 2004, has far more security than XP ever did, has quite a few more features and graphical polish than the lego OS that XP was without classic mode, and was designed natively for x64 (which is far better than x86 long-term, especially for those of us who stress our CPUs regularly - native x64 code flies with the additional 32 registers that 32-bit software can't use). I've hand-built and purchased OEM systems running Vista and Windows 7, and don't run into the problems you seem to be - I don't know if that's driver issues, hardware choices, or what, but given we both have different experiences I'd say it's at least possible that the differences aren't Windows, but other factors like drivers or 3rd-party software (or both, or neither - again, your complaints are a bit vague so I'm left guessing).Ultimately, you're free to your opinions, but again your complaints seem more like someone holding onto the past with driver problems on Vista rather than real, actual Vista-caused problems.

I've had this problem before, and I've fixed it by installing .net 3.5 SP1 after installing Vista SP2 (it was fairly recent). No matter what the checkbox for .net 3.0 was, it never installed. However, 3.5 SP1 contains 2.0, 3.0, and 3.5 bits, and it worked fine (and afterwards .net 3.0 was checked and greyed out in windows components too).

It would likely be illegal to provide you the ISO or install media, however you could always contact the original vendor of the disc (the OEM you bought your PC from, etc) to see if they have any replacements they could send you.

If your network guy doesn't know you can't team NICs attached to an unmanaged switch, you should probably look for a new network guy. Anyway, to be specific, you'd likely need to know the algorithm being used for anything specific. However, the most common at this point is going to be LACP (802.3ad / 802.1AX) - just try to find an unmanaged switch that supports the protocol (and find a managed switch that doesn't, which would also be fruitless ). Do some reading on 802.3ad or 802.1AX if you want to know more. Again, if you want an exercise in futility, try finding an unmanaged switch that supports 802.1AX or 802.3ad. Or, even better, find out what switches YOU are using there and spec them - do THEY support either of those protocols? The answer, if they're unmanaged, is likely going to be "no". For example, you mentioned you were using unmanaged 24 port netgear switches, so I've done a little research for you. The most expensive netgear unmanaged 24-port gigabit switch (JGS524F): Standards Compliance IEEE 802.3i 10BASE-T Ethernet IEEE 802.3u 100BASE-TX Fast Ethernet IEEE 802.3ab 1000BASE-T Gigabit Ethernet IEEE 802.3z 1000BASE-X Gigabit Ethernet IEEE 802.3X Flow Control And to contrast, the cheapest 24 port gigabit "smart" switch (not even fully L2 managed, only partial managed switch features - GS724T): Network Protocol and Standards Compatibility IEEE 802.3 10BASE-T Ethernet IEEE 802.3u 100BASE-TX Fast Ethernet IEEE 802.3ab 1000BASE-T Gigabit Ethernet IEEE 802.3x full-duplex flow control Administrative Switch Management IEEE 802.1D Spanning Tree Protocol RFC 1157 SNMP v1, v2c RFC 1213 MIB II RFC 1643 Ethernet Interface MIB RFC1493 Bridge MIB Private Enterprise MIB Jumbo Frame Support (up to 9216 bytes) IEEE 802.1Q Tag VLAN GS716T: 64 Static VLANs - Supports 16 port-based VLAN GS724T: 128 Static VLANs - Supports 24 port-based VLAN IEEE 802.1p (Class of Service) DSCP - L3 QoS Port-based QoS (options High/Normal) Port Trunking - Manual as per IEEE802.3ad Link Aggregation // <- Link Aggregation, aka NIC Teaming support DHCP client function Access Control: Trusted MAC Broadcast storm control (GS724T only) Port mirroring (many-to-one) Port setting Web-based configuration, anywhere on the network Smartwizard Discovery Utility program auto discovers devices (up to 254 agents/switches); set system configuration to each agent Configuration backup/restore (easy to configure more than one switch) Password access control and Restricted IP Access List Firmware upgradeable The unmanaged switch was $259.99 USD, and the "smart" switch is $299.99 USD. Hopefully you can see the difference between a managed and unmanged switch (and this isn't even a "fully" managed L2 switch, let alone managed at L3 or higher - those feature lists are usually pages long). So YES, you DO *need* a managed switch to get link aggregation functionality. Remember, it's not just the NIC that needs to be capable. Honestly, if you've got a network guy who doesn't know this, he'd be fired if it were my employee. This is pretty 101 stuff. I don't know what SMC switches you had (I noticed you mentioned you had a mix), but expect the results of checking managed vs unmanaged on that brand to be pretty much the same.

The latest builds are no longer in winmain, they're in win7_rtm and they're in the 726x build range currently. You can find these probably leaked, but I see no real reason to build hunt anymore, as RTM is coming supposedly this month.

Agreed. You can't do LACP or any other aggregation with a L2 or L3 non-managed switch, and even failover and round-robin don't work as well when it's a "dumb" switch.

shdocvw.dll is the shell document viewer, so it sounds like you have a shell extension or add-on that is causing problems. Might want to consider using sysinternal's autoruns and nirsoft's shellexview to disable all non-Microsoft shell extensions and add-ons to see if that fixes things (then re-enable in groups until the problem returns, of course, and go from there on narrowing down which is the culprit).

You can, but only with current HBAs that support it (the switch must as well, although the HP ProCurve I'm using does this). iSCSI still can't hold a candle to fiber in high-volume environments, but in the home and SMB-type setups, it's more than adequate.

I thought I was pretty clear that you need to contact MS for them. They're NOT available to the general public.

Doesn't look like it comes in Italian (only 5 languages listed).

You can either get the ISO in the language you need from Microsoft or your OEM you bought your server from, or you need to get them from your account representative (they're only available to folks with a software licensing agreement, they're not public).

0:000> kn # ChildEBP RetAddr 00 00139608 7739bf53 ntdll!KiFastSystemCallRet 01 00139640 7738965e user32!NtUserWaitMessage+0xc 02 00139668 7739f762 user32!InternalDialogBox+0xd0 03 00139928 7739f047 user32!SoftModalMessageBox+0x94b 04 00139a78 773d7e85 user32!MessageBoxWorker+0x2ba 05 00139ad0 779f1d6a user32!MessageBoxIndirectW+0x55 06 00139b94 779f3ca9 shdocvw!CDocHostUIHandler::ShowMessage+0x10f 07 00139ba8 779d3ee9 shdocvw!CDocHostUIHandler::Exec+0x100 08 0013ae4c 779b2ca3 shdocvw!CDocObjectHost::OnExec+0xac6 09 0013ae7c 7fbcdb93 shdocvw!CDocObjectHost::Exec+0x101 0a 0013afc0 7fb5d474 mshtml!CDoc::ShowMessageEx+0xf3 0b 0013b128 7fa52246 mshtml!COmWindowProxy::Fire_onbeforeunload+0x150 0c 0013b17c 7fb01178 mshtml!CFrameSite::Notify+0x1e6 0d 0013b1c8 7facb45e mshtml!CFrameElement::Notify+0x95 0e 0013b1e0 7fa70f7b mshtml!NotifyElement+0xbc 0f 0013b2c4 7faad7a1 mshtml!CMarkup::NotifyDescendents+0x92 10 0013b42c 0207b900 mshtml!CMarkup::SendNotification+0x7a WARNING: Frame IP not in any known module. Following frames may be wrong. 11 0013b438 7fa81e95 <Unloaded_Eng.dll>+0x207b8ff 12 0013b4a4 76fa0336 mshtml!CElement::Notify+0x686 13 0013b4b4 76fa04cd jscript!GcContext::Release+0xd 14 0013b798 020e17b0 jscript!NameTbl::Release+0x58 15 0013b7c4 7faadefd <Unloaded_Eng.dll>+0x20e17af 16 0013b7e8 0013b960 mshtml!CTExec+0x40 17 0013b868 7c827d29 <Unloaded_dll>+0x1145a0 18 0013b86c 77e61d1e ntdll!NtWaitForSingleObject+0xc 19 0013b994 7fa6af60 kernel32!WaitForSingleObjectEx+0xac 1a 0013d9d8 00000000 mshtml!COmWindowProxy::CanNavigateToUrlWithZoneCheck+0x1d3 0:000> .frame 6 06 00139b94 779f3ca9 shdocvw!CDocHostUIHandler::ShowMessage+0x10f 0:000> dt mbp Local var @ 0x139b58 Type tagMSGBOXPARAMSW ... +0x00c lpszText : 0x001ede64 -> 0x41 +0x010 lpszCaption : 0x001c1dc4 -> 0x4d ... 0:000> du 0x001ede64 001ede64 "Are you sure you want to navigat" 001edea4 "e away from this page?..CAUTION!" 001edee4 ".If you press OK, you will lose " 001edf24 "all unsaved data (Enter Assmt.)." 001edf64 ".Press OK to continue, or Cancel" 001edfa4 " to stay on the current page." 0:000> du 0x001c1dc4 001c1dc4 "Microsoft Internet Explorer" Looks like your java app is trying to browse away from the site, probably with form data on the current page? Also, it looks like the URL being handled at the time was "http://netaccess.mhsnr.org/t0A6-NTAP-BIN/webcptun.exe/PRD/1?KEY=WD-INVISION2LP-INV-5-1-ZZZZ:O:2050:1245866717". I'm guessing this is a full-fledged java app that hides IE, otherwise this dialog box should be visible. However, if it's a java app that runs in IE's process and "hides" IE, this is what will happen on this type of error.

The only reason they aren't being hacked/exploited more than PCs is because there just aren't as many Mac users out there. Think about it. There's no point in creating a virus or worm that's only going to affect <20% of computers out there. True - it's the same reason you find viruses for Windows that *don't* target the Win9x users. Considering the flat-memory model of Win9x, and the fact that any app on the system is "admin" and can write to kernel, you'd expect with such an easy target that you'd find more viruses targeting Win9x. So why not? Because why attack such a small market when you can get the XP/Vista/etc market, and get the most "bang" for your virus dev "buck" (not to mention the virus toolkits out there for the script kiddies are all for Windows).

Comparing Vista RTM and Vista SP1 are almost two separate OSes. Vista SP1 was the "real" RTM release of Vista (regardless of what Microsoft says), so you should at least consider it. However, with Win7 looming, I'm not sure it's worth it anyway.

According to the hitslink graphs (the one Coffee is using), MacOS X overall has 9.81% of the OS marketshare, with MacOS X 10.5 having a 6.39% share by and 10.4 with a 2.49% : http://marketshare.hitslink.com/os-market-...e.aspx?qprid=11

It takes no longer with Vista to copy files than it did with, say, Win2K (unless your network drivers are awful). It's just that it's no longer lying to you and telling you "hey, I'm done!!!" when it's still copying files from cache to disk (or the network). WinXP, for instance, would close the file copy dialog once everything was either in cache or at the intended destination - note the distinction. Vista only closes the copy dialog once everything is *actually* written to disk. Works great here, even faster than XP (and yes, that's to a 2003 file server, so still SMB 1.0). If your network transfer speeds are that slow, don't blame Vista, because it's probably not Vista's fault. And yes, SMB2.0 really is that much faster than 1.0, but you'd of course need a 2008 server or another Vista/Win7 client at the other end of the file copy.As to SMB2.0 vs 1.0, If the Vista machine finds the remote machine uses 1.0 rather than 2.0, it'll fall back to 1.0 - and considering the protocol is slow, complex, and designed long before the advent of fast networks, I'd say moving on isn't necessarily a bad thing in this case.