jaclaz

Most probably yes, but it's difficult to say. Unless I am mistaken, you have posted "Side B" of the burned PCB and "Side A" of the "replacement one". Since my crystal ball is again in the shop for tuning , I have to use I-CHING, that tell me: The weak element is above, the strong below; hence their powers attract each other, in your case the weak element is the PCB and the strong one is the HD, the general meaning is that you are doomed to success, but the road to reach it will not be easy. jaclaz

You are welcome. As you can see from my previous post, it is not that XOSL is in any way "not as stable as grub4dos". XOSL simply relies on bootsectors. grub4dos can, besides relying on them, BYPASS them. In other words, grub4dos can use BOTH (example): title WinPE on (hd0,7) BOOTMGR hide (hd0,0) hide (hd0,1) hide (hd0,2) hide (hd0,4) hide (hd0,5) hide (hd0,6) root (hd0,7) chainloader /bootmgr And: title WinPE on (hd0,7) bootsector hide (hd0,0) hide (hd0,1) hide (hd0,2) hide (hd0,4) hide (hd0,5) hide (hd0,6) root (hd0,7) chainloader +1 The latter (unless you correct the sectors before) won't work exactly as XOSL won't, the first simply ignores the BPB of the bootsector and directly loads the Systemfile. jaclaz

It would be interesting to know how you would make a logical volume inside extended Active.... Quick sum up: the Active flag is used by "standard" MBR code to choose WHICH partition among the 4 (four) entries in the MBR Partition Table to boot from a logical volume inside extended it is NOT in one of the entries in the MBR partition table you need a kind of bootmanager to chainload the bootsector of a logical volume inside extended the "standard" code in the bootsector or PBR won't normally work unless you fix the "sectors before" parameter in the BPB of the bootsector (see already given link) the alternative is bypassing the bootsector and directly chainloading the system file (grub4dos can do this) Normal boot sequence: BIOS->MBR->PBR or bootsector of Active Primary partition->Systemfile invoked by bootsector (IO.SYS or NTLDR or BOOTMGR, etc.) Boot sequence with most bootmanagers: BIOS->MBR->Bootmanager->PBR or bootsector of ANY partition->(FAIL if BPB is wrong)->Systemfile invoked by bootsector Possible bootsequence with grub4dos (I think newish syslinux/isolinux can do the same): BIOS->MBR->grub4dos->Systemfile on ANY partition jaclaz

Ok, found the problem with devcon.exe. You need to change this: ;---------------------------------------------------------------- ; Manufacturer + Product Section (Done) ;---------------------------------------------------------------- [Manufacturer] %Provider% = tap08qemu [tap08qemu] %DeviceDescription% = tap08qemu.ndi, tap08qemu to this: [Manufacturer] %Provider% = tap08qemu [Models] ; Note 1. Replace the bogus *NM_OFDRIVER "hw-id" with a real hardware PnP ID ; Note 2. Optionally, add more NIC models supported by this file ; ; DisplayName Section hw-id ; ----------- ------- ------ ;%DeviceDescription%=*yourdriver.ndi, *NM_OFDRIVER [tap08qemu] %DeviceDescription% = tap08qemu.ndi, *QEMU_TAP then devcon.exe install oemwin2k.inf *QEMU_TAP works for me (don't ask which is the trick, as I don't know). Just got tapinstall.exe from OpenVPN, which I think it is not redistributable as well (but check it's status - I am not at all sure of this ). And I can confirm that: tapinstall.exe install oemwin2k.inf *QEMU_TAP works allright with the modified .inf. I'll see if I can find anythng else. jaclaz P.S.: Found an interesting link: http://forum.installsite.net/index.php?showtopic=15898 it seems like the most "plain" way is to create a DIFX package using DPINST, which is redistributable.

No. The devcon.exe doesn't work for me (XP SP2). C:\Downloaded\tapdriver\TAPDriver\i386>devcon.exe install oemwin2k.inf t ap08qemu.sys Device node created. Install is complete when drivers are updated... Updating drivers for tap08qemu.sys from C:\Downloaded\tapdriver\TAPDriver\i386\oemwin2k.inf. devcon.exe failed. It starts installing but then fails, it seems like there is the need for some other files beside the .sys, or maybe it doesn't "connect" properly to the virtual device. In the .inf there are additional files "REMmed out" by using ; . Among the Remmed ones there is the "right" way (supposedly) to install this service, which is running tapinstall.exe, which seems like being a file coming with OpenVPN, which should be an equivalent to devcon.exe. here is a partial output of devcon listclass NET with bolded the devices installed in various attempts. Something possibly very easy to fix must have been overlooked or it is missing. jaclaz

No, but the method should work. Please post how you succeed to install it with devcon.exe, and I'll try to make a "working" .inf for it. (I need to understand how it behaves when succesfully installed) jaclaz

There is already a rather known project called Qemu Manager, if I may, you should change slightly the name of your project to avoid confusion. Hey, wait, the link is on daveryn.co.uk, which is the home of the Qemu Manager! So you're Dave! Welcome to MSFN, happy to meet you. Back to your problem. Cannot you use a .inf file? The linked file has one. I am not an expert at all in using them, but if I managed to put together an install of a service: http://www.boot-land.net/forums/index.php?showtopic=9765 you can do it as well. Basically: RunDll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 <your_driver>.inf and you need a DefaultInstall section in the actual <your_driver>.inf Just post if you need further help, if you better explain what the driver is for, I can try modifying the .inf and test it. jaclaz

Just for the record, there is a way to "embed" a diskpart.txt file inside a batch, here: http://www.msfn.org/board/index.php?showtopic=126069&st=16 http://www.msfn.org/board/index.php?showtopic=126069&st=19 jaclaz

Actually there is NO difference in the .lst files at a binary level. I guess that we can put the blame on (choose one) of the things that may have had an hiccup: nlite magiciso you WinsetupfromUSB Actualy I would exclude #4 (and I presume ilko_t would do the same) , and you'll probably want to exclude number #3 , then, since it seems like in this particular case MagicISO appears "innocent" , considered that nuhi is not often around here anymore, I would say it was a nlite hiccup, and live happily forever.... jaclaz

That's what I use my custom made sticks for (besides using them to NOT touch Vista ) http://www.msfn.org/board/index.php?showtopic=125258&st=12 And the "real" trick is to first dive under the table and THEN hit the button. jaclaz

It may be completely irrelevant in this case, but as a general advice, NEVER fiddle with ISO manipulating utilities. The error in "REVR" seem to me like either "timing" problems or "file in use" problems, (the initial error on a .chm file sees to me unprobable being caused by an antivirus) but you never know. How was the .ISO built? Are "they" two different .iso's or the same used twice? Is it/them a physical media (CD/DVD) or a .iso mounted to a Virtual CD driver? jaclaz

To be fair, it's about PE 2.0, then it should be VISTA related. jaclaz

...and don't forget.... jaclaz

Well, of course the freedos bootsector has different CODE from the WIN PE one, so it is well possible that the problem of the wrong "sectors before" doesn't affect the one, but does affect the other. I don't see what you have to lose in trying corrrecting the "sectors before" in the PBR. If it works, you have solved your problem, if it doesn't it's something else, and we can find an alternate solution (already hinted - grub4dos). JFYI, if there is a problem in the BCD, you woulld get a BOOTMGR error (BSOD), not XOSL re-loading or whatever. jaclaz

Now, now, comeon , to de-solder and re-solder a SMD you don't need to be an open heart surgeon , nor to be Certified by anybody, you need some specific tools and a little experience. Actually CrazyDoctor appears to miss both latter requisites right now, but let us not put him too down... You forget TWO possible reasons : FUN the satisfaction of being able to do what all other told it was impossible jaclaz

Tihiy managed to remove the embedded logo and config manager: http://www.msfn.org/board/index.php?showtopic=45103 but no details on how it was done. And I seem to remember something about decompressing IO.SYS on some cChinese DOS board, but don't think that any detail on HOW to do it were posted. There is also this snippet in the readme for grub4dos: But again no method explained. jaclaz

Well, with all due respect , if it 's NOT a multi-boot CD/DVD and is NOT Unattended, this is hardly the "right" place: MSFN Forums> Unattended Windows Discussion & Support> Multi-Boot CD/DVDs If I get it right and the problem/question is "how can I boot from a logical partition?", the answer is here: http://www.goodells.net/multiboot/index.htm http://www.goodells.net/multiboot/ptedit.htm If the question, on the other hand is "What would be the easiest method to boot a setup like this?", most probably the answer is "using grub4dos instead of XOSL2, as grub4dos can directly chainload the loaders bypassing bootsectors and needs not a dedicated partition". jaclaz

I guess that if windows can start booting at it, it should not be that bad. It surely has some bad sectors, possibly unrecoverable, but it seems to me like it is mostly functional, or at least it is to try and recover the DATA before starting fiddling with it. jaclaz

The matter is really confusing. Let's try not to confuse further ideas, let's assume that there is no such thing as 5V TTL, but rather that there is: TTL/CMOS which is 5V TTL which is 3.3V http://www.interfacebus.com/voltage_threshold.html The fact that the chip used is a MAX232 doesn't necessarily imply that the output will be at TTL/CMOS levels, see here for a series of examples: http://www.panuworld.net/nuukiaworld/hardware/cables/basics.htm http://www.panuworld.net/nuukiaworld/hardware/cables/old.htm http://www.panuworld.net/nuukiaworld/hardware/cables/fbus.htm The Nokia cables use TTL 3.3v, and NOT 5V. This is how I understand the issue (not necessarily right ). Case #1: Disk using TTL Adapter using TTL Everything "speaks" the same language, and everything is OK. Case #2: Disk using TTL/CMOS Adapter using TTL/CMOS Everything "speaks" the same language, and everything is OK. Case #3: Disk using TTL/CMOS Adapter using TTL If the drive is working with TTL/CMOS levels, it will understand anyway the 3.3v signals sent to it's receiver through the 3.3v TTL adapter TX line, and will send back to the adapter a 5V one, that the adapter's receiver may: "flatten" to 3.3V max and understand get it at 5V and don't understand it Case #4: Disk using TTL Adapter using TTL/CMOS If the drive is working with TTL levels, when the TTL/CMOS sends a 5V signal, hard disk's receiver may: "flatten" to 3.3V max and understand get it at 5V and don't understand it The hard disk's transmitter will send a 3.3V signal that the TTL adapter will understand anyway. Case #5: As often happens with "standards", they are mainly b***sh** and noone actually respects them so a given adaprter works with the hard disk and another one doesn't, and noone knows until he actually tries it. Without knowing the specifications for the Seagate disk, we are in this situation: TTL interfaces (3.3V) will work ALWAYS if they can "flatten" the hypothetical higher level signal from the hard disk TTL/CMOS interfaces may or may not work Anyone is free to choose an adapter and trying it, of course. If ANYWHERE (meaning either on the hard disk side or on the adapter's side) there are the two pulling down 2.7v or 3v zener diodes (or some other "peak pulling down" circuit): http://www.msfn.org/board/index.php?showtopic=128807&st=2645 anything will do, as anything between hard disk and adapter will be within TTL levels. The number of people that (after having been very lucky and found the "right" Nokia cable or bought a bunch of them before finding the right one) had success with the Nokia cable make me think that we are in case #1 (or in #5 ), though it is very possible that those that had problems with the original "auto-switching" adapter simply had "something else" going wrong, but I find it unprobable that a "good" adapter as the one originally used has this kind of problems: http://www.sparkfun.com/commerce/product_info.php?products_id=449 Please note how the terms appear reversed from what the reference shows: http://www.interfacebus.com/voltage_threshold.html from other sources, it seems to me like this latter is accurate and the peeps at sparkfun completely missed the point. However, the mistery remains...., the good news are that there shouldn't be any harm done if the hard disk gets a "full" 5V signal level, so, at the most it won't work, but there should be no risk in trying it. jaclaz

Please don't tell me you tried it on a friday in a month which name contains the letter "r" That's obviously a no-no. jaclaz

Now you know: http://www.msfn.org/board/index.php?showtopic=128807&st=2338 The point is that, even if the interface "understands" TTL/CMOS (which I doubt), a 3.3V will work anyway, whilst a 4.8V will be understood as a "suffusion of yellow". I don't think anyone has actually documented the EXACT signals level the HD actually "understands", though. jaclaz

DO not DOUBLE POST, please http://www.msfn.org/board/topic/18408-forum-rules-updated-must-read/ Replied on your other thread: jaclaz

Look, let's separate questions and answers. This is a trick question: What may be good for 3.11 may NOT be good for Win95 or for 98SE, also, what may be good for one scope may not be for another one. In my experience Win98 in Virtualbox is not that bad, when properly configured : http://www.virtualbox.org/wiki/User_FAQ http://forums.virtualbox.org/viewtopic.php?t=9072 If you are going for 3.11, nothing can beat Qemu in usability and size of VM. For Win95 it is debatable, and it's not so straightforward to install 95 on VPC: http://blogs.msdn.com/virtual_pc_guy/archive/2005/02/15/372846.aspx Most probably an "old" VPC 2004 would work better that VPC 2007, and an even older Connectix version still better (with the older OS). There is again as I see it a definite advantage in using RAW disk images in any VM, the new .vhd (the fixed size, NOT the "dynamic" one) is anyway very handy, as it is simply a RAW image with a sector added to it's end, as thus it can be used/mounted/whatever by most "normal" RAW image tools. There are so many settings (and so many drivers) that it is out of the scope of a thread like this to discuss how to setup a VM for ANY of those Operating Systems. I guess that starting a new thread for each of them would be advisable, and however there are quite a number of threads already on the board, one out of many: http://www.msfn.org/board/index.php?showtopic=140233 jaclaz

NO, there is some white text on the blue screen, which is an ERROR CODE that you should post in order for anyone to be able to help you. Most probably you are trying to install XP on a PC with SATA drives and your install lacks the proper drivers, and the error message is 0x0000007b "unaccessible boot device", but without some indformation and details, it's an educated but still wild guess. Some "general" advice on how to ask for help on a technical board: http://homepages.tesco.net/J.deBoynePollard/FGA/problem-report-standard-litany.html Besides the BSOD code, post some info on the hardware, and on the OS (SP?), which media are you using to install from, etc., etc. jaclaz

This is what I posted, yes: If the question is "will the PCB swap work", the answer is "noone can say". Define "cheaper", and add to your evaluation "fast", "accurate", then we'll talk about the matter. As I see it, that price is an awful lot of money for that hard disk, but you should actually kneel down and kiss the ground where the seller has walked , as very few people sell hard disks on e-bay giving such a number of details. You are payng not so much the HD but the time of the guy to make a proper ad, compare with buying a lot of undescribed HD's for a few bucks to find that they are not the right one or taking several days of correspondence with the seller to make sure it is actually the right PCB. What these guys do is to buy lots of HD's then catalog each one properly. You can do the same, you may save some dollars, but if you are dealing with data recovery, time is one of the key factors. Following are another few chaps that sells PCB's: http://www.ioffer.com/selling/hddsolutions http://stores.ebay.com/Softcom http://stores.ebay.com/Hard-Drive-Parts-Specialist http://stores.ebay.com/A-Better-Way-Computer-Recycling (just first four results of a search - no intention whatsoever to promote any of them with which I never had any contact) Hint : search on e-bay for "PCB Western Digital" (without quotes) jaclaz