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

... so that we have now a number of yutes [1] that are not capable of doing a simple subtraction, like - you know - making the change for a cash payment without using a calculator, or more generally are so arithmetically (besides and before mathematically) impaired to fail calculating mentally even orders of magnitude ... jaclaz [1] https://www.imdb.com/title/tt0104952/quotes/qt0404568

All is well that ends well ... jaclaz

Check from here: to here: jaclaz

With all due respect, if it unmaintainable it doesn't actually *need* to be killed (killing with it years of shared knowledge). It should be possible to simply block new membership or even putting it in "read only mode". jaclaz

Good Besides the eprom replacement, when re-mounting the PCB make sure, double sure and triple sure that contacts are clean (use an eraser and isopropyl alcohol if needed) and that you tighten the screws "firmly" (don't overdo it, but do not power up the thingy with the PCB not properly attached to the drive). jaclaz

Oh, noes. Since some 10 or maybe 15 (ten or maybe fifteen) years hard disks PCB's contain "adaptive" data. If you are lucky, the PCB swap didn't cause damage to the platters. Why didn't you ASK before doing a PCB swap? Or actually tried looking for related info? You know, like here: https://msfn.org/board/forum/169-hard-drive-and-removable-media/ Essentially a PCB swap on a modern hard disk is futile as it CANNOT work (but in the worst cases can also damage the hard disk internals) You have basically only three possible ways out: 1) do a ROM swap (provided that the EPROM on the "fried" board is still good AND that the already done PCB swap didn't create further damages)[1] 2) send the "fried" PCB to one of the good guys that sell "swaps" for hard disks (that included in the sale or for a small additional fee will desolder the EPROM from the old PCB and solder it to an used, compatible PCB that they will send you) 3) fork from some serious money and send the disk to a recovery company that might be able to do the same for ten or twenty times the price of #2 above or - should this not be possible - fix via PC3000 or similar the firmware and adaptive data. jaclaz [1] this involves some level of familiarity with desoldering and soldering chips without ruining them. And of course you need to procure an EXACT match for the spare PCB anyway