jaclaz

Yep , as said the issue is WHEN this will happen. BTW, decompilation rights are in some cases ("fair use") given even while the Copyright is in effect. http://en.wikipedia.org/wiki/Decompiler#Legality jaclaz

The 82845G (internal) is among the tested cards for VBEMP: http://bearwindows.boot-land.net/vbe9x.htm You may need to update BIOS or use a TSR, though: jaclaz

Well, if it is PCIe it may be nonetheless accessible by grub4dos (i.e. the BIOS may map it even if it does not allow it in the list of boot devices). It would still be a "mixed mode boot", but better than nothing.... An old attempt (UNfinalized ) here: http://www.911cd.net/forums//index.php?showtopic=20314 jaclaz

At least in the US, a computer program is considered "literary work": http://en.wikipedia.org/wiki/Software_copyright I also presume that specifically it falls in the category of “work made for hire” AND "corporate ownership". Thus it should fall in the category: http://inventors.about.com/od/copyrights/a/expiration.htm First published Windows98 should be 25 June 1998. IF the quoted data is correct, that would mean 1998+95-2011=82 years, better than 87, but still...... jaclaz

HOW is the SD card reader connected (which BUS)? PLoP may be able to boot from it if it is on the USB bus (it would be a "mixed mode" boot, though) jaclaz

Doesn't this require Microsoft to release the source code? Or has it ever been leaked? No. "Public Domain" does not mean that it becomes "Open Source" (and of course DO NOT EVEN THINK of using leaked source , if any ). After a given number of years since publication has elapsed or in some cases after a given number of years since the death of the Author, intellectual property is not anymore protected by Law: http://en.wikipedia.org/wiki/Public_domain I have NO idea where the cited 87 years come from. Cited from here: http://programmers.stackexchange.com/questions/72914/will-a-copyrighted-code-get-into-public-domain-once-its-copyright-expires jaclaz

The 2K drivers are FASTER than new ones, but this applies to FAT32, not to NTFS (and I presume that your 15 Gb archive resides on NTFS): So it must be something else, I doubt that recent hardware (say last 3 years, even laptops) have USB 1.0 speed, if that laptop came with Windows 7 it must be a recent one.... jaclaz

I wonder WHERE you got that file. You want this one CALLED UBCD511.ISO: http://www.ultimatebootcd.com/download.html The page lists a number of mirrors, a few ones: http://ubcd.mirror.fusa.be/ubcd511.iso http://ftp.gr.vim.org/mirrors/linux/ubcd/ubcd511.iso http://pharry.org/data/ubcd511.iso And yes, if you don't have a suitable program, get IMGBURN: http://www.imgburn.com/ http://www.imgburn.com/index.php?act=download You want to get a file that is called SetupImgBurn_2.5.6.0.exe jaclaz

There is a recent thread (not Win9x) related: where you may get anyway some info. Have you considered the idea of running with NO page file? How much RAM is actually used by the system in "normal" operation? Which "kind" (i.e. in which occasion) are "temp" files created? How big in size they can be? 196 Mb on a Windows 98 machine should be enough to run setting aside a small RAM disk for "temp".... jaclaz

New kid on the block: http://code.kliu.org/cmdopen/ Quite a bunch of other nifty tools on the site (under "misc") jaclaz

If you could run some "diagnostics" and post some actual info on the chip used, the actual drivers that do work in Win9x, more generally technical specs of the notebook, etc. someone may be able to help you. jaclaz

Hmmm, either I am very late, or you are a bit early for Christmas.... . Nice circular referrence you made jaclaz

That has NOTHING to do with TTL levels. That part is about the Voltage regulator that is included in the chip and is abiut Vcc ("power") and NOT "signal". Since you removed the board, and also used the "cardboard", check thoroughfully contacts between HD and PCB: jaclaz

A good idea could be to use the UBCD: http://www.ultimatebootcd.com/ as it contains, besides several other tools, Partition Magic which is a nice small Linux distro that includes TESTDISK and PHOTOREC. jaclaz

Comeon, don't take this too seriously . Things like this happen every other day, I don't think there is any malice in the OP "general warning", some peeps tend to trust this kind of apps more than they are worth or - if you prefer are a little over-sensitive to these false alarms/overcautious, just as examples : http://www.911cd.net/forums//index.php?showtopic=23931&st=361 I think it is part of the game (being suspected of hiding heaven only knows which malicious code within a freeware app), nothing to become upset for. Continue the good work... jaclaz

Very good you have more than enough available space. First thing you should do is to create a "forensic sound" or "dd-like" or "sector by sector" image of the probelmatic disk. To do this you will need EITHER an "alternate" way to boot the "old" PC (like a boot CD or USB stick or make the Freeagent GoFlex drive bootable -this latter may take some time) if the CD drive is operational and you have another PC with a CD recorder (and a writable CD ) the boot CD is probably the easiest of the options OR a way to connect the "old" hard disk to a fully functions PC (like an USB external enclosure or - better - another desktop to which you can attache the "old" hard disk as "slave". The above step (doing an image of the hard disk is STRONGLY suggested and may be - depending on the situation of the "old" disk - "absolutely necessary". Then the "recommended" attempt is to do a filesystem recovery, IF it works, you will have the contents of your "old" disk exactly or nearly exactly as they were. Alternative is to attempt a files based recovery, you will likely get your files with a simpler procedure but they will likely be "mixed together" in a single folder and surely they will be all renamed to a (meanigless) name, i.e. if you have a file that was (say) C:\MyPhotos\Holidays\Spain2008\alhambra.jpg, it may turn out as (say) E:\Recovered\0003456.jpg Up to you the choice of which path you want to take, this may depend also on the time you have available for this, your level of familiarity with tools/OSes, etc. Here you can find a few examples of past recoveries, just to have a "general" idea of the possible complexity of the steps you have before you (filesystem recovery): For file based recovery there are tools (namely PHOTOREC) that are easier to use: after a few unsuccessful attempts with filesystem recovery, file based one was used: page__st__28 jaclaz

While your google gets fixed , here : jaclaz

Basically you are stuck (IF the idea is to recover the filesystem) with a probability of 30 to 80 % . IF you are looking to recover files (namely photos/Images) AND IF the disk is detected in BIOS AND IF the disk had been defragged recently (before the filesystem issues began to show) THEN you have good probabilities, nearing 90% or more to recover them as files. How big is the failed/failing hard disk? How big is the new USB disk? How much free space you have on it? What you need is enough free space on a disk to contain TWICE the whole size of the "failing disk" (or two disks each one with enough space to hold the full contents of the old disk). Doing *anything* without this requirement fulfilled FIRST is STRONGLY NOT advised. Please start a new thread in the appropriate area: http://www.msfn.org/board/forum/169-hard-drive-and-removable-media-issues/ and detail as much as you can the hardware you have available and what you remember of how the disk was partitioned, if it was recently defragged, etc. etc. Please take note that no matter the (completely fake ) probabilities of failure of success, IF a filesystem recovery is possible the result will be essentially the files just as you had them before, whilst if this is not possible a file based recovery will - IF succesful - a number of "good" images BUT withouut their original names and paths. jaclaz

Where exactly? Mind you, I am not saying that the CP2102 does not support the "lower" TTL levels (I simply DO NOT know for sure that ) , only that I cannot find (and I doubt you were able to ) this particular spec on the provided datasheet. If you review the "readme first": (Point #6) you will find a link to here: http://www.interfacebus.com/voltage_threshold.html where the thing is graphically explained. We have an indirect report here: notable parts bolded for your convenience. IF this is the case, that adapter WILL NOT work to "talk" to the Seagate drive. See what was replied at the time: Based on just this partial info I would confirm what you have already been told: again bolded the relevant parts for your convenience. Since the Seagate circuit FOR SURE does not "like" 5V TTL/CMOS levels and operates at 3.3V TTL levels, IF the adapter you have is "3v3 tolerant" on the Rx line (which obviously ANY adapter would since the 0.8÷3.3v range is WITHIN BOTH TTL/CMOS and TTL specs per given linked page ) you may want to get something like this: http://www.sparkfun.com/products/8745 Or TRY mkaing a similar voltage divider with two small resistor on the adapter Tx line (HD Rx) to lower it's peaks (you will need a 10K and a 20K resistor Of course the above may or may not work, and you would have an easier life by just getting an appropriate adapter..... Can you "talk" to that other HD with the same USB/TTL adapter? If NO, it will be a confirmation that there is some problem with that particular adapter (again cannot say if with the "model" or the actual "specimen" you have ) Yep , you see, if the PCB is not powered it cannot - obviously - "boot" the "miniOS" which is it's "firmware", when unpowered it may either "short" the terminals or leave them open, but it is pointless to try to "talk" to an unpowered device anyway. jaclaz

WHICH "download file"? The XP_INST_v04.7z? Here: jaclaz

If I may, saying "latest version" of Opera may mean *something* today, but won't on one week/one month time. (and same applies to KernelEx) Latest at the time of this post should be 11.52 Latest version of KernelEx should be 4.5.2 jaclaz

"not initialized" (I presume from disk management of XP/2003/Vista or 7, etc.) simply means that the MBR has NOT at offset 510 the "magic bytes" 55AA. This could be due to several reasons and may either be easy fixable or unrecoverable. Please describe with as much detail as you can: the OS you are running. which hardware PC model/etc. if you have available another disk, possibly in a USB or e-sata enclosure of the same size or bigger what happened (what could have caused the issue, your actions, when it happened, etc.) what was BEFORE on that disk (number of partitions, filesystems used, etc.) jaclaz

http://reboot.pro/4416/ jaclaz

Yes, there must be asubdirectory in the *recy* named folder for it to appear. The &hA AFAIK was good until 9x/Me and changed with XP, it was connected to the (whatever it was "BITBUCKET" or something like that. But still, just like the mentioned "::{645FF040-5081-101B-9F08-00AA002F954E}" it pointed to the "virtual folder". Conversely the approach pointed out by Coffefiend is "OS agnostic", or, if you prefer, in your approach you assumed that you boot to the OS and you want to look at the Recycle Bin of that OS. A procedure like: "bruteforcing" the names <-(Glenn9999) can be executed also from another booted OS (BUT it won't work if the Recycle Bin folder has been renamed *somehow* to a different name from the three known ones) finding *recy* <-(Gunsmokingman) can be executed also from another booted OS (BUT it won't work if the Recycle Bin folder has been renamed *somehow* to a different name from the three known ones AND it may provide "false positives) checking contents of the folder <-(jaclaz) will ONLY remove the possibility of "false positives") checking folder attribute <-(Coffefiend) will MAKE SURE that the folder is a Recycle Bin (used at least once by at least once of the OS ever booted on that machine) BUT won't cover the *somehow* renamed form the known three names I would think that the most comprehensive procedure could be "mixing" all these approaches: find all files called INFO2 (and "take note" of their parent folders) find all files called $I*, verify that in the same folder exists an identically named file but with $I replaced with $R (and "take note" of their parrent folders) process each of the found parent folders with the SHDESCRIPTIONID as per the "The Old New Thing" post, to verify that they are not a (rather sophisticated) "false positive" jaclaz

The math doesn't sound exactly right: http://www.allensmith.net/Storage/HDDlimit/98Fdisk.htm 156,301,488x512=80,026,361,856 80,026,361,856-68,719,476,736=11,306,885,120 11,306,885,120/1,024=11,041,880 11,041,880/1,024=10,783.0859375 Maybe the OP lied (or maybe was not ereally accurate in his report) In such a situation FDISK should have shown 10.783 Mbytes in size and "all" the others" *somethinge else*. But it could be . (I still wonder WHICH are the "all the others" ), but the bug is in FDISK only, and should not have affected the disk once partitioned in Win2K Setup, maybe it was a "combination" of things. jaclaz