jaclaz

And - specifically - given the (hopefully already past) known issues of WIndows 10 with multiple monitors and DPI scaling they made the wiser choice. jaclaz

But before that, are you sure that the dll actually needs to be registered? Windows errors can be sometimes misleading, maybe is some other file that creates the issue. Can you provide some context? There is a known issue related to that file in combination with some Java programs/updates, maybe you are having something similar: https://windowsexplored.com/2012/01/09/the-case-of-the-ie-hangs-and-missing-png-images-or-killing-two-birds-with-one-stone/ This may (or it may not) be the fix you need: https://forums.majorgeeks.com/threads/ie-will-not-display-png-images.150568/ jaclaz

No, it is not at all "unique" Binary (actually hex) is a representation of values. What is used is bytes, that can have values between 0 and 255 or - in hex - 00 to FF. Bytes can be grouped in words (2 bytes or 16 bit values), long words (4 bytes or 32 bit values), quad words (8 bytes or 64 bit values) when they represent a number. Otherwise they are taken as single bytes. A subset of bytes value, 0 to 127 (or 00 to 7F or 7-bit values) are used to represent most common letters, numbers and symbols (and non printable "control codes"), according to ASCII: http://www.asciitable.com/ and values 128 to 255 (or 80 to FF or 8-bit values) represent "extended ASCII" i.e. additional letters and symbols. Then there is Unicode that uses a two bytes encoding: http://www.unicodetables.com/ (but the first 128 characters are anyway the same as ASCII) In the Registry the "binary" type of data corresponds to *any* number of hex bytes. These hex bytes may represent text or numeric values or *something else*. Only text represented as bytes can be read/translated back to text. As an example, check your HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices You will find there ALL and ONLY Reg_Binary keys. If you click on some of them, you will see how some of them (those corresponding to USB sticks or more generally removable devices, i.e. those beginning with 5C 00 3F 00 or 5F 00 3F 00) will be long and "human readable" in the pop-up modify value window, whilst those corresponding to partitions/volumes on internal hard disks will be shorter and (unless by sheer coincidence) not readable. This is simply because the former are text strings (encoded in Unicode) whilst the latter represent different data, namely the first four bytes are the Disk Signature and the other 8 bytes are a Quad Word with the offset in sectors to the volume beginning (in practice last three or four bytes will almost always be 00). jaclaz

The OOBEtimer key contains binary values, nothing that you can ever trasform into a "comprehensible string", unless - by sheer luck - those values are in the ASCII range of printable characters AND they are readable. Have a look at the value in Regedit, example: I don't think that "ÿÕqÖ‹joÕ3“ý" means anything. jaclaz

The blinking cursor - generally speaking means that the stick has some issue in its partitioning/format (typically a mismatch between CHS and LBA but also a mismatch with the geometry of the device). Try booting the stick on another PC, if it boots there, the stick (and its partitioning/format) is fine and you need to find out what settings on your new firmwatre allow to boot from it, there may be other settings that are in conflict. Historically there are BIOSes that simply won't boot from this (or that) code (as an example Insyde BIOS had issues with several grub4dos and syslinux versions), but it is strange that this (recent) Intel one fails with Rufus. jaclaz

XP (or its setup) is NOT bootable on UEFI. You need to find the setting (if any) in your firmware to activate CSM (Compatibility Support Module) or "legacy boot" (in other words: BIOS). jaclaz

Sure , the point is that a Win 2K may look like a Win9x but it is very, very different from it as an Operating System. For no apparent reason, an image video (no need for translation and worth more than one thousand words ): jaclaz

I believe you mean "it looks almost like it". jaclaz

I don't know, it is "queer" in the sense that no actual reason/cause for the behaviour (which is also seemingly not-so-common, but also not-so-rare) has been found (AFAIK). jaclaz

Maybe OT, maybe not, on other news: https://www.zdnet.com/article/windows-7-bug-prevents-users-from-shutting-down-or-rebooting-computers/ jaclaz

LOOONG shot, but maybe this driver can do something about it (or maybe not) diskmod.sys: http://reboot.pro/topic/9461-page-file-in-usb-hard-disk/?p=86619 mind you it could also make your system unbootable, so, if you wish to test it, be very, very careful. jaclaz

Sure , and wait until you find one where something (like not allowing to enter a number in engineering format) is by design, example : https://web.archive.org/web/20090626230528/http://support.microsoft.com/kb/135673 the motive: would be not as stupid as it may seem at first sight if not for the fact that anyone (in his/her own mind) would use the numeric keypad (and not the top row) when entering numbers. Or - IMHO even better - when Remove All Does Not Remove Everything (by design) https://web.archive.org/web/20080217232953/http://support.microsoft.com/kb/147373 jaclaz

Mtools can make larger volumes just fine. Of course you need the "right" version of mtools and the right command options, you seem like having the "right" version: http://reboot.pro/files/file/267-mtools/ http://reboot.pro/topic/14354-buidlingmodifying-floppy-images-with-mtools-as-replacement-for-winimageimdisk/ If you take the example "-f 1440"and use instead "-f 67000" it won't work because the "1440" is a known format, whilst "67000" is not. You know like: Here you will find a small batch which can be useful to understand (and make more explicit) the parameters involved: http://reboot.pro/topic/21664-makeiso/page-4#entry205455 jaclaz

Well, it depends. Extended partitions are intrinsically "safer" from some risks (when compared to primaries), as an example a (malicious) tool with the same capabilities of MBRfix (and no more) won't find the actual bootsector of the logical volumes so - in theory - can do less damages. On the other hand since logical volumes are addressed through a "chain" of EPBR's, thet are intrinsically "weaker", if any link of the chain breaks (for whatever reasons) you will have corruption (perfectly recoverable, still ...) A good (and infamous) example is attempting to manage extended partitions from Vista or later in XP. the good MS guys not only created the mess when "switching formatting paradigm", but also mis- or under- documented the issue and of course never issued a proper XP patched set of programs, again JFYI: http://reboot.pro/topic/9897-vistawin7-versus-xp-partitioning-issue/ http://www.dcr.net/~w-clayton/Vista/DisappearingPartitions/DisappearingPartitions.htm And not only, they also removed the KB that mentioned the issue (via Wayback Machine): https://web.archive.org/web/20080821212615/http://support.microsoft.com/kb/931854/en-us By definition, out of the four partition entries, only one can be active at any time, and only if primary, so it is implicit that any primary partition but one will be non-active. The (IMHO only) good news with GPT partitioning are that in GPT ALL partitions are primary and you have in practice no limit in the number of volumes (most implementations are for up to 128 partitions/volumes). jaclaz

Extended partitions have NOT (and cannot have) "drive letters" (as they are NOT "drives" NOR "volumes") MBRwiz is a wizard for the MBR, nomen est omen, it only accesses the MBR where there is NO info whatsoever about the logical volume(s) (if any) inside the Extended partition, which is BTW what I tried explaining in the previous post. I does anyway look in the Windows Registry to find the drive letter (and the label) of the drive(s) - please read as volume(s) it finds (in the MBR) To give you one of my (in-)famous layman examples , imagine that you have for some reasons a security camera reading the registration plates of vehicles passing by: 1st recorded plate is a car, AA123456, you can look up for the registration number and find out (say) that it is a 1989 Corolla 2nd recorded plate is a car, AB234567, you can look up for the registration number and find out (say) that is a 2010 BMW series 3 3rd recorded plate is a car, AC3425678 you can look up for the registration number and find out (say) that it is 2018 Range Rover 4th recorded plate is a lorry, BC 89765432, you can look up for the registration number and find out (say) that it is a 2006 Scania truck, a car transporter Now, would you be surprised that you cannot find which cars (if any) the last vehicle is transporting? If you want to check the start offset of logical volumes also you need another tool, PartInfo will do: https://www.terabyteunlimited.com/kb/article.php?id=288 https://www.terabyteunlimited.com/downloads-free-software.htm (but in this tool you won't see the drive letters, not for primary parttitons, nor for logical volumes) jaclaz

You were not in class (or you were distracted) the day they explained Extended Partitions (and how they are different), did you? :w00t: In MBR style disks there are two kinds of partitions, primary and extended. In a MBR partition table there are 4 entries available. They can be filled with (up to) 4 primary partition entries or (up to) three primary partition entries and one (and one only) Extended partition. If you prefer, since there are no more than 4 possible entries in the MBR partition table, the concept of Extended partition was implemented to have more than 4 volumes. What gets a drive letter in Windows is the drive or volume. A partition (primary) is essentially a "container" (to be more correct an extent, i.e. a start address and a size starting from that) where a single volume resides, in practice a primary partition (to be more correct the extent addressed in the MBR) is exactly the same thing as the volume (technically if the volume is NTFS there is a single sector which is inside the partition but outside the volume, at the end, containing a second copy of first sector - bootsector - of the volume, but that is a detail ). In any case the first sector of a primary partition (i.e. the sector that you can find at the address "Start sector" in the MBR partition table entry) is also the first sector of the volume inside it, i.e. the volume (or drive) bootsector. A partition (Extended) is as well a "container" (again an extent) where one or more logical volumes reside. The specific partition ID Extended partition have (either 0x05 or 0x0F) means more or less (to the OS accessing it): Be aware that this is an outer container and you will have to parse other addressing data to find logical volumes inside it. Then how can the OS find these logical volumes? Here comes the "clever" trick, the first sector of an extended partition (i.e. the sector that you can find at the address "Start sector" in the MBR partition table entry) is NOT the first sector of any volume, nor a bootsector. It is instead a structure very similar to the MBR, sometimes called EPBR (Extended Partition Boot Record), it has (at the same relative address 446 or 0x1BE as the MBR) a partition table, but - unlike the partition table of the MBR - this one has only two entries (and not four) which are filled with this data: 1) The first entry is the "next" logical volume inside extended (i.e. in the first EPBR, the one pointed to in the MBR, the first entry is the first logical volume) 2) The second entry is the "next" (if any) EPBR and this EPBR will contain as first entry the "next" volume and as second entry the "next" EPBR (loop to #1 until all logical volumes are enumerated). MBRfix ONLY looks at the partition table in the MBR, so: the Start sector for Primary partitions (which is actually ALSO the Start sector of the volumes) is a good indicator of the alignment for the volume whilst the Start sector for the Extended partition is meaningless to determine the alignment of logical volumes inside it (they may be aligned or not aligned, and you wont know unless you either inspect the whole chain of EPBR's or you check the volume bootsectors). This said, 16065 - usually - is a sign of the partitoning having been made with the "old" paradigm as 255x63=16065, or if you prefer, a whole cylinder. IF the old paradigm was used, the first volume inside Extended should be (but needs to be verified) a further 63 sectors, so 16065+63=16128. Since 16128/8=2016 (with no rest), everything should be fine, the volume starts on a multiple of 8 sectors or 4096 bytes. BUT this is only valid if the volume is NTFS (because in NTFS *everything* is a file, including the bootsector, which is 16 sectors in size, and common sizes of NTFS volues have also 4096 bytes clusters so everything is automatically aligned if the beginning of the volume is aligned) and NOT for other filesystems like FAT12/16/32 where there are a number of reserved sectors and the FAT tables that may - or may not - be a multiple of 8 sectors in size, besides the cluster size which could be smaller than 4096 bytes: https://support.microsoft.com/en-us/help/140365/default-cluster-size-for-ntfs-fat-and-exfat See also here: And here: http://reboot.pro/topic/16775-discover-allocation-unit-and-other-information-of-ufd-under-windows/ http://reboot.pro/topic/16783-rmprepusb-faster-fat32-write-access-on-flash-memory-drives/ to better understand the matter. The disk where the offset to the Extended partition is 16321, IF the volume starts 63 sectors after, is OK as well (if the volume is NTFS) 16321+63=16384 and 16384/8=2048, but as well this needs to be checked. jaclaz

Check the "sectors before" in the bootsector or the start of the partition. In XP64 you should be able to use MBRWIZ (that has also a 64 bit version), you want the "legacy" version 2.0b: http://firesage.com/mbrwizard.php?x=6 as follows (open a command prompt window, navigate where the MBRWIZ is and issue) : mbrwiz /list you will obtain an output *like*: C:\mbrwiz>mbrwiz /list MBRWiz - Version 2.0 **beta** for Windows XP/2K3/PE April 30, 2006 Copyright (c) 2002-2006 Roger Layton http://mbr.bigr.net Disk: 0 Size: 140G CHS: 17861 255 63 Pos MBRndx Type/Name Size Active Hide Start Sector Sectors DL Vol Label --- ------ ---------- ---- ------ ---- ------------ ------------ -- ---------- 0 0 07-NTFS 140G Yes No 63 286,948,260 C: Disco You see the field "Start Sector" (which is 63 in the above example)? If it is 63 it uses the old, NOT SUITABLE for a SSD alignment, you need to re-create the partition correctly aligned to 1 MB. If it is 2048 it uses the new, OK for SSD alignment, you are good to go. jaclaz

Well, that is a pet peeve of mine, Trusted Installer is not as much a security concept as a limiting of freedom In the good ol'times of NT and 2000 "pro's" (which implied network, shared pc's etc, AND often an IT supervision) had a all in all "sound" security/access implementation, and the "normal users" (your home PC and laptop, probably never connected to a network) had a simplified model with 9x/Me, With XP, it was forced down the throat of common users a whole load of access/permisisions and what not that simply made no sense. With the (stupid) Vista and later there were not that many (or good) improvements (in the sense of actual increase in security in practice), as each and every (stupid) additional roadblock has been - before or later - worked around, the only effects were to make the life of users (and in some cases of developers a little more miserable). And if you would tell us which among the various proposed solutions/workarounds you used successffully that would maybe be useful to someone else with the same or similar issue. jaclaz

Any source for this rather bold (besides pessimistic) statement? jaclaz

It is not difficult. The "standard" has changed over the time. Up to XP (the change was with Vista, not 7) it was assumed that the geometry of mass storage device was 63 sectors (and 255 heads, but that is irrelevant) 512 bytes in size and even if long before XP disk access in NT systems was LBA based and not CHS based the old paradigm was to start and end partitions on a cylinder boundary. You don't need to know what CHS and LBA are, all you need to know that until Vista the partitioning software in NT base systems (Disk Manager and Diskpart) defaulted to: 1) start first partition at the offset of 63 sectors 2) have partitions end on multiples of 255*63=16065 sectors Well before SSD came out, it came out that in some cases having partions aligned to a multiple of 8 sectors (4096 bytes) provided some advantages in speed of disk access (the reason of that being essentially that the ubiquitous NTFS filesystem has normally a cluster sized 4096 bytes). So starting with Vista the so-called MB alignment was used: 1) start first partition on 2048 sectors (2048*512=1048576 bytes=1 MB = 256*4096) 2) have partitions end on multiples of 1 MB Of course the good MS guys never retro-fitted to XP tools the same "new" behaviour. By sheer coincidence (or luck or whatever, possibly even by design) SSD have an internal structure based on 4096 bytes "chunks" (that are only artificially divided into 512 bytes sectors) so this same new paradigm remained valid, as a matter of fact it became necessary, as unlike the (modest, if any) speed advantages on mechanical hard disks in 2006/2007 using the "old" paradigm on the new SSD's increases the number of needed writes (and consequently the wear). To visualize what happens, Imagine that you have a (crazy) work where you have a printer output 8 copies of each document and you have to separate the printed sheets into 8 piles, storing them in a cabinet. with several drawers, depending on the contents of the document printed, let's say keeping invoices separated from orders and separated from memos. Would you prefer your cabinet with 3 drawers, each large enough to hold side by side the 8 copies or (say) a cabinet with 5 drawers, each one large enough to store 5 copies? In the first case each time the printer outputs the 8 copies you only need to open 1 drawer, in the second case you need to open 2 drawers. Using the Windows 7 setup disk (there is not actually any need to fully install the 7) to partition the SSD is only one of the possible ways to create the partitions according to the "new" paradigm of 1 MB alignment, as IntMD said one could use Gparted or a number of other tools, including some that run just fine under XP. If you prefer, the important thing is to have the partition properly aligned on a SSD, the actual method tool you use to obtain that alignment is irrelevant, and the Windows seup disc is only one among the many ways to do that. jaclaz

So, all in all, it is a timing problem of sort, that the execution of another program accessing the file (or possibly the device [1]) solves. About CHS/LBA balancing all you need is here (shameless plug ) : http://reboot.pro/topic/2959-chs-lba-translations/ get the v2 version here: http://reboot.pro/topic/2959-chs-lba-translations/?p=74116 jaclaz [1] I mean, if on the same device (floppy-like) where the hdd-512mb.img.gz resides there is another file, let's say pleasels.me and upon boot, you run: ls (fd0)/pleasels,me and then you map the image what happens? Or - maybe - only: ls (fd0)/ would do.

They are other tools similar to the RunasTI by joakim I linked to earlier, the topic contains also some background/why/how the approach works: jaclaz

Naah, I only happen to know quite a few things on a very narrow set of data (like you know this or that set of 512 bytes). The CHS/LBA being not balanced is more or less as old as partitioning, the fact is that until a certain point *everything* was CHS based and after a certain point *almost anything* was LBA based, whenever both come into play, if they are not balanced/corresponding, it is likely that issues arise. Though this specific case is actually "queer", the difference between "absolute" or "relative" path should be not influencing the mounting, so the only possible explanation is (very much similar to your hint about timing) due to using the "find" (or "find --set-root") before mounting, it should mean that *somehow* finding the file allows for a different parsing mechanism, but it remains "queer". It is like there is a difference between "cold mounting" (i.e. mapping a file that has not been accessed before) and "hot mounting" (i,e. mapping a file that has been already accessed by some other grub4dos command, it is like grub4dos is "taken by surprise by the contents of the file" and tries to "invent" a suitable set of partition data (and failing at it). The origin is of course the unbalanced partition data (GIGO paradigm) still it is baffling. If you still have the "bad" image, can you try: root (fd0) ls /hdd-512mb.img.gz and ls (fd0)/hdd-512mb.img.gz before the mapping? (I mean instead of find or find --set-root) jaclaz

I am missing something, what are the differences in the commands you issue (between the ones that end up with a "bad" mapping and the ones that end up with a "good" mapping")? They seem to me exactly the same, at first sight this one: is a "hardcoded/absolute" path to the image, this one: is a "relative" path. Both are "wrong" (theorically/philosophically), what happens with the "right" one?: Or there are other differences that I missed? Anyway the MBR partition table of the two (bad vs. good) mapped drives is different, what is actually in the original image? If it is the one in the "good" mapped image, at least part of the issue is likely in the "unbalanced" CHS vs. LBA values. The geometry is clearly 32/63 (as it is confirmed in the bootsector BPB data) The data in CHS values is: Start: 0/1/1, that translates to 63, OK End: 520/31/63 that translates to 1050335 (521*32*63-1=1050335) from which you subtract the 63 and obtain the amount of sectors 1050335-63+1=1050273 sectors in the partition, 1050273 converts to 0x001006A1 BUT the MBR partition table LBA has 0x000FFEC1 instead that is decimal 1048257 So, THAT partition table entry is NOT balanced CHS vs. LBA, and as such it won't "behave" correctly in a number of cases. Then, as a matter of fact, the actual bootsector has in its BPB data 1048257 sectors. You should try starting with a CORRECT image. To correct the image, you need to change the end cyl in the partition table from 520 to 519, i.e . change the: 80010100061FBF083F000000C1FE0F00 to: 80010100061FBF073F000000C1FE0F00 Or you can get to where you have the image "badly" mapped and issue in grub4dos a partnew (hd0,0) 0x06 63 1048257 geometry (hd0) What happens to the partition table entry CHS values? jaclaz

Well, you can use extract (command line): https://www.winimage.com/extract.htm it should have the same capabilities (needs to be tried in this Qemu setup, though). jaclaz