jaclaz

Mind you I am re-building this justification from memory and from re-reading some ten years later the files, so don't count too much on the accuracy of the details, but the general idea should be correct. The idea is (was) that a number of BIOSes (or programs) want to have as first sector a MBR, while some other want to use a volume (i.e. first sector is a bootsector/VBR) The original makebootfat code/approach (only valid for FAT) is to prepend a sector to a normal volume, then: 1) have in this sector the MBR code and a partition table covering itself and the following volume 2) have in this sector a copy of the BPB of the original VBR but with an added "hidden sector" (or "sectors before +1") So, if you look at it with a MBR viewer, it should be valid, and as well if you look at it with a VBR viewer it should be valid. The code is (should be) code. Once executed, it would map the whole stuff, execute the MBR boot code and the PBR boot code sequentially. With NTFS, since we cannot prepend a sector to the $Boot (the 16 sector VBR for NTFS) I tried to have the same effect by simplifying the original MBR code to save space and putting it in holes of the VBR code, hence there is the need to load the same sector twice, the first time as MBR code, the second as VBR code, and this is the purpose of the 42 flag. What happens is (should be) that: 1) sector is loaded (by the BIOS) at 0:7C00h but moved to 0600h (this is in the original makebootfat) 2) a check for 42 at 0602 makes it continue using the MBR code or the VBR code 3) since initially the byte is NOT 42 it continues with MBR code (that sets the 0602h byte to 42) 5) the MBR code execution continues on the copy at 0600h 6) and the sector is loaded at 7C00H 7) the SAME code (since it is the SAME sector) is executed but this time the byte at 7C02h (copied from 0602h) is 42 so it continues with the VBR code

I don't know. The value 42 is written later at 0x0602: at first pass both 0602 and 7C02 should be NOT 42. at second pass BOTH should be 42. Anyway whichever works, works.

From the source code (scarce) comments I wrote at the time, the 42 is just a flag of sorts, it is used to tell the bootcode what to load, if you prefer a switch: And yes, the first part of the "dual-use" mbr/pbr (up to the FA31C0) must be filled wit the original BPB of the NTFS volume, while the "dummy part entry" should be replaced with the actual volume size as partition data.

This is another useful source for NASM fiddling: http://goncharov.pp.ru/en/osboot.htm The makebootfat things always worked for me (with the notable exception of some InsideH2o ones), but as you well know BIOSes are strange things. And yes, the MINI-MBR approach is a very nice one. Unfortunately Nuno has disappeared from radars, so I believe that yes, reboot.pro is gone. I am still in contact (like once a year we send each other a ping) with erwan.l , he does have some old backup/archive of the board (mid 2020 if I recall correctly) that could - in theory - be possible to put again online as read only. But don't count too much on it. I am attaching the result of some of my old fiddling with the Anvin/Mazzoleni code, maybe it is useful to you. Mbr_NTFS_BS_001.zip

As I see it 144/64/32 is a good guess, though I don't think that we will ever know if accurate. I believe the Caleb UHD 144 was never adopted in meaningful numbers, so it is only for completeness. But then you should add also the previous Insite 20.8 Mb "floptical": https://wiki.preterhuman.net/Floptical 755/2/27 with sector size selectable between 256, 512 and 1024 bytes.

Well, you did a lot of work, very good . There is something else that may be of use to the old tinkerers, the makebootfat approach to have a disk that is at the same time a floppy and a partitioned disk: https://www.advancemame.it/doc-makebootfat.html Also (JFYI) check this: http://reboot.pro/topic/12436-usbzipls120-booting-with-minimalist-mbr-code-and-grldr/ it may contain something useful.

Only to clarify, making a partition active doesn't touch at all the partition itself, what "make active" means actually "mark the partition as active in the corresponding MBR partition table entry (by writing 0x80 in the appropriate field)", it is essentially flipping a flag to allow the MBR code to know which partition boot record is to be chainloaded . On a GPT partitioned disk there is not really a MBR, its place is taken by a "protective MBR" that has only a table with a single entry with a special partition type (0xEE) that spans the whole disk and is there to tell older programs that they shouldn't touch the MBR partition table.

They needed this user script: https://msfn.org/board/topic/184051-my-browser-builds-part-4/page/203/#findComment-1258499 but until yesterday they worked just fine with it. Maybe there is another (new) userscript needed. Will try supermium.

It seems that - starting today - Discourse based forums are not anymore accessible (with Palemoon/Newmoon 27.9.6). Is there a (new) version (of NewMoon/Serpent/whatever) that still works (running on XP 32 bit)?

You seem like assigning a value to the DRIVE variable, but later you use the USBDRIVE one. Also, you have bo provision should the file/folder be not found (empty variable). Besides that, depending on the OS and machine, the "IF EXIST" may be not the right way, see starting from here:

Let's first thing remove some basic conceptual errors. 1. there is no such thing as relative physical sector, a physical sector is always absolute, its LBA is the number of sectors before it from the start of the disk, there is very little so absolute as the first sector of a disk. 2. a logical volume inside extended partition is in NO way different from a primary volume (ONLY the way it is addressed, in the chain of EMBR's (sometimes called EPBR's) vs. directly in the MBR is different, which implies that the Sectors Before in the VBR are relative to the EMBR and not to the MBR, but it can be corrected and have a logical volume be bootable), see the usual: https://www.goodells.net/multiboot/index.shtml (i.e. transforming a relative address to its absolute one) 3. alignment: there are only two main types of alignment (in MS world, Linux - generally speaking - does *whatever*), the 63 (actually last sector of cylinder/head, so if the device has CHS of X/Y/63 it is 63, if the device is X/Y/32 it is 32, etc.) and the Megabyte one, which is a (wrong) implementation of the actual new approach (offset being a multiple of sector size, page size and cluster of the filesystem) to all practical effects this could have been done on 128 sectors or less (128 sectors is multiple of 2, 4, 8, 16, 32, 64 sectors) , for whatever reason Microsoft decided that 1 MiB 1024*1024=1048576 bytes was a "better" multiple, this creates the now common initial CHS of the first partition of 0/33/32 or LBA 2048. 4. the gap between partitions. Most if not all partitioning programs leave no gap between partitions, which if you think about it is automatic, the first partition needs a gap to be aligned to the desired standard, then it is created with a size aligned to the same standard, so next partition will necessarily be aligned, and so on. The EMBR chain, of course creates before each logical volume a gap, the same size of the first one. Until you will have fully and completely learned and understood the information on the given goodells.net page you will only get confused, everyone uses a slightly different terminology to call the same things and some concepts need to be digested. jaclaz

It all revolves around the same project by ChrisR, Win10pese that evolved into Win10xpe, now on github: https://github.com/ChrisRfr/Win10XPE

I thought that was SPECTRE: https://en.wikipedia.org/wiki/SPECTRE "Special Executive for Counter-intelligence, Terrorism, Revenge and Extortion" jaclaz

What we, highly specialized technicians, call "sweeping the dirt under the rug".

Only for the record, it wasn't stolen, and it doesn't mean letter. Telegramma means telegramma, NOT lettera. Telegram is an English word alright, and means, like in Italian, a message (a letter if you like, but usually telegrams were way shorter than a letter or would have costed an arm and a leg) sent through the telegraph: https://en.wiktionary.org/wiki/telegram#English https://en.wikipedia.org/wiki/Telegraphy#Telegram_services of course the root is the same of telegraph, from Greek tele (distant) and graph-ma (letter/written message from graphein to write). Telegraph is the method technology, telegram is the message delivered through that technology. Of course the English don't use it, replacing it with wire or cable. Curiously enough, the Russian word for it - besides cyrillic transliteration - is телеграмма more similar to the Italian, or to the French télégramme.

For a francophone, you have a good example in Maurice Leblanc re-known character: https://fr.wikipedia.org/wiki/Arsène_Lupin Arsenio in italian.

Maybe it depends on transliteration, I can find quite a few people with that name on wikipedia, so probably not that much rare: https://en.wikipedia.org/wiki/Arseny It derives from Arsenius (Latin, arsenikos in Greek): https://en.wikipedia.org/wiki/Arsenius that actually derives from arsenikos, which is the same root from which the chemical element and the poison are commonly named but that means mainly "male" or "virile": https://en.wikipedia.org/wiki/Arsenic#History and the whole stuff comes from Persia via Syria ...

First they came for Dixel's Instagram account ... https://en.wikipedia.org/wiki/First_they_came_...

Just in case: https://neal.fun/password-game/ jaclaz

When I posted here, I could not find a way to send the message, so I posted its contents, later, after having pruned the second instance of the 4.3 word, it was finally accepted. So the user will likely reply, the risk is that he will accidentally use the by now famous 4.3 word and get a 403 forbidden when replying. Since Karla posted here, this thread is visible to all members and they can post on it (i.e. it is not read-only). jaclaz

I received a PM by a fellow member and - for whatever reason - I cannot reply to it, nor I can start a new conversation/ send a new message. In both cases I got code 403 forbidden. In the remote case the user (Bacho) happens to read this (there is nothing personal in the message, he was asking about an issue he has with booting an XP installation booting only from a USB stick and failing when the USB stick is removed), the reply would have been: After the usual zillion tests, it is not the known BOOT.INI issue alone, it is the link to the other thread in the form of a preview that triggers the behaviour, the text only link allows it BUT this worked on this post (the 4.3 word is present alright), but not on the PM, where I had to remove all occurrences . jaclaz

Well, even if your program is nice and all, it will take time to get it known. You could try submitting a link to it at tinyapps: https://tinyapps.org/faq.html your thingy seems like just the right kind of tool for there. jaclaz

There are four usual ways these fake drives are made, once said that if a "bulk", "no name", 32 GB SD card can be found for (say) 5 bucks, when you buy for the same or double price a 2, 4, 8, 16 or 32 TB media you are actually getting at the most the same capacity of 32 GB: 1) simplest, the media has a capacity of 32 GB but the MBR or GPT and the filesystem (volume) on it have been manually modified to appear larger 2) more complex, the controller has been programmed for more or larger chips than those actually available 3) even more complex, the controller has been programmed with mapping the same extents to different addresses, the space simply "wraps around" (multiple times) 4) an even more subtle way of version #3 exists, when the wrap around is not of the whole disk, but is after the normal placement of the filesystem structures #1 can be detected by a simple CHKDSK, or simply writing to it enough data #2 can be as well detected by checking the filesystem with CHKDSK or writing to it enough data #3 is trickier to detect and usually needs a dedicated program, like H2testw, when writing to it enough data, the filesystem structures are overwritten and the volume becomes raw/not accessible anymore. #4 is really tricky, only using tools like H2testw or writing to the disk special (numbered/identifiable) data patterns they can be detected, otherwise the data in excess will be written just fine (without errors) as the same area is overwritten but the filesystem structures are updated correctly. On a typical NTFS filesystem, if you have the first 10 GB or so (for exFAT even less) set correctly and the rest wrapping around the device will seemingly behave fine, new data will overwrite earlier data without triggering errors. jaclaz

@tekkaman JFYI, the advantages of aligning (one way or the other) is (largely) bul*****. If "everything" is aligned (NTFS is inherently aligned, FAT 16/32 are usually not) then there some (slight) advantages, actually only noticeable on slow bus or slow devices (such as USB 2.0 devices) on a relatively fast bus (like SATA 3) they are negligible (for traditional rotating hard disks, which also tend to have largish caches) while it is a very good idea to align to multiple of the sector AND of the memory page for SSD's. Check: http://reboot.pro/index.php?showtopic=9897&p=85960 https://msfn.org/board/topic/154633-partition-boundary-alignment-in-4096-byte-physical-sector-drives/ jaclaz

Only to (hopefully) clear the matter. The 2.2 Tb original limit depends on the 32-bit size of the MBR partition table that sets at 2^32-1=4,294,967,295 the max number of sectors accessible.[1] If the disk exposes 512 bytes/sector the limit is then 2.2 Tb. If the disk exposes 4Kb/sector size (so-called "Native 4k" disks) the limit is 8 times that much. What a number of USB external enclosures (the controllers in them) do is to expose on the USB connection the disk as if it was a Native 4k one, i.e. it makes the XP believe that the disk has 4 kb/sector, thus allowing to use "normal" 512 bytes/sector disks of much larger sizes than 2.2. Tb. The chosen method of alignment (to the cylinder up to XP, to the Mb on Vista and later) is unrelated. jaclaz [1] only for the record, at the time I devised a partitioning schema with two (or more) partitions that allowed to use MBR disks up to (almost) 4.4 Tb, but (a few) actual tests led to the conclusion that while the schema did work on later OS (7 at least) it did not work on XP due to some other limitation (still 32 bit related) in system files.