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

Sure . The bad news (for the aliens) being that Nuhi's negotiator uses the same strategy Bruce Willis used in the Fifth Element jaclaz

Though of course they could remove this kind of information from google search results , which are "widely used", I believe , but yes, the issue with Pandora's box (actually jar) is that you cannot put back the evils in it and reseal it. jaclaz

@Isobuster Very good. Still, the original "issue" that is about ISOLINUX.BIN based CD/DVD's where the ISOLINUX.BIN is "hidden", remains: Files on which bextract.cmd works fine (but latest posted Isobuster does not ): http://reboot.pro/topic/12406-editing-iso-files/ http://mirror.slitaz.org/iso/3.0/slitaz-3.0.iso http://mirror.slitaz.org/iso/4.0/slitaz-4.0.iso As I see it there are two ways to solve these issues (both IMHO not entirely "proper") search in the 2,048 bytes that are listed in the boot catalog for the ISOLINUX string and/or the syslinux.com one (or other "pattern recognizer) and then find the ISOLINUX:BIN in the other filesystems structures (or find the file that starts on the same LBA as the boot image, as it may have been renamed) and use that size instead <- this would "cover" only part of the images, but should be OK for the vast majority of the "pure" ISOLINUX based ones, no matter the tool with which the .iso were made check if there is any "hole" in the LBA addressing starting from the LBA of the image in boot catalog and derive from this "hole" the real size of the image <- this would be somehow "risky" and would provide in nay case results rounded to 2,048 bytes, which may be "wrong"Or, do *something like* the above checks and then show a window/message to the effect of: It is just my opinion of course , but I would personally prefer the software telling me that it has doubts about something or that it is not 100% sure of something better that having it seeming to work 100% but providing at the end a "wrong" image (or image extents). About the 2OS images, there must have been a "glitch in the matrix" (on my side ) when extracting, I retested and everything is fine now (re:size ), still I would like to understand why (unlike other similarly based ISOLINUX.BIN images) the boot image is "recognized" as "Magic ISO Boot Record.img" The kav_rescue_10.iso and AcronisAntimalwareScanCD.iso are also OK , no EFI images in them AFAICT, I must have had inadvertedly turned off the "mkiso patch setting" . jaclaz

I guess it would be very difficult to do this splitting without "losing too much" in the one or the other thread. It is better IMHO to leave this as is, and start from scratch on the new one, people interested in the details/making of up to the current status will surely be able to get here as I posted a reference to this one on the new thread. jaclaz

Sure . Done! Here: http://www.msfn.org/board/topic/172655-strange-or-odd-multi-or-single-boot-cddvd-el-torito-images/ I hope that the place I made it in: http://www.msfn.org/board/forum/82-multi-boot-cddvds/ is appropriate (but a Mod can always move the whole thread to somewhere else). jaclaz

In a topic that was originally intended to be specific to Linux based and specific to a known Software firm boot CD's, here for the record: http://www.msfn.org/board/topic/172610-acronis-iso-boot-on-uefi-pc/ it came out how there are (still) some "not entirely standard" or not "entirely documented" ways to make bootable CD's by using (or abusing) the No-Emulation provisions of the El-Torito standards. Additional the relatively recent introduction of EFI bootable CD/DVD's gives reasons to attempt revising the way these CD/DVD's are made and how to interpret their contents. A known tool to inspect the contents of a .iso in the Windows world is Isobuster: http://www.isobuster.com/ a tool that is partially freeware (with limited functionality), with a Commercial license for the "full set" of available functions/features. Taking advantage of my familiarity with Isobuster's Author on another forum, I invited him to discuss here issues/features/changes/ideas/whatever about his tool when looking at these .iso's, he gladly accepted, and now there is this brand new thread to hopefully discuss the matter peacefully. Quick recap: traditionally it was believed (by me at least) that El-Torito no-emulation images were reserved to "special" loaders, such as:the known "ArnesBootRecord" or MicrosoftCorporation.img (sized 2,048 bytes and used in Windows NT based OS install disks and PE 1.x's)the known etfsboot.com (sized 2,048 bytes and used in Vista install disks and PE 2.x's)the known etfsboot.com (sized 4,096 bytes and used in 7 and later Windwos OS and in PE's >2.x)ISOLINUX.BIN (part of the Syslinux project, typically between 10 and 14 Kb in size)GRLDR (part of the grub4dos project, typically around 250 Kb, but of which only the first 4 sectors, i.e. 2,048 byes are actually the "boot image"other "special crafted" bootloaders still in the few Kbytes range in sizeit is possible to have El-Torito No-emulation images that are either a whole (large) volume (hundreds of Mbytes in size) or a volume (still large) with prepended to it a loaderin passing by the extension to the El-Torito standard adding to it the "EF" type of boot image (which is normally represented as a very small FAT formatted volume containing just the \efi\boot\ folder and an efi executable, such as bootia32.efi, bootia64.efi or bootx64.efi) has been talked aboutit also came out that this "EF" no-emulation boot image can be a rather largish FAT formatted volumethe El-Torito standard does not include anywhere in boot catalog a field for the SIZE of such images (though it includes a field for "Size to be initially loaded")The discussion provided some ideas to make clearer the structure of these .iso's, and allow the user to have valid data about the size of these images and the possibility to "extract" them "correctly", i.e. in a way that these images can be re-used to create other images and or be mounted/accessed with other commonly uised tools. Isobuster (the nick with which the Author of the Isobuster tool has registered on MSFN) already made a series of changes to the tool and we are in the phase of experimenting the modified tool on several different .iso's to see how efficient and useful are these changes and/or to propose new, further changes (where needed), etc. jaclaz

What is the part that you didn't understand in: ? I will try again as: (if possible) never, NEVER, NEVER (meaning actually NEVER) use a Windows based flashing tool and ALWAYS ONLY use a DOS based one, when booted in a "clean" (no autoexec.bat, no config.sys, NOTHING loaded but pure DOS) MS-DOS or FreeDOS. jaclaz

"Normal" SATA, i.e. simply "SATA". The "inside" of the connector is a little less that 34 mm: and the "two notches" are on the sides of the space in the middle. If you are going to put a (heavy) 3.5" disk in that case, you NEED (IMHO) to find a way to fix it "safely", consider the idea of putting "spacers" between the disk and the case (without completely preventing air flow around it of course) jaclaz

You see the good thing of the UK ? If the issue was on your side of the pond, you would have likely had a much higher frequency 60 Hz buzz instead . jaclaz

Bingo , you cannot post the same question over and over. Earlier today you posted some 8 or 9 times this same question (most probably due to a connection or board issue), under two different thread titles, but now you have already an answer by ilko_t, try following this thread. Answer ilko_t's questions, DO NOT start new threads about the same issue, please. jaclaz

Anyway, maybe you don't really-really need to fork from several hundred bucks for buying the mentioned in the article (which is obviously some form of not-so-hidden advertisement/plug) "special" phones, JFYI: https://secupwn.github.io/Android-IMSI-Catcher-Detector/ (though this will only tell you if you are at risk of being intercepted by an IMSI catcher) jaclaz

Well, of course they *need* (like I do) to add all those u's that you insist on removing from common words, but it is actually a very little overhead, while replacing -ize with -ise does not of course later the length of messages, and when your English friends sends messages to you, the message would be actually shortened on-the-fly. Those are "revocation letter" items #1 and #2 in it's most widely reknown version: http://www.snopes.com/politics/soapbox/revocation.asp jaclaz

Don't forget to include among the possibilities: A bum Skype installation at your end. The intervention of any of the three or-more-letters US or UK Government agencies. A man-in-the middle kind of attack/sniffing/whatever by hacking groups steganographing LOLCAT images in your astronomical photos in order to avoid custom fees. .Seriously, it seems like a very "strange" and "preoccupying" (given the amount of files exchanged globally through SkyPe) issue. Which format are the images? I mean it is not that the service is attempting to decompress (for virus scanning or *whatever* reasons) the contents (or a local antivirus or something similar)? Is this behaviour "bidirectional" (i.e. it happens BOTH if you send or receive the image) AND it happens ONLY with this other user? jaclaz

@isobuster JFYI: Files on which bextract.cmd works fine (and latest posted Isobuster does not): Kav rescue disk 10 http://rescuedisk.kaspersky-labs.com/rescuedisk/updatable/kav_rescue_10.iso has seemingly a "eltorito.img" on sector 228 sized 25225 bytes Acronis Antimalware CD https://kb.acronis.com/content/18647 has ISOLUX.BIN on sector 228 92 11691 bytes Files on which bextract.cmd DOES NOT work (and Isobuister also *somehow* fails): 2OS 3.16 http://sourceforge.net/projects/meos/ http://sourceforge.net/projects/meos/files/binarys/3.16/ (isobuster gets it seemingly "wrong" in size as 2 Kb, AND it recognizes it as MagicIso bootsector, though it is seemingly an ISOLINUX) 2OS 8.10 http://sourceforge.net/projects/meos/ http://sourceforge.net/projects/meos/files/binarys/8.10/ (isobuster gets it seemingly "right" in size, 14 Kb, AND it recognizes it as MagicIso bootsector, AND it is seemingly a modified ISOLINUX, BUT isobuster extracts only the first 12 Kb) jaclaz

Sure Harkaz's contributions are noteworthy, interesting and useful :, the comment was only about the non-news nature of those "news" for MSFN members. I would add - as a side note - that part of the (unfortunate) decline of Windows XP may be due (besides the scare-mongering tactics by MS and friends) to "physiologic" reasons. I mean, a large part of the XP installed base is most probably "OEM" and "pre-installed" on "portables" (laptop and notebooks) manufactured before 2009 (the "year of 7") and those kind of devices tend to age (due to shock, wear and what not) faster than desktops and they rarely are as repairable or as upgradable as desktops. jaclaz

Unless of course a secret court, presided by an anonymous judge, issued a secret order authorizing another (not the FBI) three-or-more-letters government agency to place them. We must be scared of this new generation of hackers with unlimited funding that can place fake cell towers across the U.S.A. Snippets from the article: no further comment needed. jaclaz

... or use any of the other way to workaround it ... jaclaz

List of products including Calibri (from the mouth of the wolf): http://www.microsoft.com/typography/fonts/font.aspx?FMID=1710 What they don't say is that the font is included in some free products, such as PowerPoint Viewer 2007: http://www.microsoft.com/en-US/download/details.aspx?id=6 with a few strings attached: jaclaz

Very good. : Though latest version does not work (for me) on the "reference" Slitaz : http://mirror.slitaz.org/iso/3.0/slitaz-3.0.iso I still see the "Bootimage.img" on LBA 33 sized 2.00 kb (and in the accessible part of the .iso the \BOOT\ISOLINIUX.BIN at 14.00 kb) I'll check a few other .iso's I have around and see if I can find "unexpected" behaviours and report. Idea's : Not to beat a dead horse , but maybe you could distinguish a "real" name like "Acronis" (which text string is in the boot catalog) from a "fake" name (the friendly name you use to give access to the disc extent) by making the latter red in colour? (relevance of this near to 0, of course, just a way to distinguish actual contents of the .iso from "artifacts") As above, but if possible an added column with the ID of the image (00/01/02/EF for 80x86(BIOS)/PowerPC/Mac/UEFI) would be nice. Maybe you could add a setting - a sort of minimal "database" or .ini file - where one could add to a given "name" found in the boot catalog an offset to the bootsector, something like "Acronis=12", when another "queer" image is found one could add an entry to this list, maybe adding a "check" for -say- first few bytes of the loader, like "Acronis=12=EA5E7D000030" to cover more cases?jaclaz

Oww, comeon , why do you think I used coefficient k with 1<k<4 and adopted for it in the calculation just the average 2? I can still use values up to 3.999 for it , I hope that would be enough to "cover your back" jaclaz

Are you joking? Or you wanted to post it under "news"? The source of that article is: http://www.ryanvm.net/forum/viewtopic.php?t=10321&postdays=0&postorder=asc&start=0 And guess which board harkaz is also a member of? http://www.msfn.org/board/topic/171171-introducing-unofficial-windows-xp-sp4/ jaclaz

Nice . Though I hope you are going to eat some lasagne (plural) as one lasagna (singular) provides not enough calories . Don't worry too much about Babylon 5 representing "being behind", you are not the only one still liking and watching it. But I guess you'll need to wait tomorrow for the feedback as I am also going soon to have dinner (or at least I hope so). jaclaz