jaclaz

Well, if you have the tools and ability to open a laptop (without cracking it ) and more than that re-assembling it after having cleaned it , you definitely can replace a thermal pad. If you never applied a piece of double-side adhesive tape anywhere , then you might need to take a course on it . It is not entirely unlike what you would do with a gasket when you disassemble an engine, even if it seems fine, while you are at it you replace it anyway, but if you are disassembling the engine beacause you found out some water or oil is leaking, you definitely change it. A laptop GPU or CPU thermal pad should cost something like 1 or 2 bucks, while disassembling and reassembling a laptop is likely to take more than one hour, and after having replaced it/them you will be at least sure that you did the most that could be done. jaclaz

@JorgeA In other words, it is *something* that makes everyone able to do *dangerous* things through an additional click of the mouse. @MagicAndre1981 I am pretty sure you have it right , but you should tell this to the good MS guys: http://technet.microsoft.com/en-us/library/cc709691(v=ws.10).aspx and: At least they call it a "security component" and say that it's adoption should help protect the OS from "malicious software". jaclaz

Hmmm. The whole point is that if the hardware overheats, performance will be degraded as most modern hardware uses temperature sensors to "throttle down" the CPU (or GPU or both) in order to attempt to build not too much heat. If this happens on your machine, no matter how "lean" is the OS, as soon as a given temp is reached, everything will slow down, often down to a crawl. jaclaz

Which is fine. I claim I don't understand UAC (and I am not particularly interested in understanding it ). The only thing I know about it, is that it gets in the way every three things I do on a computer (usually someone else's computer that went beserk for *whatever* reasons, through "plain" use with UAC fully enabled and that I am attempting to fix). No doubts that UAC may be seen from a technical viewpoint as the third best thing in life after ice cream and sliced bread, still it seemingly does not provide the protection against OS corruption that it promises in common practice. And yes, I already know the counter reply "well, if the OS had not UAC enabled it would have been corrupted earlier", and it is exactly the point on which my practical (limited) experience casts some doubts. Given that I have the same - more or less totally inept at computers - friends, I haven't seen in last ten years any decrease in desperate requests" for "Help, my PC doesn't work" and certainly I could not observe any decreasing corresponding to adoption of UAC enabled OS's. Of course this means nothing really, only reporting my personal experience. jaclaz

My guess is that the "hard drive led" is actually an "activity on SATA bus led", and if this is the case there is no way you can change it's behaviour. As well if you set in the BIOS SATA/AHCI, that setting affects the way the controller is detected by the booting OS and it's "global" for all devices connected to the SATA bus, so last sidenote seems to me like perfectly "normal". The "booting issue" sounds strange, it seems like the booting OS "interrogates" the device and cannot have the reply it expects. Is the behaviour the same with?: a CF card inserted (wiped, i.e. all 00's) a CF card partitioned/formatted (i.e. with first sector a MBR) a CF card only formatted (i.e. as "superfloppy" with first sector a PBR)Can you make a boot log with the CF card (i.e. "hanging") and one without the CF card (i.e. booting normally)? Additionally, can you try tracing the boot with xbootmgr/xperf? http://helpdeskgeek.com/how-to/speed-up-boot-time-in-windows-vista/ I believe you need the WAIK or the SDK to get the tools. jaclaz

A 2.80 Ghz Celeron with 1 Gb RAM is a more than decent hardware for XP. I have had (and still have) similar machines and they run fine. No matter whether you like it or not, if you want to solve the overheating you need to open up the laptop. Besides thoroughly cleaning it, generally speaking the heat sinks - particularly of the GPU - use a "thermal pad" (as opposed to heat transfer paste) and these thermal pads tend over time to "dry up" and lose part of their heat transmission properties and simply need to be replaced. If - when the disk was replaced - the recovery partition was preserved, I would try imaging the disk "as is" and the do a recovery (you will find yourself with a machine that has a lot of HP bloatware BUT that is "as from factory"). With that see how it behaves (of course NOT connected to the Internet as it won't likely have any antivirus/protection). Then I would see if installing a "lited" XP (at least wthout the HP bloat) would make a difference. jaclaz

The pins are the same for most Seagate models, that is NOT the issue. The parameters of the serial transmission may be different depending on model. There is NO evidence whatsoever that your USB/TTL adapter is of the "suitable kind". The fact that it works in a loopback doesn't mean that it doesn't use the "wrong" TTL levels. PLEASE, STOP posting on this UNRELATED to your issue thread and start a NEW THREAD if you want assistance with your issue (which is NOT related to a 7200.11 and DOES NOT belong to this thread). jaclaz

Well, if it is different from a 7200.11: the 7200.11 "fix" will NOT likely work this thread which is for 7200.11 ONLY is not the right place to ask questions about a non-7200.11To this you add two a few changes from the "known" paths/methods, the use of MacOSX, the use of Minicom (whatever it is), an unspeciified USB/TTL adapter and clearly you are not using the Windows Terminal. Verify it is a 7200.11 with model ending in AS. If it is not one, start a new thread about your issue, after having checked for other existing threads (there is one about the 7200.12 and one about the ES.2 or NS version of the 7200.11) but YMMGV, there is a concrete risk that you might trying to apply either the "wrong" cure to the "right" disease or the "right" cure to the "wrong" disease. Double check with point #1 of the read-me-first: http://www.msfn.org/board/topic/143880-seagate-barracuda-720011-read-me-first/ jaclaz

I wish I could say "it could have been worse", but I would be telling a lie. More images on the (german) source: http://www.computerbase.de/2014-09/windows-9-technical-preview-bilder-testversion/ http://winfuture.de/news,83577.html IF the background image (that looks a lot like one of those prank images to simulate a broken LCD screen) is going to be the default one and an example of the "new design" I confirm how humanity is doomed. The "Microsoft Confidential" notice: must have been put on it by the lawyers fearing being sued as an innocent kid may remain shocked by viewing it and it would not be uncommon that elderly people with a previous heart condition would get a final stroke when seeing it. jaclaz

Which is substantially the same situation as user lemontea3313's, he donated but can't use the program (because due to the Hong Kong missing ZIP code he cannot retrieve the key). You donated and you have the key, but the program does not work as expected. So you are either also hijacking the thread or the thread was not hijacked. Try uninstalling aeroglass, reboot and reinstalling it. Report what happens. jaclaz

Re-reading your quote of my post I noticed I miswrote "sectors" for "fields" , corrected in the original post. jaclaz

No. But, if I get it right, it will never detect anything. The isolinux.bin before 2.12 has ALL fields set to "EFBEADDE" BUT it cannot be used without the mkisofs -boot-info-table switch that will fix with the right values into first (only used) 4 fields with the right data AND fill all the other fields with 00's. The isolinux.bin 2.12 and later will have the first 4 fields pre-set and all the other ones set to "EFBEADDE" (i.e. it will work with or without the mkisofs switch, and the only difference will be whether the other unused fields will "EFBEADDE" or "00000000"). If you are checking for "EFBEADDE" in the first 4 sectors fields, you will never find a bootable .iso based on isolinux with those values. Keeping the "hardcoded check" routine handy may be of use in the future, but right now the option is (sorry, my bad ) not useful. jaclaz

True ! At that stage that is all I test yes. I could look into a stricter test (I'm not promising and it may be next week before I find time for that). No hurry and no worry. I re-checked the older Isolinux versions and (unwantingly of course) I brought you on a "wrong" path. Earlier versions of Isolinux NEED the -boot-info-table switch in mkisofs to be actually bootable. The pre-embedded valid boot info table in later Isolinux has seemingly been implemented to avoid the need for the -boot-info-table switch. In other words (apart the "source" isolinux.bin in the original tool archive) it seemingly cannot exist "In nature" a bootable Isolinux based CD without correct bootinfotable data (no matter of course if that is the pre-embedded or the mkisofs calculated/patched one), in practice a .iso made with Isolinux before 2.12 with mkisofs without the -boot-info-table switch won' t be bootable. As such, now that the bootinfotable checksum verifying is corrected, there is no need for the "EFBEADDE" check, as any "real world" .iso based on Isolinux is correctly identified by the size and checksum in the bootinfotable. I hate it when it turns out that I am more royalist than the king ! jaclaz

I honestly do not know what you mean... could you please elaborate? I mean, you are not actually "veryfying" or "double checking" that the first 512 bytes of a sector represents a MBR or a PBR. Seemingly you just check that at offset 510 there are Magic Bytes 55AA and from this you assume that the sector is a MBR or a PBR. In the example grldr based image (the one with the boot info table filled), if I hexedit the offset 510 of second sector (i.e. offset 2048+510=2558) of the grldr file in the .iso (and correct the checksum in the boot info table), Isobuster does not "create" or "detect" the two extents. This is of course (and as said) a very minor issue. Very, very nice. jaclaz

Only to confirm that another user had the same issue, see here: http://www.msfn.org/board/topic/172655-strange-or-odd-multi-or-single-boot-cddvd-el-torito-images/page-2#entry1085470 http://www.msfn.org/board/topic/172655-strange-or-odd-multi-or-single-boot-cddvd-el-torito-images/?p=1085474 so it is not the specific ignoreJorgeA=true setting in the configuration file. jaclaz

I see. And yes , this might be set as an additional option, as if the boot image is very large (the Acronis) this read will slow down operations (let alone the case of defective media ) . Still - IMHO - in the case of the "divided in two extents" image, the size of "first extent" is evidently either of (please bear with me) "LBA start until PBR of second extent is found" OR "Info in the boot catalog (2048 bytes)" while size of the second extent is "Size in boot info table - size of first extent". If this size of 2nd extent is not matching with any "recognized size" in the MBR or PBR "leading" the second extent, this second extent is an "artifact" in the sense that it doesn't compare with a "righteously identified because a MBR or PBR valid structure was recognized" one). Not an issue of course , but still .... jaclaz

@monroe Facts: 1) witnesses for loud boom (and possibly for burning smell) 2) no witnesses (yet) for flash of light in the sky 3) crater 4) no traces of meteorite found 5) seismic trace of event recorded Opinions: 1) "experts" quoted about meteorite "vaporized" 2) "astronomer" quoted attributing the meteorite to fragment of 2014RC 3) "seismologist" quoted saying that the seismic trace is compatible to an impact 4) "other experts" not convinced http://en.wikipedia.org/wiki/Duck_test Maybe if it sounds like a bomb and smells like a bomb, it could be a bomb? @dencorso I don't know. The 90 degrees simply don't sound "right", and I am not convinced about the speed. Wouldn't a falling meteorite have a rather acute angle (something like 20° or less)? Wouldn't *anything* falling through atmosphere tend to "stabilize" at a given "terminal velocity"? http://en.wikipedia.org/wiki/Terminal_velocity (or is the initial speed so high that it hits ground before being slowed down?) In any case: 50*60*60=180,000 km/h 180,000/1,225= Mach 146 ! that sounds like 5 times "re-entry speed" http://en.wikipedia.org/wiki/Hypersonic_speed What you can be rather sure is that "loose sand" weights much more than 1000 kg/mc, depending on mineral composition, anything between 1600 and 2200 kg/m3 would be more accurate. jaclaz

Yep, it seems to me like everything is fine . The provided test GRLDR based image (the one WITHOUT boot-info-table) show as a 2048 bytes bootsector but if one chooses "use other filesystem to guess the files' size" it is parsed/recognized correctly. With the provided test GRLDR based image (the one WITH boot-info-table) the boot image shows as a "composed image", with a "first extent" of 2048 bytes and a "second extent" for the rest 268339 bytes[1]. In other words *somehow* choosing the "guess" overrides the detection of the two extents, providing an actually "more accurate" result than the "proper" parsing of the boot info table. Maybe an added column with - say - a "c" if the size has been determined by contents of the boot catalog, a "t" if the size has been determined by contents of boot info table and with a "g" (added once the "use other filesystem to guess the files' size" has been run and it determined a different size from "first look") may expose more clearly the data. I still have to try creating test .iso's with the old isolinux versions, will do and report. jaclaz [1] not that it matters, as long as the data is valid, but how is this extent size calculated?

Hmmm... tricky question... Check the chart for possible connections : but the volatility of this price is preoccupying in itself : http://supertart.com/priceofteainchina/index.php last time I checked, it was all the way up to 69.27 gerbils, which IMHO is really A LOT! jaclaz

Sure , but - by the same token - can also be recreated, so I wouldn't be surprised is several specimens would "re-appear" for sale. Try using the very convenient Computing Crater Size from Projectile Diameter online calculator : http://www.lpl.arizona.edu/tekton/crater_c.html jaclaz

Or if by appropriate use of "magic" the meteorite disappeared (and is going to re-materialize itself soon as an item for sale on e-bay ) jaclaz

Yep. I will test the new-new beta. GRLDR is a "very" flexible file. It can be used as: no-emulation bootsector on CDas "full featured" loader (invoked by the bootsector code of a volume instead of NTLDR or BOOTMGR)chainloaded by BOTH NTLDR (from BOOT.INI) and BOOTMGR (from either \boot\BCD or BOOT.INI)chainloaded by it's own MBR (+hidden sectors) file the GRLDR.MBR (which is actually a "subset" of the whole GRLDR)and can be used for many, many "tricks", and in order to do that it needs some common filesystem PBR's. A current GRLDR has : on sector 2 a FAT32 bootsector (with 00ed size) on sector 3, a FAT12/16 bootsector (with 1.44 floppy size) on sector 4 code that may be detected as a bootsector (possibly for EXT2/3 ) on sector 5 a NTFS bootsector (with 00ed size)so that is very easy that the one or the other is recognized as the beginning of a "valid" image. I did not see this variant yet but have it implemented. Test if you can as I can not see if it works ? However, based on the xls you sent, the length will be a block too much for v1.60 ? Yep. That is an issue. Though the number of .iso's created with versions 1.60-1.64 (in version 1.65 the isolinux.bin is already 8552 bytes) will be so low to be of no practical relevance, the (optional) "advanced" scan may be needed to see if any file/structure is allocated on the LBA n+4, and if it is, lower the guessed size from 5 to 4. But (i will have to test a couple of .iso's), even if the isolinux.bin occupied area "overlaps" the "next" file/structure, if it extracted as 5 sectors and re-burned it should work alright, the only side issue would be that the recreated .iso is one sector larger/with contents shifted by one sector. The alternative would be scanning the first sector for the "ISOLINUX x.yz" string, but I understand how that is not very "elegant". jaclaz

Now, now, you haven't been doing your homework on Microsoft Lingo. The term "to fix a bug" is deprecated and replaced by either "to update obsolete [*] feature" or "to better user experience" or "further increase the rock solid stability of the OS". jaclaz [*] obsolete may mean "one month old"

You see how strange is life? If you pay - say - 20 bucks to nuhi (please read as Robin Hood ) for a tool removing the crap, you are happy and you also thank him. If you pay the same twenty bucks to MS (please read as the evil Sheriff of Nottingham) for something where the crap has been (hopefully) already removed, you are angry, as it sounds like a ransom of some kind (actually it is a friggin' ransom ). In a perfect world they would give a free upgrade to all 8/8.1/8.1u1 users AND present a letter of apologies for the inconveniences caused .... jaclaz

If I get this right you use this method (more or less): http://www.bltt.org/accessibility/win98/win98display_appearance.htm but the results are not "sticky" through reboots? Are you saving your settings as "Scheme", but at next reboot the "default scheme" is changed back to the original/previous ? http://support.microsoft.com/kb/196001/en-us Just in case: ftp://ftp.pcmag.com/archives/2001/0801/ jaclaz