Albuquerque

hard day at work today Albuquerque? LOL Actually yes, it's been a bad several weeks. My company has put me on a project to roll out "Live Meeting" and the manager who's running it is a micro-managing mongerel who deserves a long relaxing session of acupuncture using eleventy brazillion dull steak knives followed by a warm bath in molten steel. That all being beside the point, the reply I posted above has become my defacto standard reply to every whiner, moron, flamer and loser I meet in real life who has nothing else better to talk to me about except how bad Vista sucks. And no matter how many well-deserving things in Vista I can retort with, basically all of them have their head stuck so far in the sand (or other rear-facing bodily orifices) that they simply refuse to listen to any logical thought that can be provided as to why Vista might actually be better than they suggest. Every single thing that's been lobbed at Vista has been lobbed at every other "new" OS that Microsoft has ever put out. It uses more memory. It uses more processor power. It requires better hardware. It has compatibility problems with applications (that are coded shoddily or are extremely old). Well guess what? The OS you're comparing it to is at least four years old, and four years ago, that's the hardware that was available. This is TODAY, and TODAY's operating system will run on computers built TODAY. And guess what? They have more memory, they have more CPU cycles. They use applications that aren't built 15 years ago using a 32-bit wrapped version of IBM REXX. It is my opinion that Vista is probably THE most forward-thinking operating system that Microsoft has taken on to date. I could give you a laundry list of reasons why, and it still wouldn't matter because some anonymous e-tard on this forum would retort with "You're dumb, Linux > all, it uses memory, it takes up CPU cycles, blah blah cry river wah mommy" and it would go nowhere. So fine. You don't like it? Then don't buy it. Don't install it. Don't use it. It isn't required that you use Vista, just like it isn't required that you use XP, or 2000, or 98, or even 95. It isn't even required that you use a PC to begin with... If operating systems give you this much heartburn, go buy a Console and have it done with. Or maybe a MAC, because lord knows Macs don't have any problems at all compared to PC's (cough*BS*cough) There are those segments of the population who's sole happiness in life is to create drama and cry about something. The best thing the rest of us can do is tell them to take their sobbing drama to someone else who might remotely care, and leave the other 92% of us alone. Know what I mean?

Physically impossible. Vista's new driver model, WDDM, is the foundation of DX10. Multiple pieces of this new WDDM and DX10 are directly linked to a serious kernel overhaul, major changes in how data passes through the driver stack, and significant changes in how low-level hardware is exposed and controlled. Windows XP has absolutely zero way to "emulate" these changes, and as such, Microsoft has already publically stated (in multiple cases, please search this Vista forum for a direct link provided by me) that DX10 will never become available for any operating system released prior to Vista. Period. Back to the folks who are bashing Vista -- guess what? Don't buy it. Don't warez it. Don't even so much as blink at installing it EVER on any computer that you own. No exceptions. That way, myself and the other millions of people who will be using it don't have to listen to you whine, cry, b*tch and complain incessantly. Good riddance.

The above-mentioned piece of batch code will only work if you are starting the script directly from the CD; it doesn't work if you load the ISO to ramdisk from the CD and are running the batchfile from said ramdisk... In that case, you can perform a quick WMI query to spit out all the optical storage devices on your machine: Set objWMIService = GetObject("winmgmts:\\.\root\cimv2") Set colItems = objWMIService.ExecQuery("Select * from Win32_LogicalDisk where DriveType = '5' and DeviceID != 'X:'") For Each objItem in colItems LETTER = objItem.Caption FS = objItem.FileSystem DESC = objItem.Description wscript.echo DESC & "#" & LETTER & "#" & FS next Save that as something like detect cds.vbs and then you can directly run it from your shell script (batch line would read: cscript "detect cds.vbs") It will output the descriptions, then letters, then mounted file systems (if there's a disc in the drive) of all optical drives in your system. I have each output field delimited by a hash sign (#) so it's easy to parse it with a FOR /F "usebackq tokens=3 delims=#" %%A in (`cscript "detect cds.vbs"`) do (... batch function. This way you can support machines that may have more than one CD/DVD rom drive, or machines that may have multiple volumes so you can't always rely on it being on the same letter.

Ok, so two people said they'd try this -- either of you have any success?

Thought I'd throw in my two cents... First is hardware requirements -- I'm on a Dell Inspiron E1505 with a T2300 processor (core duo 1.66), 2GB of DDR 667 ram, and an ATI x1300 hypermemory (64 onboard, ~192mb shared) It's actually quite playable on this crappy old video card at 800x600 at all-high settings minus AA/AF. Or at 1024x768 with medium texture detail and all other settings the same as above. Gameplay is fantastic. I love the part where you're looking at the little "brown ball" in the glass case and wondering what it is, and then teleporting right ONTO it like you're about an eigth of an inch tall! And you can still see the room outside the case when you're that big, so everything is freakin' huge! And then you can run around the ball as if it were a tiny planetoid, so you can actually be standing "upside down" even though you're "right side up" in relation to the surface of the ball. Freaks your head out -- I love it! A definite must-buy in my opinion...

I noticed on my Dell Inspiron that if your "Graphics" rating sinks below 2.5, you lose Aero Glass effects. I had this happen because I was running on batteries while playing with the WinSat app, and PowerPlay had reduced my GPU clockspeed to something like 200mhz. Once I plugged my laptop in, the clockspeed came back and my score jumped by quite a bit. That's how I ended up finding it out Edit Just clicked on the link to your performance rating picture... That explains it! I'm still curious why my x1300 mobility is laying the smack down on your setup? 64mb of dedicated ram on a 64-bit bus at ~300mhz in combination with two pixel pipes with 2 ALU's each just doesn't seem like I should be so much further ahead. Let me post back in a few with my own screencap to show you what I mean...

Microsoft has been talking about this for quite a long time; D3D10 (the actual name, notice it's not DX10, there is no DX10 any longer) is available only for Vista because it is directly tied to the new Windows Display Driver Model (WDDM). Here is a Microsoft Powerpoint named "Intro to Direct3D10" that explicitly defines D3D10 being available only on the Vista platform (see pg 68) There are other sites out there too, just hit Google and type in D3D10 and you'll find an onslaught. If you do Google, make sure to read the search results carefully -- you can install the SDK for development of code, but you can't actually run a D3D10 renderer on anything other than a Vista OS. Sorry to give everyone the downer, I figured most people knew this by now if they were following Microsoft's DirectX announcements with any frequency

This does not resolve the original poster's issue -- the problem wasn't that the framerate was too high, it was that the entire game was running "30x too fast." Unreal's computation of CPU speed is done by a series of assembly instructions that are meant to guess at the speed of the CPU by how fast they're calculated. If your CPU changes speeds between the guess and the game, your game speed goes wonky. Interestingly enough, I came back to this thread after running into the exact same problem on my brand new Dell Inspiron E1505... My Core Duo T2300 was throttling down to 1ghz during the "detect" phase, but then would throttle up to the full 1.6ghz when the game started. This resulted in everything going about double-speed making it near-impossible to do anything (except get my butt kicked by the bots) Just wanted to clarify to make sure you understood this was a CPU speed issue and not a VSYNC / GPU speed issue.

Did you perhaps not read my multitude of replies to this thread? Intel 10.3 drivers + PE 1.6 = works. I'm using it. Right now. And it's not just me, I have ~25 technicians using my CD on dozens of Dell, IBM and HP devices daily without issue. Whatever the problem is in this thread, it isn't specific to the Intel 10.3 drivers and PE 1.6; there's something else wrong in his build that we simply don't have visibility to.

You can do some very simple WMI queries for the first two items (processor speed and memory size). The third option will require a more advanced video driver to be installed; you probably can't do that with that from PE easily. Consider revising your suggestion for a 2.0ghz processor... An AMD at 1.66ghz may perform quite adequately; a Pentium-M would also perform quite well at much slower speeds too.

A quick note about DX10 You will not see DX10 (or it's proper name, whatever that might be these days) on any previous version of Windows. That includes XP, MCE, Server 2003, 2000, you name it; you will get an upgrade to DX9.1 or something similar... Why? Both "new" versions will have support for later hardware, but DX10 will bring performance improvements (in some cases, quite massive ones) because of the way it interacts at the kernel level. More specifically, the new Windows Display Driver Model makes a fundamental change to CPU context switching requirements, constant buffer support and data transfer batching -- among a ton of other items. The net result is a "whole new way" for Vista to interact with the video card and vice versa, a way which fundamentally cannot be "emulated" by any previous Windows operating system. Sorry. If and when we see DX10-only games, it will be Vista-only too. I thought I would also note that DirectSound got a huge upgrade using the same thought process. A lot of time went into moving things far away from Kernel mode, which far-reduces context switches which automatically offers quite a bit of extra performance. Pushing nonsensical "not actually important" things out of kernel mode also provides for a far more stable operating system should anything go wrong. It also allows for much better batching and queuing of work, and making pieces of "stubborn" hardware actually play nicely with eachother.

Something I didn't mention that might be pertinent: I injected the Intel chipset INF file for 815/845/865/875/915/945/955/975 chipsets. This has some newer USB drivers that fully support the USB 2.0 interface on certain models. I had problems in some early testing with PE where certain USB ports on our Dell Optiplex 260/270/280 would stop functioning after PE loaded -- but not all of them. We found this when using USB keyboards plugged into certain USB ports on the back panel... You could use the keyboard to select the ISOLinux option for booting PE just fine, but once PE loaded, it would completely stop working. I fixed this by loading the Intel chipset INF associated drivers files. At the same time, I may have fixed USB-attached storage working too as I hadn't gotten that far in testing yet. Maybe worth a shot?

You need to make sure that, when you build your PE image, you specified /PNP in the Mkimg command line. Also, you need to make sure your USB device was plugged in before factory.exe runs -- it cannot "hot detect" devices like a normal Windows operating system would. I know that PE detects external USB-connected and Firewire-connected drives because several of my scripts interact with them. I also know Ghost32 works to and from the same devices, so you shouldn't have any problems. I'm using PE OPK 1.6 and Server 2003 SP1 as my base.

I wanted to make sure the n00bs saw this I had an ancient IBM 600E that was dog-slow. The original specs were nothing to be impressed by: P2/333, 96mb of ram, 6gb hard drive, PCMCIA 3Com nic, etc. I bumped the processor up to a P3/800, installed 512mb of ram and a 20gb harddrive and it was still dog slow. It occurred to me that both drives were 4200 RPM cheap models, so I bit the bullet and bought a 7200RPM IBM drive for a hefty chunk of change. That single harddrive upgrade made my laptop go from near-unbearable to almost as fast as my P4/3.6ghz + RAID0 250gb drives + 1gb of ram. Well, at least when talking about booting Windows and doing simple Office apps and internet surfing. Hard drives are, without a doubt and BY FAR the slowest component in your computer. Defragging and cleanup will always help, but sometimes you just need phsyically faster hardware to make it better. If you've got the cash, a 10K RPM Sata drive or even a 15K RPM SCSI drive is the best way to go. If you don't, a pair of 7200RPM drives in RAID 0 will certainly do well too and might be cheaper.

First, I want to ask about this: Why do you think this? Any dual core S939 is still at or above $300 (I found a one-day sale on the x2 3800 for $297 + shipping at NewEgg) and would be handily spanked by a $250 Conroe part at 2.13ghz. If an FX-60 with the bigger cache and higher FSB can't keep up with a 2.4ghz Conroe, why do you think a more expensive A64 at 2ghz on an "old" socket layout is going to compete with a cheaper 2.13ghz Conroe on a new socket that will last longer?Now, about this part: I hope you really don't think lithography process (65nm, 90nm) has much to do with the actual processing performance of any processor. It surely makes the die smaller, which makes it cheaper to manufacture. It also can help somewhat with clock speeds, but they aren't going for uber clockspeeds anymore. Conroe (and Merom) speed increases come from a redesign in how instructions are handled and processed. Intel spent a ton of time focusing on Instruction Level Parallelism, memory latency issues, ALU resources, macro- and micro-ops fusion (taking smaller instructions that might otherwise plug up individual ALU resources or break an OOO processing cycle and making them one bigger instruction that can complete much faster). These are the sorts of things that actually matter, versus just turning up the clockspeed and hoping lithography can keep up (which was Intels' prior methodology that sucked so bad with Prescott) Now consider Intels' new focus on driving down power consumption... Their top of the line Core 2 Extreme (biggest and baddest Conroe they are going to release) has a TDP of 75W; the standard 2.4ghz Conroe will come in at 65W. This is almost half of the heat they're currently pumping with the PrescHOTts and ~40% less than the TDP of AMD's FX60 that the standard Conroe 2.4ghz beats thoroughly in performance. Here's some helpful reading: Anandtech's writeup RealWorldTech's writeup ArsTechnica's writeup

Might I suggest reading the sticky at the top of this page? It would likely answer all the questions you've asked in this post... http://www.msfn.org/board/index.php?showtopic=25128

Not that you asked, but if you're thinking that a faster processor is going to speed up your games, then you're going down the wrong road. That 6600GT is probably holding you back far more than you current 3.46ghz processor speed and gig of 667mhz DDR2 ram.

Yeah, the AM2 benchmarks have been quite disappointing in the recent days. There really isn't much new except for the support for faster DDR2 ram, which doesn't really seem to be helping them at all. I think I saw one individual application benchmark where it gained ~10% over the previous FX generation of the same speed, but nearly all the other benchmarks were no more than about 5% better. In my opinion, AMD will not be able to compete with Conroe's raw processing capacity until next year. That doesn't mean they cannot compete with other technology choices, or lesser cost, or both.

Can't update the BIOS if you don't have the password ... Or in the case of a system such as my Dell or most of the new Lenovo (IBM for you folks who are still behind ) laptops, you can turn on the option to flash the BIOS but it still retains the password even after the flash. You're likely going to have to send it away for $300. On the IBM machines, there's a physical device you must use to reset the password. And I don't mean a simple tool, I mean an electronic card widget that plugs into the board almost like a daughter card... You must yank the mainboard, attach this thing and let it do it's electronic wizardry which will unlock the board. Dunno if it's like that for the HP's or not...

Never saw any replies back on this, so no updates Lemme know if it works, I'm curious just because I don't have any way to actually test and see if these tools function as-advertised since I don't have any spare HP servers laying around

Nope, didn't do anything fancy at all. My PE image is based on the Server 2003 core and PE OPK 1.6 if that helps. The CD itself is based on an ISOLinux 3.09 core if that helps any further... But otherwise, I made no radical changes. The SDI file was previously 95mb in physical size; it's now 115mb in size due to some new tools we're using and it typically takes the M200 about 3m 30s to boot up. Our choice for boot device is normally one of our "floater" Sony 16x DVD+-RW/DL USB 2.0 drives. We use CD media for my boot disc. That's really all the pertinent info I can think of.

If you're on the "allowed list", you already have the link in your inbox. Thanks for the notification, time to go download!

The list I posted is applicable for your needs; it does not impact HTA, VBS, or Java functionality. It also does not impact networking ability, unless the driver you need is one of the drivers that I have removed (in which case, simply remove that entry from my list). The scripting I use has far too many dependencies for me to trust something like NLite or similar; it sounds similar to what you encounter. As for the other posters regarding UPX; compressing Shell32 never gave me any specific "problems" other than terrible memory usage. Other DLL's and EXE's had similar problems to what was described above me -- slow loading, terrible memory usage and occasional hiccups. The only time I now use UPX is on standalone EXE's and other DLL files that I know aren't multi-instanced. For those who are seriously interested in file compression to save ramdisk space the real payoff for space savings isn't UPX... You need to look at NTFS file compression on an SDI ramdisk. I cram ~165mb of data into a 115mb SDI ramdisk, with ~9mb of that as free space for writeable (and compressed!) ramdisk usage for temp files and the like. I'll never go back to the stock ISO read-only method...

Yeah, it came out middle of last week sometime for the registered BETA folks. I've had it on my Inspiron for about five days and it's doing better. I dont' get the incessant "VPU Recover" loop when I hibernate / suspend, although it's not too far different IMO from 5381.1

As I mentioned earlier, make sure to test with files that you've UPX'd. I ran into a problem where VBS could no longer enumerate file system objects (FSO.SetObject stuff). Turns out one of the files I compressed killed that functionality somehow and I never knew it. Also look at ram utilization. You can safely compress a TON of exe's and dll's in the PE build, but many of them will result in massive increases in memory usage. A great example is SHELL32.DLL -- it's 8mb uncompressed, and about 2mb compressed. Sounds like a great way to save 6mb of disk space, especially if you're using a ramdrive, right? Not really, as that 6mb of saved disk space on my build translated to more than 30mb additional memory usage within PE when it was booted. I only UPX-compress DLL files and EXE's that I know are not multiple-instanced, such as format.exe and my BCWipe utility and a few other items. As for my scripts -- they do an "if exist" so it really doesn't matter if your delete.txt or compress.txt has extra entries, as it will only apply the changes to files that exist.