jaclaz

The order in which you install the two Windows 2000 instances doesn't make any real difference. But normally you would install the "recovery" partition after having installed the main one. Remember that in both NT4.00 and Windows 2000 the "default" name for the "%Windir%" directory is "WINNT", what I personally use is "WINNT" for the NT 4.00 install and and "WIN2K" for the "main" Windows 2000 install (and I actually use "NT911" for the "recovery" install), this helps (for example in BOOT.INI entries) to quickly see which is which. BTW, after the install of the "NT911" recovery 2K install I used to reduce greatly the size by deleting files I did not need, I guess that nowadays it would be easier/smarter to use nlite to make a very small install media. I would not "trust" Easeus partition manager, not that it is not a good tool , but it is simply "too new" to be reliable (in the sense that all three systems use a cylinder aligned partitioning scheme and they are traditionally very picky with CHS addressing, whilst Easeus may decide to "adopt" the newere MB aligned scheme and/or create "queer" CHS addresses). I would rather use the built-in tools (FDISK initially for the Windows 9x install and later the "inside setup" tools) and (if needed) some more low-level (or more "direct" and not "automagic") tools for MBR and VBR manipulation. Typically I would use RPM (the Ranish Partition Manager) and grub4dos, while having handy (you never know) bootpart. Additionally, if you are going down the way of installing Windows 9x to the logical volume inside extended you might need a couple more tools, Letter Assigner and/or COA2. I know that I am flooding you with a load of information , and that you will need to take some time to digest them , don't worry, it seems more difficult than it is in reality, but you need to get a "general idea" of the possible issues (and corresponding solutions/workarounds) and to have a "plan" before getting to the "practical" part (and consider also how my memory might well be fading as these are things I did YEARS ago, so you will need anyway some patience and likely a few attempts). jaclaz

No. (see below) Yes Sure it is possible . Fake that instead of Windows 98 you are installing DOS (which is what you are actually installing), the simpler would be to install in this order: - Windows 98 - Windows NT 4 - Windows 2000Each windows setup will attempt (and succeed) to write to the disk it's own VBR invoking it's own bootloader, the difference being that the NT 4's one was designed in such a way to allow booting DOS (and conversely Windows 98) and that the Windows 2000's one was designed in such a way to allow booting of both NT 4.00 and DOS (please read again as Windows 98) whilst the Windows 98 (yet again DOS) only boots "itself". There are obviously a number of third party utilities that may allow you to install the operating systems in every order you choose (i.e. fix the booting mechanism) but if you are starting from scratch it would be easier to install them in the given order. I have run for years such systems, the point that is worth some time thinking about is how to setup the partitioning scheme. Both NT 4.00 and Windows 2000 were designed to be installed (apart a few boot files) on Logical Volumes inside Extended partition. Windows 98 was designed to be installed ONLY on First Primary partition. Windows NT 4.00 has some limitations on the size of the volume in which it is installed and it's position. Additionally there is an issue with NT 4.00 and Windows 2000 "sharing" a NTFS volume, Windows 2000 will ALWAYS "upgrade" the NTFS filesystem to it's own version and a few NT 4.00 tools will NOT work properly afterwards (namely CHKDSK) and the NT 4.00 NEEDS to be at least updated to SP4 or it won't even boot. There are however a couple of tricks that allow the installing of Windows 98 (again set apart a few boot files) on a Logical Volume inside Extended. My personal way to setup these three OS has always been the following (you will get a lot of different suggestions about this, it has been debated for years): First Primary FAT16 containing all the boot files and an "emergency" Windows 2000 minimal install, size less than 2 Gb Extended partition containing: First Logical volume inside Extended Windows NT 4.00 install, size 1 Gbytes, formatted FAT16 Second Logical volume inside Extended Windows 98 formatted FAT 32 size 2-4 Gbytes formatted FAT32 Third logical volume inside Extended Windows 2000 install, formatted NTFS .... Last logical volume inside Extended "Common Data", formatted FAT16 size 1 Gb The attempt here is to have all volumes get the same drive letter under whatever OS is currently booting, I always suggest this because IMHO it helps in not deleting by mistake a file on the "wrong" volume. The alternative is to have separate Primary volumes (each with an OS installed) and using a third party bootmanager (such as grub4dos or XOSL) to choose which one to boot, in this case each OS will have "it's own volume" as C: drive, and the other volumes may get "different" drive lettering. (the DOS/Windows 98 boot would anyway to be on First Primary unless you would some more advanced re-mapping in grub4dos or similar) Of course *anything* midway is possible. It greatly depends on how much "dignity" you want to give to each OS, and how (or how much) you intend to work on one or the other, I mean if you use (say) NT 4.00 only sometimes You will need some detailed instructions to achieve this triple boot as it is not "easy-peasy", but it is entirely doable . Start by reading (no matter if you will use it or not) the XOSL Faq's, as they contain a number of key informations: http://www2.arnes.si/~fkomar/xosl.org/faqhow/faq.html jaclaz

Start a new thread, you are likely in a situation similar to this one: http://www.msfn.org/board/topic/145574-seagate-750gb-one-partition-is-raw-after-bsy-fix/ and there is the need to fix/recreate the MBR partition table or however attempt to recover the data from it, though it is as well possible that there is an underlying physical issue as in here: http://www.msfn.org/board/topic/170881-seagate-720011-malediction/ that cannot be fixed DIY. (in any case the drive is NOT anymore "bricked" and it does NOT anymore belong to this thread). jaclaz

Sure we can tell you , though it won't really help you since most probably you don't know which one is the Tx and which one is the Rx on the DKU-5 cable, and even if you know, you have anyway a 50% probability of having them wrong, as the marking of Tx and Rx can be interpreted (and may have been applied) in both ways . However the suggested guide is this one: http://www.msfn.org/board/topic/133387-debricking-the-seagate-drives/ (that does contain a correct picture with the ID of the terminals) Get the attached PDF, as the original guide page is now defunct. BTW the same guide is ALSO attached to FGA topic: http://www.msfn.org/board/topic/147532-fga-for-the-seagate-720011-drives/ and the trick is always, if it doesn't work, to try reverting the Tx and Rx. jaclaz

If you want to make a partition image, yes, you select the partition as source: otherwise, if you want to make the whole disk image you select the device physical as you just did and DMDE will provide you with the full size of the disk in the relevant fields, and that would be in your case: If you check, (try accessing the physical device) you will see how the actual partition starts on your disk at sector 2048+the 8 Gb unused/unallocated, possibly around sector 16779264. jaclaz

In DMDE? Tools->Copy sectors Choose as source device and choose the "right" physical drive. Start 0 End 0 Sectors 1 as destination choose file and save on the new disk volume. jaclaz

Yep , that's the idea. I personally prefer to make "whole disk" images, but making a partition image is also fine in this case . Make anyway a separate backup of the MBR. As long as you have enough space on the target volume, there is no need to move the existing files to another hard disk (or just move enough files to have enough space for the image), a good idea could be however to make sure that the destination volume filesystem is thoroughly defragmented, this way the image will be made contiguous or at least as contiguous as possible, something that while not really *needed* may speed up operations IF file carving is needed on the image. What I am not really sure to advise you on is whether to attempt recovery from the original device or from the image, IF the cause of the issue is *something* connected to a failure of the actual "original" hard disk, fiddling on it might not be such a good idea , all in all I would rather see what happens during the imaging process and if the "original" hard disk behaves, I would attempt the recovery on it, keeping the image as a "safety" backup, after all if the imaging is successful, should the original disk be proved to be failing you would have anyway the option to restore the untouched image to a new disk. jaclaz

Well, to "zap" huge numbers of sector addresses/file allocation tables/MFT records is actually almost instantaneous. I doubt that the issue was caused by Opera (by itself) or even by the Windows 7 filesystem driver , what you report is "queer", Opera (or any other browser for that matters) simply has not the kind of "direct" access that would explain what happened. Running chkdsk /f might have NOT been a smart move in this case (but it is well possible that it did not change anything). It is difficult to provide some advice unless we understand the cause of this event. and what were the "low level" effects on the filesystem. I would try checking in DMDE the (I am assuming NTFS) cluster map, depending on how much the filesystem was fragmented (the more it was fragmented, the worse) it may be possible to understand if there are chances to recover the files that UndeletePlus marks as "overwritten" (if the issue after all is related to cross-linked clusters or something connected to them). As always, BEFORE anything else, making a whole disk image is strongly suggested. jaclaz

Strictly speaking there is no actual *need* to use delayed expansion. I would write it like this: @ECHO OFFSETLOCAL ENABLEEXTENSIONSFOR /F "tokens=1 delims=;" %%A in (paths.txt) DO CALL :get_drive %%AECHO ENDGOTO :EOF:get_driveSET drive=%~d1SET driveletter=%drive:~0,1%IF DEFINED drive ECHO Drive found %driveletter%: in path %1GOTO :EOFPlease note how there is a need (no matter if using a subroutine like in the above or using delayed expansion inside the FOR loop) to make sure that the path/filename is valid, because the ~d will expand to "current drive" for non-existing files (without the leading "<driveletter>:") As an example, depending on the context, an additional test like: FOR /F "tokens=1 delims=;" %%A in (paths.txt) DO IF EXIST %%A CALL :get_drive %%A may be advised. Example paths.txt: Please note the potential issue with the last item, compare with: http://www.msfn.org/board/topic/137714-install-xp-from-a-ram-loaded-iso-image/?p=895361 the ~d expansion will produce, just like IF EXIST, a "No disk" error. Another approach would be direct parsing of the string. Something *like*: @ECHO OFFSETLOCAL ENABLEEXTENSIONSFOR /F "tokens=1 delims=\" %%A in (paths.txt) DO CALL :get_drive %%~AECHO ENDGOTO :EOF:get_driveSET drive=%1IF %drive:~1,1%==: SET driveletter=%drive:~0,1%IF DEFINED driveletter ECHO Drive found %driveletter%:SET driveletter=GOTO :EOFmight all in all be more suited. jaclaz

See also here, maybe something useful in it: http://www.msfn.org/board/topic/170986-emails-vanished-from-outlook-express/ jaclaz

Maybe "stupid" suggestion, but wouldn't it be possible to use a batch to quickly (regedit through a .reg or reg.exe) reduce the SpecialPollInterval value: http://www.wikihow.com/Change-the-Time-Synchronization-Interval-in-Windows-7 issue a w32tm.exe /resync and then change back to a "more decent" value the SpecialPollInterval ? (additionally stopping/starting the service if required) jaclaz

Well, make a dd copy (or "forensic sound" copy) of the whole device, then see if the previous volume structure can be found in the image. If the partition on it was NTFS you have rather good chances, unfortunately much lower ones if it was FAT32. DMDE (which is free for personal use with some minor limitations) will be able to do both the image and analyze it: http://dmde.com/ if no volume can be found, then you can stil do some "carving", in this case Photorec is a suitable tool; http://www.cgsecurity.org/wiki/PhotoRec jaclaz

@Trip Queer To be picky, DVI does not exist. (as a connector) DVI-ADVI-DDVI-Iexist instead. Most graphic card output DVI-I, i.e. they output BOTH a Digital and an Analog signal. The Analog signal is actually a "plain" Vga one: http://pinoutsguide.com/VideoCables/dvi_to_vga_adapter_pinout.shtml I doubt that a DVI-I actually can output a signal which is not fully VGA compatible, are you saying that given a same PC (with DVI-I output) one VGA monitor would work and another one would not or that you have some computers on which the VGA monitor does not work (maybe they have not DVI-I output, and offer only Digital but not Analogic signals)? jaclaz

The best you can do (IMHO) is to find out which area of the disk is "bad" and make a partition table in such a way that the area is not used. This, depending greatly on the UNknown reason of the issue, might give to the rest of the disk some residual "life" (though it is well possible that the "bad" area will grow). You can try, with tools like mhdd or Victoria, or hdparm, to mark an area as bad or do an ATA secure erase, but it won't likely help much if the area is biggish, or, if you prefer, YMMGV (Your Mileage May Greatly Vary), here are some hints: http://www.msfn.org/board/topic/158576-need-to-mark-a-few-blocks-as-unusable/ jaclaz

What you have to understand is that ATX supplies (UNlike older AT models) is actually made of TWO power supplies . One (a very little one, and actually not a "separate item", but a part of the main circuit) is "always on" (and this is how you can have Wake On Lan or, on some BIOSes switching the computer on by keyboard key presses, which simply switch on the "large part" actually powering most of the circuits. The net card and some other parts of the PC are always powered, ready to "bring back to life" the PC. If you prefer, an ATX powered PC is NEVER "fully OFF" unless the power switch on the PSU is turned off. Having a "real" ON/OFF switch on the PSU is a "feature", useful if you want to really have it off, short of unplugging the cable. jaclaz

Maybe, or maybe not so excellent. Sure , and the net result of this "vast" testing is Wndows 8/8.1 and now 10. Yes, it is a sad world , poor masses willing to test and provide feedback, but prevented from doing so by the evil plans of the developer ..... . jaclaz

http://en.wikipedia.org/wiki/Twist_tie jaclaz

Well, I guess it depends on local habits, we're much less formal here and I never actually needed one : jaclaz

Not at all "stupid", but showing that you haven't thoroughly studied the threads/tools you gave as reference (nor - as you should have - at least all the stickies in this subforum http://www.msfn.org/board/forum/157-install-windows-from-usb/ ) In a nutshell: the path to the "install" files is HARDCODED in SETUPLDR.BIN this hardcoded path is \I386 on CD/DVD like media this hardcoded path is \minint on hd-like mediaThus you NEED to hexedit the SETUPLDR.BIN BUT you have maximum 4 chars on CD/DVD and 6 on hd-like devices. With all due respect, there are now MANY documented ways to install XP from USB, in MANY different ways, including fully automated ones, there is NOT one reason in the world to "invent" yet a different one, and you should think a bit on the reasons WHY Wimb, ilko_t, cdob, yours truly and quite a few other people went to a great length of effort to develop these methods. Don't you think that IF it was as simple as : it would have been by now, already found out and documented? Of course you are very welcome to invent yet another method, but you should AT LEAST get familiar with current "state of art" AND test extensively the documented methods BEFORE thinking about yet another method (and assuming that it can be as simple as you described ). jaclaz P.S:: as a side note, one could abuse of other path/file renaming, but it seems like not worth the effort: http://www.msfn.org/board/topic/131103-win-ntbt-can-be-omitted/

Filename? jaclaz

That "sounds" like an issue of some kind in the "file association" part of the Registry. Maybe useful to test/check: http://wstudios.home.xs4all.nl/Associate/index.html?url=wassociate.html jaclaz

But (at the risk of going seriously OT ) would it be affordable for the people or can it be evaluated (in terms of time/money) properly? JFYI: http://www.cato.org/publications/policy-analysis/responsible-counterterrorism-policy http://object.cato.org/sites/cato.org/files/pubs/pdf/pa755.pdf jaclaz

It deserves a brand new Pulp-O-mizer Cover : jaclaz

This made my day jaclaz

Hmmm. http://www.videolan.org/vlc/index.html http://lifehacker.com/5877208/what-are-codec-packs-and-should-i-use-them In other words (AFAIK) VLC comes with it's own "internal" codecs that won't in any way interfere with "other player's" codecs. jaclaz