> I took the easy way out on this one. Rather than more reading and > downloading I booted Windows on an old Dell, which when double > clicking on it in the file manager extracted > mb_bios_ga-970a-d3_f12.exe from mb_bios_ga-970a-d3_f12.zip then > extracted FLASHSPI.EXE and the 4M 970AD3.F12 from the .exe.
...first and foremost, glad to hear that that your problem is now solved. > > Or maybe the exe is just a self-extracting ZIP, then UNZIP may > > help? > > I don't generally luck into those from motherboard makers. Yeah, I second that... especially "the big three" tend to obfuscate the internals of their BIOS update packages, which are generally for Windows only and the outer shell is an opaque Windows executable. Some "brands" of these EXE shells can be dissected by the archiver brand's own or third-party tools. Most of the archivers (ARJ, RAR, ZIP) can have a self-extracting EXE header strapped on - that's the easy case. Then you have installer creation tools, which add more magic that's specific to installing software in Windows... InstallShield, WISE, NSIS, WiX, and there's the MS own MSI format (which is not EXE). And there are probably less popular and more proprietary ones... such as those used for BIOS update packages :-( In general nowadays, a nice convenient "is this possibly an archive" inspection tool is 7-zip, namely its GUI for Windows. It understands UNIX formats too (TarGzip, Tar Bzip2 etc.) and even takes squashFS images... If you still encounter InstallShield, there is UnShield. BIOS updates, per se, can be non-trivial. Perhaps there's a good reason why the packages are made opaque. Namely, the ROM image tends to be "no longer a 1:1 copy", unlike what it was two decades ago. I've seen image formats that have a header, so the image is not a "binary rounded size" anymore. Or it can be compressed in some proprietary way. Or it may need proprietary "strapping" in the particular machine. Etc. (Let alone the fact that UEFI NVAR's are stored on flash in the host machine = bye bye setup reset by removing the CMOS battery.) For instance AMI at least make their proprietary flash programmer binaries available for DOS (still? maybe no longer), Win32/Win64 and UEFI (can be run from the EFI shell). Thus, even if the machine is UEFI-only, and does not have the UEFI shell included (in the system "BIOS"), you can still boot UEFI shell from a USB flash, and run the AMI flash tool from the UEFI shell. AMI also have a flasher tool for Linux, not sure how portable, see also this if interested: https://github.com/flohoff/amifldrv If you still meet the good old Award style 1:1 binary images, congrats, that's good luck on your part :-) Not sure what happened to the Award BIOS codebase to this day, it's been years since it got acquired by Phoenix, and that possibly happened before the Award BIOS got UEFI support/architecture. I recall that Asus\Gigabyte\MSI used to create their own "cuts" of the awdflash tool, and you needed the mobo maker's own cut to flash the BIOS... or perhaps it was just the recentmost upstream releases coming out from Award and being required to flash your mobo, not sure. Phoenix themselves, for their own legacy BIOS, apparently/possibly used a different "image packaging style": I recall once seeing a Phoenix BIOS update that consisted of a series of smaller files... that needed to be assembled by the flasher tool. This is not something you'd want to rip apart and try to flash using some generic tool. There's also the generic "flashrom" tool, originally coming from the coreboot project, open-source and native in Linux, also used to have binary EXE builds for DOS: https://www.flashrom.org/ There have been occasions where I used it to take a BIOS image as a snapshot of the ROM chip from an existing motherboard, and flash it in a different piece of that same HW model+revision. Flashrom works with 1:1 images. And apart from in-band flashing on a live motherboard, it also supports out-of-band flashing via an SPI adaptor... (can be out of band AND in circuit). Note that by 1:1 cloning, you also clone any DMI serial numbers or similar unique data - if you care about those. > > file mb_bios_ga-970a-d3_f12.exe > mb_bios_ga-970a-d3_f12.exe: PE32 executable (GUI) Intel 80386, > for MS Windows > Yes... the EXE binaries historically come in several flavours: DOS vs. modern Windows (NT-based), and the Windows variant further subdivides to a myriad CPU instruction sets... there are tools that can go into much more ugly details about the PE-COFF header. I recall something called LordPE, then there is IDA Pro (the free version is x86 only), and recently I recall that a tool called dotPeek (by JetBrains), nominally a dotNET decompiler, also contains a neat capability to show you all the ugly details of a PE-COFF header, even if the binary at hand is not of the dotNET persuasion: https://www.jetbrains.com/decompiler/ What does the MZ header do, at the beginning of Windows PE-COFF binaries (hint: historical legacy compatibility): https://stackoverflow.com/questions/957057/what-is-the-mz-signature-in -a-pe-file-for I guess this should do for my daily wallpaper... Frank _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
