LLXX

My Abit PX7 with Pentium 233MMX from 1993 could boot from a USB (1.1) drive. This feature is not very new. However, whether or not the manufacturer has decided to implement it is the question...What exactly are you trying to do? Install Windows on the main HDD by using an external HDD to hold the setup files, or boot Windows XP from that external HDD?

The operations that the program does does not require SSE, and SSE does not make binaries bigger - quite the opposite, since the point of SSE is to replace many instructions with one, to operate on several data values simultaneously thus increasing speed and decreasing size (i.e. increase efficiency).Also, don't forget that the author would have to enable SSE opts explicitly (/Ox /arch:SSE) for it to have an effect - this option is disabled by default for compatibility reasons; seeing as the released binary was seemingly compiled in debug mode, I doubt he even knew. Would be interesting to see what speed and size of binary would be obtained from a newer compiler at max optimization though.

Windows Defrag works fine. Let it run overnight.

CPU fan plugged in and working correctly?

Might actually be 12.10. Look for the divider settings on the monitor software.

The users here might be able to help you better.

How exactly is Anonymous "fixing" these files? What differs between the file deletion code between 5.x and 6.x shell DLLs? If it has to do with resources, is there a resource leak in the code? ...yes, I'm planning to fix this one myself too. With regard to localise, is possible just to hit several bytes with hex editor in code section to make it work... (If I sound a bit stupid, just ignore me. I'm a bit... 'off' right now ) Edit: Just reinstalled IE6 again so might as well do the 16K files test with this Anonymous's shell32.dll, it froze for a minute after the deletion (which took all of 12 minutes) but then everything seems to have returned to normal ! I replaced it with my original shell32.dll and 5.5x browselc/browseui dlls, here are the results: 1,6384 files. Let's select them all! After pressing Delete, the confirmation after ~5 seconds. Deleting. 30 seconds later. Success For some reason the patched and original 6.x dlls make the deletion process go very slowly. 23 files per second for the 6.x browseui/browselc with patched shell32, vs 550 files per second for 5.5 browseui/browselc and original shell32. I am typing this post up immediately after the deletion, everything is working fine - system resources 92% before delete, stayed at 92% during the delete and afterwards. Now with IE open it's at 84%.

I think those were the BBs.I have a pair of WD1200JB and they've been fine for 2 years of continuous operation.

One binary - or heck, ALL my binaries could grow by 200kb, and it wouldn't make much of a difference at all. It would add ~1GB to my current \windows directory tops - all of 30 cents worth of space wasted, big deal. Once you manage to shrink my photos, mpeg4 files, and all that by 50% (lossless), then perhaps you can speak about "doubling space"... The binaries here represent a small fraction of 1% regardless. No, I meant those binaries doubling in size. Also, those are the files that are among the most compressible. Photos, mp4, etc. are pretty much compressed already (I'm assuming you mean JPG and PNG/GIF, not BMP), and can't really decrease in size (read about 'entropy'). They ARE getting FAR better indeed. Just not at making irrelevantly tiny apps, but rather FASTER apps (and supporting all kinds of new stuff) - which actually matters (and other ways). Again, the compilers make FAR faster code than your asm - if that's not proof enough... The hardware is getting faster. Compare the executables generated by an older compiler vs a newer one for speed, on the same hardware, to find the real difference. There might be a tiny increase in speed, but that tiny increase is far less than the increase in size. As mentioned above, 1024 times the size, yet only 100 times the speed? Size and speed are often directly proportional, as in the case of opts like loop unrolling and function inlining (indeed, the fastest code is a straight line of execution), and one usually settles for a medium between extreme speed and extreme size which maximizes efficiency. In that case above, maximal efficiency (which balances speed and size) occurs somewhere between 100MB and 100KB."Imagine if all software was 1/128th of its current size, and 128 times faster on the same hardware. This is the level of efficiency that computers were supposed to be able to achieve, yet this ideal is drifting farther away from reality every day."

Not bad, not bad at all. File is actually ~150Kb as they packed it with EXE compressor.

I'd rather just rename the file as MDGx suggests there.

Start -> Run -> "services.msc" Ensure Themes service is running and set to Automatic

Read carefully. What exactly is the error you're getting?If it's an NTFS permissions problem, try taking ownership, and if that doesn't work, use Linux (I'm serious - Linux NTFS access ignores all permissions)

I'm still at a loss to understand what the big issue is. Si there's a 167Kb waste. Okay... on a 500GB hard drive, that's what?, a 0.03% waste? Is that really significant? Just installing the latest game takes up several GBs of hard drive space, and even then, it's still not significant. I can hardly see the point of worrying about it. And by the way, I'm honestly not sure, but /Zi /O0 sounds like debugging, not release, switches to me considering /Zi is for complete debugging info. And you know, I would rather see a program compiled with /O2 (optimize for speed) then with your choice of /O1 (optimize for size). I program that is faster is, IMHO, hundreds of times better then a program that is smaller by a few KB. I would rather have a program that's 100MB in size if it's a 100x faster then the one that's 100KB anyday. No, that's over 50% waste. Would you want to buy a 500Gb HDD and then only be able to use 250Gb of it? Or, the other way around, buy a 500Gb HDD but then use it as if it were 1000Gb?One little prog sure doesn't make a lot of difference, but imagine doubling the amount of storage you have left over. BTW, /O2 gives ~140Kb, and /Ox (maximize speed *and* minimize size, i.e. maximize efficiency) gives ~120Kb. Still a whole lot better than the original, and me recompiling with the options that the author supposedly used (i.e. debug mode) gives ~200Kb. The only thing that I can think would be different is the compiler. I'm using Visual C++ '98, he's probably using something newer. So much for that "compilers are getting better at optimizing code and in the future will be better than Asm programmers" statement. I prefer size over speed, since I seem to have plenty of CPU power. If you prefer speed over size, that's fine too. The point is that going for both maximum size and minimum speed doesn't make any sense

If there's nothing that the batch file can't do, then I suggest you continue to use a batch file instead of a script.

They try not to cut off connections that are already established but don't want to see new ones being created.The ones that were already established are likely going to be very slow, if they're rerouting them somewhere. Try downloading a large file and ensure that it continues to download past the time the connection is supposed to cut off. If you see a large decrease in speed at the time it drops out, then it's very likely.

Interesting.- Make 2 partitions, one tiny and one large enough to hold Win98 - Install Windows 98 on the larger FAT32 partition. - Convert partition to NTFS. - Install DOS 7.0 kernel and filesystem driver on tiny (boot) partition - Boot Win98 from NTFS partition B) I should try that sometime and report back on the results

The reasons for using 9x are starting to repeat themselves even within this thread. I say lock this useless thing. If you think I'm not supporting 9x, the truth is we don't need to be constantly reminded of why we use it, just as we don't need to be reminded of why we breathe.

Wasn't there one in the polls forum?Let's just kick this one back up then... and since this is the general discussion forum anyway, this can turn into a programming quality/efficiency/etc. discussion. That's exactly what I did, but it's still very shocking to see how many lusers can't figure out how to use a compiler correctly, this statement coming from someone who has more experience with Asm than C/C++!I recently downloaded an open-source Pascal -> C converter. The original program file was 280Kb, and on inspection most of it was empty space. All I did was recompile it with my default compiler options (/O1 /Og /Gf /MD) instead of the original (/Zi /O0) and it went down to 113Kb. Another program in the same set went from 28Kb down to 5.5Kb. I didn't touch the source at all, just recompiled it. I don't know who to blame more, M$ for setting such inefficient defaults or the programmer for not knowing that the defaults aren't the best If you want to see an example of good code, look at Donald Knuth's TeX source code.

Release Notes link is 404'd Edit: fixed, but as noted below

Dual-input - great for working with two machines at the same time

That would have to be an extremely badly designed mobo for such to happen. As long as the voltages match, nothing should happen.

The fopen dialog is I think in comdlg32.dll, it uses a syslistview32 control to display the filenames and the syslistview32 can be in a number of different viewing modes. It just sets the syslistview32 to small icons mode when it creates it, this can be easily changed through a bit of hex editing.