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

Very good. The new beta works fine. The GRLDR issue (please find attached two "demo" .iso) is now also much clearer. Whilst the good Syslinux guys have decided (as seen since version 2.12) to pre-embed the size and the checksum (and write EFBEADDE as "filler"), the good grub4dos guys leave the whole set of bytes set to 00's. The net effect is that IF the .iso is made with mkisofs AND the -boot-info-table option was chosen, Isobuster has no troubles with it. Otherwise the size is still found as 2048 bytes since the bootinfotable in the first sector is all 00's. Given the complexity of the options of mkisofs I would guess that the amount of GRLDR based .iso's around made with the "-boot-info-table" represent maybe 0.01% of the total number of GRLDR based .iso's. And I plead guilty, too , for having built numberless of such .iso's without the switch: http://reboot.pro/topic/9696-oscdimg-and-grub4dos/?p=84348 I may ask tinybit/chenall (current grub4dos maintainers ) if they would consider to pre-populate the size and checksum in the bootinfotable in future versions of GRLDR (unless there is any size effect since GRLDR doubles as hard disk MBR + hidden sectors loaders). In any case, the "do a scan for listed file starting on same sector as the bootimage.img" option would be useful in Isobuster for past and current builds (and may cover a number of "other non 2048 bytes sectors"). To "cover" the ISOLINUX's iso's created WITHOUT the -boot-info-table switch with ISOLINUX's BEFORE 2.12, what happens if we find the first two sets of EFBEADDE and approximate (by excess) the size to 5 CD sectors or 10240 bytes? jaclaz testgrldrisos.zip

The bad news are that evidently yes *somehow* your checksum and the one that is "embedded" in Isolinux seemingly do not match. The good news are that - though it would be of course much better to understand the reason of the mismatch and solve it properly - to identify an Isolinux (at least any actually used version) there is not really-really a need to use the checksum. Check the attached file (Excel format .xls, let me know if you have issues with this). There is definitely a "pattern" . About the GRLDR image, the snippet I posted was with an old version of parted magic. Without opening a discussion on the choice of the Author that converted the package from Free to Commercial and deleted from servers all previous versions Of course previous versions are redistributable, so if you want to work on the same one I can upload it to somewhere, but more easilu (give me some time) I will make a small empty .iso making use of GRLDR and will attach it. jaclaz Isolinux_versions.zip

Not really-really, but I am quite good at sounding like I was an actual expert. The actual asm checking routine is this one: But there is another one calculating the checksum of bytes 64-2048, I'll see what I can do, but from this to "translate" it into an algorithm that you can re-implement, it is possibly a largish "leap" , I actually hoped you were expert in asm. However, fist thing I will see if among the various tools I have around I can find a pre-made one that can recreate it. The "option to scan" remains valid, since besides the specific ISOLINUX solution (once it will be "coded properly") which will however cover - say - 87.23% of Linux originated images) it would come useful for other loaders (like the grub4dos GRLDR example I posted). jaclaz

Not really-really, but almost. It's like going on a road trip and suddenly realizing that you took a wrong turn somewhere and have spent the last two hours driving in the wrong direction, and then having to turn around and make it up, after your wife that is sitting besides you and the kids that are in the backseats have been telling you that over and over since exactly two hours. To the shame of having chosen the wrong turn you have to add to it the awareness that, besides having done something stupid, you are also dangerously stubborn, and you have NO excuses as you were actually told you were going in the wrong direction. jaclaz

You may want to change the entry to: Simple, effective. jaclaz

In the meantime I checked a bit around. It seems like there is a "hardcoded" size in ISOLINUX.BIN. I checked the isolinux.asm of version 3.82, here is a snippet: So, the data is actually there. If mkisofs and the -boot-info-table are used the data are written by it, but if not the size is however already hardcoded in the field. And the corresponding binary dump still for 3.82 version where isolinux.bin is 14336 bytes, hence 0x3800 has it nicely set at offset 0x10: I have quickly checked a very early version (2.00) and that boot info table is not there, however . I'll do a few more checks, versions 4.07 and 5.10 also have the size explicited in that field to find if earlier versions have the data *somewhere* else. To make sure that the field is there and is correct, I guess it would be possible to re-calculate the checksum of the file and compare it with the next field, though I still have to see/understand how the checksum is calculated. jaclaz

As said I have no "foolproof" solutions, the one I use in the batch is only suitable for the case where ISOLINUX.BIN (or other file) is listed in the filesystem, but at least works for a number of ISOLINUX (and non-ISOLINUX) based images. What I simply do in bextract.cmd (have you had a look at it? it is all in all a 6 kb batch file, and though it uses a few external programs it doesn't really bite - unless provoked ) http://reboot.pro/topic/12406-editing-iso-files/ http://reboot.pro/topic/12406-editing-iso-files/?p=108486 It parses the output of isoinfo -d, this is the output for the slitaz3.0 file: getting the bolded red info. If the disk is bootable (88) and if it is No emulation (0) it gets the 33. Then it parses the output of isoinfo -l -i, here is a snippet: looking for any file starting on sector 33 and then uses the 14336 as size of the no-emulation loader image to be extracted and then extracts it: Additionally (if there is one) it attempts to extract the commands used in mkisofs to create the image, saving them in a file in a folder named <name_of_the_iso_boot>, in this case of slitaz3.0.iso there is not such info, but, as an example if you try the batch on an image like pmagic4.0.iso, you get: The "hidden" is only connected to the fact that isoinfo -x cannot extract "hidden" files (though isoinfo -l does list them) hence I resolved to do the extraction using a "direct access" tool, the dsfo from the DSFOK packkage. About the time needed to scan the filesystem(s), maybe you could add a "right click" option when you select the "Bootimage.img" shown as 2,048 bytes in size (and have this option ONLY when the size is 2,048 bytes ) to the effect of "Verify size by scanning the volume" (or something along the same lines, this way the scanning becomes "optional" and is performed by user decision). I see , which however brings us back on how it would be nice to distinguish at first sight (colour was suggested, but bolding would be also a good enough option) between "real names" (the ones you get from the bootcatalog.cat) and the "fake" names (like the generic "bootimage.img"). Or maybe I completely missed it in the docs , the current behaviour is that if there is a set name in the boot catalog that name is displayed with appended the ".img", whilst if the entry is blank, the "generic" BootImage.img is shown, right? You will have to agree that (when it works ) my directory searching approach is a bit more "user friendly". jaclaz

Well, the good news are that the release date of Windows 7 SP2 TE (Touch Enabled) - which seemingly would be a more fitting name for the Windows 9 beta - is as vague as the release date of nuhi's unnamed tool http://www.theverge.com/2014/8/21/6052807/windows-9-preview-press-event-september jaclaz

Well, you are seemingly not aware of recent EU discussions (but not only EU) about the "Right to be forgotten": http://en.wikipedia.org/wiki/Right_to_be_forgotten It is a "delicate" topic, with no actual (as I see it) "right" solution possible. jaclaz