rehack

Hi all. I updated an intel laptop from SP2 to SP3 via windows update, and after restart it fails to boot. It gets to the black loading screen with progress bar at the bottom, and that progress bar just keeps going and going (albeit 1 tick every second; slower than normal). I've left it for over an hour, still nothing. Booting into safe mode gives a blue screen that only reads "+ _", no stop errors, nothing but those two symbols next to each other. Booting with last known good configuration leads to the never-ending progress bar again. Enabling boot logging fails to produce the ntbtlog.txt file. Nothing it written to the registry during bootup. Nothing is written to the event log either. The drive itself is fine (according to chkdsk). How can I diagnose this? I have no way of knowing which driver it is dying on, since boot logging won't save any output. Very infuriating. I'm open to any suggestions whatsoever. I'd rather not have to reinstall XP, but it is of course an eventual option.

itunes can support ogg just fine, it just needs a plugin - http://xiph.org/quicktime/ however this won't allow an ipod to play them, just itunes itself. converting mp3 to ogg, with any tool, will still result in a very low quality file.

converting from one lossy audio format to another is a terrible idea from a quality point of view - this is only something you should do if your playback device can't support ogg files.

it would be much easier to just play star fox in a snes emulator, disable any sound channel that doesn't have a voice on it (the snes spu had 8 sound channels, so you only have 8 to go through. check documentation for this, i know zsnes and snes9x can both selecively disable sound channels), and use its built-in wav-file logging. you'll get better, well perfect quality really.

the idea that this could in any way be inferior to microsoft's own bundled defrag is a bit odd, since they both call the exact same functions to perform defragging (i.e., the exact same defrag functions that ALL other defraggers call, diskeeper, contig, etc.). plus this utility forces contiguous space optimization, which microsoft's utility notably fails at (it termintes operation sooner, to appear faster).

Now, go here : I don't know any compiler other than VS that handles ATL so we'll need something else. Or maybe someone can do compile it for you. the atl is confined to 2 header files that just prototype the com exports - everything else is pure win32 (hmenus and all). but i don't know how annoying it might be to export the com interfaces without that atl header

about all i could imagine this wouldn't do is be able to track file usage patterns and store files on the disk in the order they're most often read.. a very useful optimization to be sure, but this program has just blown me away in terms of no-nonsense functionality, small size, no resident services that eat up 10+ mb of ram.. i'm just glad i found it. and i love the screensaver mode. defrag while idle, it's perfect.

i just have to chime in with JkDefrag, as i did here! i've always been horrified by how unfathomably huge the commercial defraggers were, for something quite simple conceptually, not to mention the actual defrag apis they all use are built into windows! hooray for something free, fast, compact, open source, etc.

this looks pretty straightforward for the cascading menu: http://www.codeguru.com/cpp/com-tech/shell...icle.php/c4505/ and i don't believe it'll require any libraries you either can't get from ms through free sdks, or include from lcc-win32's/mingw's free set.

i'm amazed i haven't seen this before, but JkDefrag is everything i've wanted in a defragger: - it's small like it should be (300kb download) - open source - uses the windows defrag api so it's as fast/safe as every other defragger - has a gui for those who absolutely must see a pretty picture - also has a gui-less version that runs silently whenever you like it to - performs a full contiguity optimization unlike the standard windows defrag - .. and is just friggin awesome. i hope someone else enjoys finding this as much as i did!

any ideas? just tried it again, this time leaving the 'keep files' dialog completely empty (no printing files kept at all), and sure enough my driver.cab is still full of printer dll/gpd/ppd/etc. files. i'm just not sure what kind of conditional statement the code runs that could allow this

ah this is the topic i was after! i've been using nlite since version 0.9-something, and *always* had intermittent problems with removal of printer files from the drivers.cab file. this was with win2k, and now having moved to winxp i was hoping that problem would vanish, but apparently not. to troubleshoot, i would select printers for removal, start the process, open up the drivertmp folder that nlite created, and watch to see whether the signature ppd, gpd, cn*.dll, ep*.dll, hp*.dll, etc. files were removed. almost every time, regardless of nlite version, none of the printer-specific files would be purged. sometimes, using the same nlite version, preset, and source files, they would be. there was absolutely no common factor i could find. nowadays i've gotten so frustrated with it that i just paste in a routine list of printer files that may or may not preserve pdf printing functionality (i never did see a set list), let nlite go about its business, and once every 10 times i'll get lucky and drivers.cab will actually shrink down to ~10mb instead of ~50mb, like it did just now, despite having selected printers for deletion. windows attempted: win2kpro sp4 win2kpro usp5.1 winxp home oem sp2 winxp home oem sp2+ryanvm update winxp pro sp2 winxp pro sp2+ryanvm update lastsession.ini i just used - it failed to remove printers on a winxp pro sp2+ryanvm: http://www.sendspace.com/file/xv8aey

well the way the format works is that you have a keyframe which is stored as a full complete picture, then following that keyframe, you have a bunch of 'incomplete' pictures which only store the difference between itself and the frame that came before it. some formats can look back more than one frame, some can look forwards too (bidirectional). so, when you want to cut the end off of something, that's easy - you just store the last keyframe in that segment, and the following incomplete frames that depend on that keyframe... then you can just drop off the other incomplete frames you don't want, since nothing depends on them keyframes are set when the codec is either forced to (by user setting) or the codec has determined that a frame is 'different enough' from the previous frame to signify a scene change, or it's just decided that it would actually use fewer bytes to store a keyframe than a very-complex incomplete frame. it sounds like the codec was smart enough to guess the scene had changed in most of your files and inserted a keyframe, however that detection either failed, or was disabled for the file that's giving you problems. what you can do is, re-encode (using virtualdub) the frames you want to keep, i.e. from 36 til 80, with the same codec as the original file. then cut the original file from frame 81 onwards. then use virtualdub to append the first re-encoded segment with the post-81 cut (this will work since the video codec, audio codec and sizes are all identical) and you'll have your finished file. i believe there are some programs which automate this cut-and-reencode procedure, but i can't think of any names right now.

virtualdub can only start a cut on a keyframe boundary. as you say, the first two keyframes are at frame 0 and 81. therefore, unless you re-encode those first 55 frames you want to keep and then stitch it together with a cut from frame 81 onwards, virtualdub just cannot do it. it's a limitation of the avi format. the frames from 1 through 80 depend absolutely on the frames that came before it. you say it worked on other files - that's because they either had a keyframe where you wanted one to be... or it just did a seek to find the next keyframe after 0 and cut from there. believe me, i've done a lot of programming involving avi parsing and virtualdub filters - virtualdub absolutely cannot do a lossless cut unless the first frame is a keyframe.

you mean extract all *.??_ files, recompress as a solid 7z archive, then reconstruct the *.??_ files after download? that'd save 27 MB from the download: (*.??_) = 102 MB, and all those files extracted and 7z'ed = 75 MB. you could also extract the two driver.cab files (42 MB and 30 MB) and combine them to one 7z archive (34 MB) to save another 38 MB. that's 65 MB saved overall. of course the price of this is sitting through the re-compression on the user's side. it'd take around 10 minutes on a current system. i don't think that's a huge price though - how often do people apply service packs? there'd always be the option to leave the reconstructed version on the hard drive so it only has to be done once. it could be worth it as another download option at least. w2ksp51.exe as 144 MB vs 209 MB?

i'd just like to say it's working great! applied it to a vanilla win2k, used nlite to get it down to a 135mb iso, and so far it's done everything i've asked of it. wonderful job.

yikes never mind, windows file protection contains several subfiles of that folder in sfcfiles.dll (in unicode format, so file searches weren't finding it), and even though the files aren't installed it still keeps a lock on that empty directory. what a waste of time.

i'm sure everyone's familiar with this folder on their own machine - because it's there no matter what! apparently it's opened by winlogon.exe and can't be deleted, but the real test here is threefold: - when is it being opened - why is it being opened - how can it be permanently removed any takers? Title edited -- Please, use [TAGS] in your topic's title. Please follow XP Forum Rules from now on. --Sonic

Brilliant!

I appreciate you looking into it. I actually got very interested in how something like the usp was put together, and started doing diffs to see how to automate adding multiple fixes with overlapping file versions. But once I saw how much trouble it was to integrate packages that prefer manual installs (dx, ie, wmp..) I figured I'd leave it to someone who's already gone through that hell =)

Oh - C: and D: are both FAT32, C: has DOS 7 installed (whatever win98 came with), whenever winnt.exe is ran it says "Please supply setup with windows setup files location" or some such, which it always correctly guesses as D:\w2ksp5\i386\. The working w2k's copy files to C:, execute them from there, and prompt afterwards whether to change C: to NTFS, the usp5.1 version never gets that far. I'll spend some time tomorrow comparing what's copied to C: by the various versions.

The working win2k installs ask you whether you'd like to convert C: to NTFS or leave it FAT32, after they've successfully copied the files over. I'll compare the files dumped and see what we have. In all cases, failure to specify source file location makes setup prompt you and ask the location, which it guesses right. I just don't understand why w2k and w2ksp4 work fine, but w2ksp51 fails from a dos install.

reperformed slipstream 4 times now, off 2 different win2k masters. download is a-ok, checksums and extraction verify it. for whatever reason, slipstreaming corrupts the working w2k install files. how about this - i can post a before/after list of md5 sums for the entire i386 directory. if someone else can do the same, and my installation matches a working one, that means it's the new computer that's causing the grief. i used md5summer to create these: before and after md5 listings of virgin w2k and usp5.1 w2k these could be compared against someone else's list with something like winmerge.

Here is the procedure I went through: - copy contents of win2k (original edition) to hard drive, at d:\w2k - from command line, run w2ksp51.exe -integrate:d:\w2k (integration is performed and proclaimed as a success here) - copy d:\w2k to a new computer at d:\w2ksp51 (new computer is partitioned) - put msdos onto new computer's c: drive - it boots up fine - after booting up new computer, execute d:\w2ksp5\i386\winnt.exe after some file copying, this produces the following: The [Files] section of the Setup Information File is not present or is corrupt. Contact your system administration. Setup cannot continue. Press ENTER to exit. now i've done a lot of slipstreaming and installations before, and this error message has only ever appeared to me when i've slipstreamed a service pack into win2k, have neglected to update the txtsetup.sif contained in the bootdisk images, and then used the bootdisk image to install (txtsetup.sif mismatch between bootdisk and i386 folder). the only conclusion i can think of is that the integration silently failed and corrupted the txtsetup.sif file. it's definitely present, has a large number of [files.xxx] entries and isn't visibly corrupt. if i replace the d:\w2ksp51 folder with the vanilla w2k cd contents, or a w2ksp4 build, they both install fine. same computer, same msdos host, same install location, the only variable that causes failure is usp51 being slipstreamed. any ideas? here's the md5 of the txtsetup.sif that was generated: fc2c314a1d96d7108a58235148dc6e8e