jaclaz

Yep, whenever the error is "this is not a valid Win32 applicarion" it is worth to try this, though sometimes it is needed to change also the "Minor" OperatingSystem and Sybsystem fields though 5 0 5 0 is OK, jaclaz

To be picky (as I am BTW) the "normal" WinPE from MS does not have it, but it is entirely possible to have it in a PE build created by one of the common tools, i.e. Winbuilder or PEbakery. Win10PE SE has a script "WOW64 Basic" (written by our friend JFX) that does exactly that, i.e. "WoW64 (Windows on Windows64) provides support for running 32bit programs in a 64bit environment.". jaclaz

In other words, if ain't broken, don't fix it. jaclaz

Well, this is bordering with conspiracy theories, that would mean that VmWare paid Microsoft to force their (VmWares) users to update to a new version of VmWare, and that Microsoft took the money and did that knowing that everyone will blame them (Microsoft) for the issue. I would attribute the problem more to the usual stupidity (or rather increasing sloppyness/lack of quality control) of the good MS guys, with VmWare "innocent", so that there is not anything "planned". jaclaz

That issue is with Windows 3.1/3.11 (and - similar but different - with any DOS earlier than 7.0). It was released in times on par with DOS 5 and 6. Last "real" DOS (6.22) only understood FAT12/16 volumes AND CHS mapped only, (partition types 01, 04, 06). Windows 3.1/3.11 having been developed in the same period, and being actually a graphical shell over DOS. uses the same data. Windows 95 and conversely DOS 7.x was, starting with 2nd release, extended with the LBA mapping for "BIG" FAT 16 volumes and FAT32 (partition types 0B, 0C and 0E). To be exact 7.0 introduced LBA FAT16 (0E) and 7.1 FAT 32 CHS and LBA (0B and 0C). More or less *any* tool before Win95 2nd version (DOS 7.1) came out only understood 06 and created only 06 FAT partitions, while later tools, depending on the case, may create either 06 or 0E partitions, more likely 0E. Even if it is not "common" it is perfectly possible to run 3.1/3.11 over DOS 7.0/7.1, but the FAT16 partition needs to be 01, 04 or 06 or Windows 3.x will throw a fit (in protected mode) if it finds a 0E partition. The grub4dos map feature (BOTH the map --in-situ used in that referenced thread and when you map a volume to a whole disk like you do here) creates on the fly a new MBR partition table and for FAT 16 it creates it with an ID of 0E, that Windows 3.1/3.11 cannot fully understand, so the underlying DOS 7/7.1 boots fine, but when the protected mode (and some related drivers) kick in it will error out. Dos 7.x/8 (standalone) and Win9x/Me won't be affected as they understand 0E just fine, besides 0B and 0C, what happens when grub4dos through the map command creates the new MBR partition table entry is seen here: http://reboot.pro/topic/21732-windows-for-workgroups-311-grub4dos-and-protected-mode/?p=206527 In more detail the automatic "conversion" of partition ID is: 01->0E 04->0E 06->0E 0B->0C 0C->0C So I wrote the small batch to allow changing (when/if needed) the partition ID (which may in itself be useful for some other "crazy" experiments) and YaYa (one of the grub4dos Authors/Maintainers) added the feature through the --in-situ=FLAGS. (,both cover and are tested for the "map --in-situ" option only), Some tests would be needed to see if my batch works "as is" or needs to be modified in the case of a map --,mem (hdm,n)+1 (hdm) case (your case) but there is no need for this since you are using Win 9x and a 0C partition ID already. jaclaz

... and get (additionally/besides Serpent) QTweb, For "simple" sites it is faster and leaner than anything else. jaclaz

They do have a tendency to stop working, particularly on desktops/tower, in my experience laptops (kept properly) are less prone to this, I personally attribute this to three main factors: the drives (common desktops units) themselves are cheap (and as such they are cheaply made) they are used less and less, and lubricants tend to stick up as they dry up very often a lot of air (and dust) is blown through them by the PC internal fan(s), which makes lubricant dry and hardened by dust ciontamination Usually (on desktop units) all is needed is to disassemble and clean the inside accurately, particularly the lens, of course and in some cases cleaning the sliding parts and putting on them a tiny drop/bit of lubricant and move them manually is needed. You'll need both a vacuum cleaner and some source of compressed air. If you need some lubricant, you want to use Molykote EM-30L (which is a specific grease "safe" for plastic parts) for slides and gear teeths and sewing machine oil for metal rods and gear pins, if you cannot find (or afford) the Molycote (or even better "Superlube") any "white", silicon based grease would do, rule of the thumb i to use the least possible quantity of lubricant, (and that much is already too much, you should have used less ). Of course it is well possible that the unit is simply defective/worn-out, but it costs very little to try and clean/lubricate them. jaclaz

http://reboot.pro/topic/22191-how-to-make-a-multiboot-usb-stick-supporting-gpt-and-mbr-targets/ jaclaz

NONE. Read latest dencorso's post to understand why (even if personally I run XP SP2, and - just in case - yes, I know, thanks for telling me that SP3 and unofficial SP4 are available ) I doubt it will work, unless you have Windows File Protection Service disabled, read the instructions: https://www.win-raid.com/t4035f45-Windows-XP-Bit-and-Server-Bit-on-Modern-Hardware-242.html#msg96981 jaclaz

It depends on what you want it to do: The options available are: So, if you type: winxppae.exe /4GB [ENTER] you will have the needed files patched to support a maximum of 4 GB AND a backup of them (before the patch is applied) if you type: winxppae.exe /ALL [ENTER] you will have the needed files patched to support unlimited RAM AND a backup of them (before the patch is applied) if you add after EITHER the /4GB OR the /ALL the /NB or /NOBACKUP (DO NOT do this) switch, you will have NOT the backup. jaclaz

Well, that is much later (like three years later, a different age, it has colours) and it is essentially a Sinclair Spectrum: https://www.old-computers.com/museum/computer.asp?st=1&c=935 See: https://www.youtube.com/watch?v=1Jr7Q1yJOUM jaclaz

@dibya Isn't this the second (or maybe third) Christmas that you create some expectations for something that you never delivered? @caliber OK. Start -> All Programs -> Accessories -> Command Prompt You now have a black window open and you have a command prompt in the form of a line, probably *like*: C:\Documents and Settings\username>_ with the underscore flashing, right? Now you should know where exactly you have extracted the file, you can use windows explorer to get the right path. Let's say the file is in D:\IronPortable\Download\WinXPPAE.exe At the prompt (in the command promp window) you type: cd /d D:\IronPortable\download and press [ENTER]. Please note that if for any reason the path has one or more spaces in it, you need to enclose it in double quotes, example: cd /d "D:\Path with spaces\download" Now the prompt has changed to the path you just typed. Verify that it is the right place: DIR WinXPPAE.exe and press [ENTER] it should show you the file, its date and time. Now type: WinXPPAE.EXE and press [ENTER] You should see the following: jaclaz

Imagine that it wants some parameters on command line. How would you pass them to it? You know like *any* command line tool that expects parameters you could open a command prompt, navigate to the directorywhere the .exe is and then type on the command line the name of the .exe, in this case WINXPPAE,EXE and press [ENTER]. Maybe then it won't close in half a second ... jaclaz

Is it a black window? You know, like when you are trying to run a command line excutable that needs parameters by double clicking on it? jaclaz

And - you know - when some time later I bought a RAM expansion kit ( a so-called RAM-Pack) for the ZX81: https://en.wikipedia.org/wiki/RAM_pack taking the memory from 1 KB to 16 KB, thus I could run "very complex" programs, and I had to make a wooden support for the computer and pack to avoid the "wobble" problem, there were already rumours of (at an extremely steep price) an expansion up to 64 KB! You may now understand, how nowadays that Mega/Giga/Tera bytes are considered peanuts I still have preferences for small, tiny programs. 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