jaclaz

Why, in my day ... https://tinyapps.org/blog/200702250700_why_in_my_day.html My first computer was a Sinclair ZX 80 ( yes the one before the ZX 81) and I soldered components to build it ... and we liked it ! (and it was replaced in a few months time by an actual ZX81) Kids today ... jaclaz

Good ol' Rubber Ducky? http://www.willsoftware.com/rubber-ducky-system-monitor-83269.html http://www.mimarsinan.com/rubberducky.asp jaclaz

Well, I expressed myself incorrectly. the MBR is not copied, some parts of it are copied and a new MBR is created using some of this data, correcting it when needed - loosely - the MBR is made of three (actually four, please read as five) parts. 1) Bootcode 440 bytes (0-439) 2) Disk Signature 4 bytes (440-443) 2.a) Unused 2 bytes (444-445) 4) Partition table, 4 entries 16 bytes each=64 bytes (446-509) 5) Magic Bytes 55 AA (510-511) The bootcode can in theory be empty, but some BIOSes/OSes might *want* or *need* some leading bytes The DIsk Signature is only used on NT based systems to "ID" the disk uniquely. The unused bytes are - well - unused an they are normally 00 00. The Partition table's entries contain a byte (either 80 or 00 ) for active/bootable, a byte for partition filesystem ID (not really-really, it is actually a "protective ID", but for years it has been used as ID) some data with the CHS addresses of the extents of the partition and the last 8 bytes are the LBA addresses of the extents of the partition. The boot code cannot be "read" (it can be read but it cannot be interpreted), it could be disassembled, but it is not normally needed/useful, set apart some special code (like grub4dos itself, or - say - MBLDR) there are tens of different MBR bootcodes (including those standard for DOS/Win9x and those for the NT family of OSes) that all essentially do the same, i.e. they parse the partition table contents and chainload the bootsector of the (porimary) partition that is set active. In the example I posted the MBR is completely blank (00's) exception made for the disk signature, the two partition table entries and for the Magic Bytes. What grub4dos does is (on the mem mapped disk MBR) 1) insert a few boot code bytes <- these are not a real boot code but rather some bytes that are needed on some particular BIOSes or OSes, it is only a "compatibility" provision, anyway since you are alreasy in grub4dos you will proceed by-passing the MBR code and either boot the PBR or firectly chainload the OS loader or System file (the io.sys in this case). 2) insert a new disk signature (it cannot be the same as the source) 3) copy the size of the chosen partition and maje an active entry for it with a default offset of 63 sectors 4) write the magic bytes Then on the given partition PBR it corrects the "Sectors Before". Of the partition table, even if you haven't got a parser like (shameless plug) this one for grub4dos: http://reboot.pro/topic/17728-release-mbrviewg4b-a-bat-tool-for-grub4dos/ or (even more shameless plug) Tinyhexer with my Structure viewer: http://reboot.pro/topic/8734-tiny-hexer-scripts/ the relevant parts are easy enough to read manually, namely, for each partition entry: 1) the first byte is active if 80 or non active if 00 2) the fifth byte is the partition (protective) ID 3) the last four bytes are the size of the partition in sectors 4) the 4 bytes preceding the last four are the offset to the beginning of the partition (still in bytes). Now, with this info, let's read the data in the partition table in the screenshots I posted: On the mem drive (hd3) (mapped from the whole disk (hd0), first entry: 1) 00 non active 2) 1C Type 1C 3) B8 0B 00 00 = 0x00000BB8 = size 3000 sectors 4) 3F 00 00 00 =0x0000003F = offset (or starting at LBA or "Sectors Before") 63 sectors Second entry: 1) 80 active 2) 01 Type 01 (this means FAT12) 3) 00 3F 00 00 =0x00003F00 = size 16128 sectors 4) C0 0F 00 00 =0x00000FC0 = offsset (or starting at LBA or "Sectors Before") 4032 sectors The above is exactly the the same as the "original" (hd0) MBR. On the mem drive (hd2) (mapped from only the second partition (hd0,1)), there is only one entry: 1) 80 active 2) 0E Type 0E (this means actually FAT16 LBA mapped [1]) 3) 01 3F 00 00 =0x00003F01 = size 16129 sectors [2] i.e. same size (+1 sector) as the second partition on (hd0) 4) 3F 00 00 00 =0x0000003F = offset (or starting at LBA or "Sectors Before") 63 sectors (which is a "default" offset for first partition in any OS before Vista) Now let's see the bootsectors, the interesting parts are (this is a very small FAT volume): 1) at offset 19 or 0x13 "small sectors" 2 bytes 00 3F= 0x3F00= 16128 sectors 2) at offset 28 or 0x01C "sectors before" 4 bytes, respectively: (hd3,1) - same as (hd0,1) C0 0F 00 00 =0x00000FC0 = 4032 sectors (hd2,0) 3F 00 00 00 =0x0000003F = 63 sectors jaclaz [1] this is a little "bug" of grub4dos, see here for the story of this queer bug: http://reboot.pro/topic/21732-windows-for-workgroups-311-grub4dos-and-protected-mode/ (it won't affect you since you are not going to use Windows 3.1/3.11) [2] strangely enough there is a (rather perverted) reason for this, the partition was originally created in XP and as NTFS, so the "backup bootsector" at the end of the partition (but outside the volume) has been "included" in the volume when it was re-formatted to FAT12.

That one is an issue with the installer. BUT get the portable version here, instead: https://www.partitionwizard.com/partitionmagic/portable-partition-magic.html And discover that - notwithstanding what the guys say on their page - : it won't work - at least here - on XP (Major/Minor are 5.1 just fine) throwing an error on missing entry point "GetLogicalProcessorInformation" in KERNEL32.DLL Everything is normal (in this world), in a perfect world people would write good software, document it properly, respect other people's IP (and licenses, and time, and ... ), jaclaz

With: map --mem (hd0,0)+1 (hdn) you are in theory mapping the first partition of hd0, i.e. (hd0,0) to a "whole" disk (hdn) So, the first sector of (hdn) would be the first sector of (hd0,0), i.e. a bootsector (or PBR/VBR) and not a MBR. whilst with: --map --mem (hd0)+1 (hdn) you map the whole disk hd0, i.e. (hd0) to a "whole" disk (hdn) In theory the first one shoudln't work , but grub4dos automagically (I believe this may depend on the specific version, I seem to remember that it was added somewhere in 0.4.5c, but I may be mis-remember) does a few things: 1) copies the MBR from the source disk to the mem disk 2) writes to the MBR on memdisk a new single partition entry (with an offset of 63 sectors, normally) for the volume, 00ing all the others (if any) partition entries 3) copies to mem the actual volume 4) corrects (if needed) the sectors before in the BPB of the volume I am attaching a couple of screenshots that should help explain the above, I am mapping, for the sake of the example to two different mem disks to show the differences. Everything is fine and dandy . jaclaz

It is always worth the five minutes it takes to try and change the major/minor OS in the executable. A number of executables are perfectly fine running in XP BUT they are compiled with a "default" setting targeting 6 (Vista). This results in the error "This is not a valid Win32 application". Get CFF explorer: https://ntcore.com/?page_id=388 Open with it the (copy of the) executable and select "Optional Header". Then change: MajorOperatingSystemVersion to 5 MinorOperatingSystemVersion to 1 MajorSubsystemVersion to 5 MinorSubsystemVersion to 1 and save. No idea if this applies specifically to Inno Setup executables, though. jaclaz

1) You will need to read "dictionary" as "directory". jaclaz

Hmmm. Can you try adding, right after the: map --mem (hd0,0)+1 (hd0) map --hook a: cat --hex --skip=446 (hd0)0+1 pause What do you get? Explanation: at first sight map --mem (hd0,0)+1 (hd0) maps the first (primary) partition to the whole device (i.e. it should be a superfloppy), unless there is something else going on , the (hd0,0) reference should not be valid. It should be: map --mem (hd0)+1 (hd0) to map the whole disk. jaclaz

Only for the record, the site in question opens (and works) just fine on SRWARE Iron (Versione 43.0.2300.0) from my XP (SP2, yes, I know, don't ask). As a side-side (really side) note, I noticed something somewhat "queer" (at least judged from my foreigner viewpoint): and: It is perplexing . jaclaz

It is his mom's iphone, it is already surprising she allows him to touch it , let alone jailbreak it. Imagine - just imagine - that while attempting the jailbreak process the phone bricks ... jaclaz

Yep , This is exactly what I was trying to specify/detail. DOS/WIN9x use BOTH the label field in the bootsector AND the "label" as special entry with attributes 0x28 in the filesystem (in the root directory if FAT12/16). Windows 2000/XP and later (and possibly also NT 3.x/4) ONLYuse the label as special entry (but with attributes 0x08) in the filesystem (in the root directory if FAT12/16). Very likely this is connected to the different level of abstraction of the device, DOS has direct access to storage, NT has an intermediate layer. The grub4dos command vol evidently behaves like 2K/XP and later. Of course (JFYI) you can change the label in the bootsector with grub4dos, by directly writing to its field in the bootsector. The label field is 11 bytes ([SPACE] aka 0x20 padded) at offset 0x2B. You can use *something like* catedit.g4b (shameless plug ): http://reboot.pro/topic/18783-release-cateditg4b-script-to-write-hex-values/?hl=[release] But it would be possible to write a small batch with the offset fixed and - possibly - the translation from ASCII to hex for the label string. jaclaz

AFAIK the grub4dos vol --write command writes to the FAT filesystem just fine. The LABEL (DOS or windows) command writes to the FAT filesystem just fine. DRIVESPACE drives may well be a diffeerent beast. There is also a "label" in the bootsector, this is normally NOT used by anything (anymore). So, if you did use (say) : cat --hex (hd0)0+1 i.e. you are looking at the bootsector, you won't find the label (which is a special entry, typically with 0x08 or 0x28 attribute in the filesystem - in the root directory if FAT12/16) see: I just tested, and the grub4dos writes it with the 0x08 attribute (like XP) instead of the 0x28 attribute (like DOS). Probably this is part of the reasons why you have different results with different tools. jaclaz

Hmmm. I have a number of doubts about the contents of the menu.lst, and particularly on the use of vol and uuid. I can understand the change to the uuid (actually the volume serial) since it is used in the batch but I wonder what is the point of changing the label to U11MEMDRIVE if that data is not accessed and BTW I don't understand the note about it being not compatible with the LABEL command. Also I am not sure to understand the rationale behind exchanging floppy disks? jaclaz

We don't want proof, we want puff. Whatever Goodmaneuver was smoking is probably good because it has aged. Yeah, time is very, very good at passing fast . Good to know you managed to solve the issue. jaclaz

And how is this related to a three years old thread abour LS-120's? jaclaz

Well, with all due respect , this doesn't sound a rational reason. Making an extended kernel (presumably both in 32 bit and 64 bit flavours) is something that should take a few zillion "units" (of programmer's time, i.e. either a looong time by a single programmer or a short time by a multitude of programmers) whilst adapting (or even re-writing) the code because a new update changed something shoudl take a very little amount of units. Anyway, we will see what will happen in two months time, IMHO, whether you are a lion or a gazelle you'd better start running: https://quoteinvestigator.com/2011/08/05/lion-gazelle/ jaclaz

First thing, hello and welcome . Then - if I may - I would like to ask you why (the heck) did you feel like starting the thread you linked to if you plan for your project to "take place" no earlier than January 2020 [1]. Did you fear that someone may have stolen the project name ( "Windows 7 Extended Kernel" doesn't sound like a particularly original name)? What do you expect from members of the board? To wait patiently at least a couple of months waiting for the project? (BTW is January 2020 "start of the project" or "projected release date"?) To become "followers" of this project before the project is even started? Something else? jaclaz [1] Full disclosure: I am an old and grumpy bastard, but I have seen tens of similar very ambitious projects being announced that never delivered anything or anything actually working.

Not really-really, that would be too d@mn simple. update #37, if it is a wednesday, odd month number but even day number and there is a full moon in the GMT minus 4;00 + your actual location time offset AND you have not update #96 but you have 101 and not 115 will crash your system. jaclaz

It is essentially "voodoo" or "black magic" , IF it is the original bug it may depend on the number of power ons the drive had (and how many other events were written to the event log in each session): See: So, it is possible that you were a lucky one that for some reason never hit the 320+n*256 value in the circular log in all these years. Then you suddenly became unlucky and disaster hit you . But soon enough you were lucky again and managed to recover the disk/data . All is well that ends well. jaclaz

Well, the READ-ME-FIRST: has a part dedicated to grounding that more or less says: I interpret that (and in particular the words ALL and ANYTHING) to be meaning what they mean, typically ALL and ANYTHING. Particularly the bolded part above should be of interest to you. Do you still have any doubt? The general idea is that of making an equipotential connection, see again the above READ-ME-FIRST in the part about TTL levels, particularly: jaclaz

Tony111 , it is like from day #1 of this comedy (drama), i.e. 2009 (i.e. more than 10 years) that EVERYWHERE it is written: DO NOT use a Nokia C-42 cable UNLESS you know what you are doing , there are a zillion versions of real and fake CA-42 cables some working, some not, EVERYONE with differently coloured cable, in ANY CASE NEVER trust colours of the cables to identify. The answer to question #1 is (and has always been): DO NOT use a CA-42 cable, but rather a known, documented serial adapter, if you really-really have no ways to procure one AND have a (supposed) NOKIA CA-42 cable handy you need to identify the wires properly (and even if you do that properly, it doesn't mean i will work) Please go (several times if needed) through: and: The ONLY proper method to identify cables is (was) here: https://web.archive.org/web/20100223072633/http://buffalo.nas-central.org/wiki/Use_a_Nokia_Serial_Cable_on_an_ARM9_Linkstation if you wish to follow this road, use that method (and that method only). The answer to question #2 (which is present in BOTH the Read-Me-FIrst and in the FDA's linked to above and that you should already be familiar with, please check, double check anf triple check what is in there about "loopback", is: It depends, no way to know. Using an XP is known to be working. Using a 7 (and Putty) is known to be working. Using 10 may or may not work and Putty might be needed or it might be not. jaclaz

No need to apologize , though what I actually meant is still slightly different. Mass Storage connection makes sense for a mass storage device and (by convention) this implies on Windows that a drive letter is assigned to volumes on it, but this drive letter assignment is the result of the way Windows works because it has access to the PhysicalDrive and - via mount manager - to logical volumes (what get a drive letter) and their filesystems. The (stupid) PTP/MTP approach is at a higher level and never provided drive letters because it has no connection to the physical drive, and what I was lamenting about was not the lack of drive letter access but rather the lack of the more direct access that allows otherwise (besides other possibilities) "normal" drive letter access. A good example of a similar approach is FTP, you have NO idea when you connect to a FTP site/directory what OS is running "there", nor which filesystem you are actually accessing. Still you have exposed some file characteristics, like (usually) size and date. If you take (on a "recent") window a ftp site you can map it to a drive (drive letter) just fine, *like*: https://www.thewindowsclub.com/map-an-ftp-drive-windows or - via third party tool - *like*: https://www.ferrobackup.com/map-ftp-as-disk.html Still only a part of the data (those provided by the FTP) are available, so, even if you have *some* access via drive letter, you do not have the same amount of data/access as if it was a local disk drive. In the case of a FTP (please read as "remote") device this is of course "normal", but in the case of PTP/MTP the mass storage device is "local" allright, connected by a (usually too short to be practical in most real world situations) USB cable, and there is no reason for arbitrarily removing (by using the stupid connection protocol) otherwise technically possible ways to access it, if not the utter stupidity and total lack of respect for the customers that are common between the good MS guys and the good Google guys (and all the sheep, which include the large majority of customers and the actual manufacturers of the phones). What anyone[1] would actually want to be able to do would be: 1) periodically connect his/her device to a PC and 2) run a full dd of the phone "as is" to an image or restore the phone to an exact previous state by dding an image to it OR 3) use Robocopy or similar or backup/restore software AND: 4) perform any "common" maintenance for mass storage devices, like copying files, defragmenting the filesystem, etc. This would be easy, simple and effective, needing not an internet connection (think of the stupid "cloud" backups) nor any particular software from the manufacturer of the phone device (usually crappy, bloated and what not). Probably too simple and easy . jaclaz [1] anyone with some common sense, I mean, a very small minority of people in my eperience.

No, you misread it somehow (or I am misreading you now). Once there was Mass Storage Device connection, then that was removed and PTP/MTP was used instead. Whether an OS supports (or fails to support) PTP/MTP is another thing, but if the data is not "exposed" by the connection the other end cannot receive it properly or if the data accessible is only a subset of all the data, there is the issue. @dencorso It depends on the kind of access you need/want to the actual storage, the threads I linked to are mostly about what is "missing" when using MTP compared to Mass Storage Device, among others there are issues with timestamps of files, as an example. JFYI, https://www.forensicfocus.com/Forums/viewtopic/p=6563168/#6563168 Particularly: https://blogs.technet.microsoft.com/juanand/2010/12/10/playing-with-windows-phone-7-as-usb-storage/ jaclaz

See also: jaclaz

WIth all due respect , I am failing to see the "huge" or actually "any" advantages, it is simply a grub4dos called by a batch file, what is the advantage of: 1) boot to DOS or Windows (and exit to DOS) 2) run the Puppy.bat file 3) choose between Windows or Linux what to boot when compared to the "normal" way: 1) boot to grub4dos (installed in the MBR + a few hidden sectors OR called by the PBR/bootsector) 2) choose between Windows or Linux what to boot Technically, the proposed thingy does not reboot in the passage from DOS to Linux (which may be a "bad" thing as some BIOS tables data might be altered by the previously run Wndows/DOS or a good thing as the transition should be - very slightly - faster than a real reboot) but there isn't - if I get this right - a symmetrical way to pass from the Puppy Linux to DOS/Windows (using Kexec or similar) so if you are on the Linux and want to go to DOS/Windows you need to reboot anyway. jaclaz