Jump to content











Photo
- - - - -

need help with virtual floppy


  • Please log in to reply
66 replies to this topic

#1 ady

ady

    Frequent Member

  • Advanced user
  • 118 posts

Posted 12 August 2010 - 08:42 AM

Hello. I installed ImDisk in Vista Home Basic 32bits. Copying files to the virtual floppy using Windows Explorer works.

But I experienced some problems using other programs that want to write to the virtual floppy.

For example, tools based on Ontrack Floppy Creator, such as:

IBM Disk manager 9.57
Ontrack Advisor 5.00 Trial
Ontrack Disk Manager 10.46 (2 floppy disks)
Samsung Disk Manager 10.42
Seagate Disk Manager 9.56a
Seagate Disk Wizard Standard Edition 10.45.06 (2 floppy disks)
Western Digital DataLifeGuard 5.04f

Such tools are created by floppy creators, and need a 1440K 3.5" A: formatted floppy under Windows to create the actual floppy tool. Some of them may need changing their properties (compatibility with XP), some may not.

In any case, under Vista, using a real physical floppy, I can create them.

But in a system without a real physical floppy, I tried VFD and ImDisk (not simultaneously) and it fails.

Under Vista with ImDisk, all Ontrack Floppy Creators stop at the same message:

Diskette write-protect tab must be closed

even in compatibility mode (XPwSP2, 2k, NT...).

Another tool, memscope 1.10, based on Winimage Self-Extractor 8.00, also fails while trying to create its floppy. I get the message:

Windows Error N. 5

Access is denied

and then the following message is displayed:

Disk error n° 69 on track 0, head 0

Access Is denied

with 3 options in the same dialog:

Abort, Retry, Ignore

Looking at the content of the virtual floppy after running memscope 1.10 floppy creator, there are several folders written to it, so the error is different from not being able to write to the virtual floppy at all.

So Winimage Self-Extractor 8.00 also fails with a virtual floppy (VFD/ImDisk) under Vista, as well as Ontrack Floppy Creators.

I test the same programs using VirtualBox, Vista as host, XPwSP3 as guest, and using VFD or ImDisk as virtual floppy (as opposed as using VirtualBox's virtual floppy). Under VirtualBox XP, all programs worked successfully.

Additionally, Seagate Seatools 2.20 floppy creator based on Towodo (formerly rundegren) Floppy Self-Extractor works successfully also under Vista with a virtual floppy (no need of VirtualBox and XP).

There are several points maybe worth mentioning, while using VirtualBox's XP guest OS:

-VFD/ImDisk/VirtualBox were ran as "Administrator".
-The floppy creator programs were ran as "User", which has administrator privileges (permissions), but not as the "Administrator" user.

For reference, every time I tried ImDisk, no other floppy was installed. That is, no additional ramdisk tool, virtual floppy, real physical floppy, and no floppy enabled in BIOS. Only one virtual floppy at a time.

I apologize for the long post. I wanted to provide all the info I could. If there is more info to provide, just ask for it and I'll do my best to provide it.

Since the floppy creators work under Vista with a real physical floppy, but not with a virtual floppy, I would like to know if there is something I'm doing wrong, or maybe there is something that could be improved in ImDisk to make it work in Vista, other than just copying files with Windows Explorer.

Any help is very welcome. Thank you in advance.

#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,081 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 12 August 2010 - 10:01 AM

Since the floppy creators work under Vista with a real physical floppy, but not with a virtual floppy, I would like to know if there is something I'm doing wrong, or maybe there is something that could be improved in ImDisk to make it work in Vista, other than just copying files with Windows Explorer.

It is very possible that these particular apps use an "unconventional" approach to writing to the floppy.
IMDISK is NOT suited for this kind of "low level" type of writing, as it is at a "upper level".

VFD should. :mellow: But is possible that being a bit dated has problems on Vista.

You can try one of the new drivers, firadisk and/or Winvblock, they are the "lowest possible" form of drivers.
http://www.boot-land...hp?showforum=94

Post a link to one of the tools that don't work, I'll have a look if another way is possible.

A known workaround is in any case a Qemu VM, but it may be overkill.

:)
Wonko

#3 ady

ady

    Frequent Member

  • Advanced user
  • 118 posts

Posted 12 August 2010 - 11:26 AM

It is very possible that these particular apps use an "unconventional" approach to writing to the floppy.
IMDISK is NOT suited for this kind of "low level" type of writing, as it is at a "upper level".

VFD should.


I thought ImDisk was based on VFD. I tried both with the same results.

But is possible that being a bit dated has problems on Vista.


That's why I thought ImDisk could be better than VFD in Vista.

You can try one of the new drivers, firadisk and/or Winvblock, they are the "lowest possible" form of drivers.


I am not a programer, but just a simple user. So for several days I've been searching for some other virtual floppy or ramdisk tool to make it work in Vista. When I took a look at firadisk and/or Winvblock, they started with something like:

This driver is not suitable for people who are not familiar with making and manipulating disk image or don't know how to use GRUB4DOS.


The last quote is from firadisk's topic. For me, a simple user who is willing to learn, Winvblock starts even worst (experimental not clean code with memdisk...).

So if you could give me a tip where exactly to start with, I guess I have a lot to learn about memdisk and grub4dos, or to find a simpler solution.

Post a link to one of the tools that don't work, I'll have a look if another way is possible.


Western Digital DataLifeGuard Diagnostics 504f floppy creator:

http://support.wdc.c...s...d=2&lang=en

Download the exe floppy creator from that page, unblock it, and change its properties to run in XP compatibility mode (since that web page states XP as supported OS, but not Vista).

Another example would be memscope 1.10, downloadable from:

http://www.softpedia.../Memscope.shtml

For the test, you should download the memscope 1.10 floppy creator exe.

A known workaround is in any case a Qemu VM, but it may be overkill.


As I said:

I test the same programs using VirtualBox, Vista as host, XPwSP3 as guest, and using VFD or ImDisk as virtual floppy (as opposed as using VirtualBox's virtual floppy). Under VirtualBox XP, all programs worked successfully.


I don't know if the time and hard disk space needed to install VirtualBox and XP as guest and all the steps needed to make a virtual floppy image are more, or are less, than the time and resources to make firadisk or Winvblock successfully work. I hope you could advise me about it.

I don't use VirtualBox for anything else. I'd rather have a virtual floppy / ramdisk tool work in Vista (or DOS). I guess the better option depends on time and resources.

Thank you in advance.

#4 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1,045 posts
  •  
    Belgium

Posted 12 August 2010 - 02:29 PM

@ Wonko the Sane
I already found a solution for extracting the floppy image from the Ontrack Floppy Creator based programs. You need a resource editor to extract the "compressed" floppy image (compressed with PKWARE Data Compression Library). To extract this compressed floppy image, you can use dynamite:
http://ultimatebootc...c...?f=9&t=2550


For Winimage Self-Extractor based floppies, there might be a workaround (besides extracting the floppy image with 7-zip, which is the best way IMHO):


#5 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,081 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 12 August 2010 - 02:52 PM

I presume that you have no problems in running/installing VFD under Vista. :mellow:

I have no Vista :) handy at the moment to do any meaningful test, but VFD has been reported to work allright under Vista:
http://chitchat.at.i...vmware/vfd.html

Let's try reviewing the procedure (just in case):

  • expand contents of vfd21-080206.zip into a directory
  • double cllick on vfdwin.exe
  • press "Install" button
  • press "Start" button
  • click on Tab "Drive0"
  • press "Change" button
  • assign letter A: (leave checked "persistent/global"-> OK
  • If you have already any floppy image (or any file exactly 1474560 bytes in size, skip to #14)
  • press "Open/Create" button (please notice how the only available option is "RAM")
  • press "Create"
  • press "Save"
  • supply path/filename-> Press "Save"
  • press the "Close" button
  • press "Open/Create" button, supply the path/filename to the saved image (please notice how the only available option is "RAM", but once you have a path in the box you also have "File")
  • choose "File"
  • press "Open/create"

Then try running Western Digital DataLifeGuard floppy creator.

Please report the exact error/behaviour you get.

@Icecube
The memscope.exe is made with Winimage self-extracting engine, thus you can use Winimage to get the internal .IMA.
Unfortunately there is a "cross-bug" between 7-zip and some versions of .imz/Winimage Sfx, so it is not possible to use 7-zip directly. :(

Normally a Winimage self extracting .exe accepts parameters, try running in a command prompt with the /x option.
You will have the option to save the compressed .imz file.
But it doesn't work with memscope :(, the guys who used the Winiomage kit disabled this otherwise useful feature.

Then you need to "repair" the archive before being able to restoring it's contents with 7-zip (or similar compression utility).
This:
http://www.diskinter...com/zip-repair/
is suitable. :mellow:

UPDATE: zip-repair can extract the the image from within MemScope-110.exe
7.zip still has errors, but infozip UNZIP:
http://www.info-zip.org/
works allright to get from the recovered file the MemScope-110.IMA file. :mellow:

The "insert floppy disk/Ignore/Retry" is a nice trick :)

Every day I thank my personal "common sense" for using the 7' 1/2 sticks to NOT touch Vista :unsure:
http://www.msfn.org/...o...25258&st=12
;)

Maybe there is "space" to write a small utility that analyzes and extract these stupid self-extracting floppies....:unsure:

;)
Wonko

#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,081 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 14 August 2010 - 02:13 PM

Smallish update:
Objectfix can (in one pass :mellow:) extract the .IMA from Winimage SFX:
http://www.essential...s/objectfixzip/

It won't work with the Western Digital DataLifeGuard Diagnostics 504f floppy creator though. :mellow:

There is an interesting little tool by Luigi Auriemma:
http://aluigi.altervista.org/
http://aluigi.alterv...org/mytoolz.htm

Offset file unzipper
http://aluigi.alterv...oolz/offzip.zip

a very useful tool to unpack the zip (zlib/gzip/deflate) data contained in any type of file included raw files, packets, zip archives, executables and anything else.
it's needed only to specify the offset where the zip data starts or using the useful -S search options able to find any possible zip block contained in the provided file.
naturally there are also other options for extracting all the zip blocks which have been found or dumping them as in their original compressed form.
it's also possible to choose a windowBits value for scanning both the zlib (RFC1950) and deflate (RFC1951) blocks (for example -z -15 for common zip files and so on).


Posted Image

That although being one of the least user friendly app I have seen in a while :) AND notwithstanding the fact that I didn't (yet :) ) manage to get it working on the stoopid Western Digital thingy :unsure: has potential. :unsure:

:mellow:
Wonko

#7 ady

ady

    Frequent Member

  • Advanced user
  • 118 posts

Posted 14 August 2010 - 07:27 PM

Wonko, thank you for all the tips and help. I really appreciate it.

I've been testing several solutions, both in Vista and in VirtualBox's XPwSP3.

Between my tests, which I want to share with you, and all your previous comments and suggestions, I know this post will not be short. I sincerely apologize for that.

During my tests, in Vista, no success at all. So all the comments I have, at least for now, are relevant to XP as guest in VirtualBox, with Vista as host OS.

To extract this compressed floppy image, you can use dynamite:
http://ultimatebootc...c...?f=9&t=2550


I guess you "googled" that topic or you did some similar search.
I wont waste your time repeating here the reasons why dynamite won't work for me , since I myself :) mentioned them in that same topic at UBCD forums.

For Winimage Self-Extractor based floppies, there might be a workaround (besides extracting the floppy image with 7-zip, which is the best way IMHO):


The "insert floppy disk/Ignore/Retry" is a nice trick


Using 7-zip ultimately was not "the best way". Not even using Winimage. For memscope 1.10, and other programs distributed using Winimage Self-Extractor 8.00 (like "clone maxx"), the "first ignore, then retry" trick worked very well and was the most efficient and direct. I even tested the resulting floppy image with 7-zip "test" function and it was readable.

Although the trick worked well, I'll take a look at zip-repair, info-zip, objectfix, offset mytoolz. If not for this particular topic, they might be useful for other situations. Thank you for the tips about them.


*** FYI,, a little out of topic, about Winimage Self-Extractor ***


I guess that the most updated version of Winimage Self-Extractor may work better than version 8.00, since the last version of Winimage works under Vista:

http://europa.winimage.com/winimage.htm 

New for version 8.10

fixes for Windows Vista compatibility problem.

Note the difference about Vista:

http://europa.winimage.com/download.htm



version 8.0 ... for NT4-x86, 2000, XP, 2003 server, 95/98/Me, along with the WinImage self-extractor.



version 8.1 ...  for NT4-x86, 2000, XP, 2003 server, [b]Vista [/b], 95/98/Me, along with the WinImage self-extractor.

Although:

http://europa.winimage.com/wima_sfx.htm 



The file.exe you create will run under Windows NT-x86, Windows 95/98 and Windows 3.1 with Win32s 1.30c installed.
(Vista not being mentioned)


*** now, returning to our topic ***

It won't work with the Western Digital DataLifeGuard Diagnostics 504f floppy creator though.


I have no Vista handy at the moment to do any meaningful test


Almost all the floppy-creator programs based on Ontrack's Floppy Creator worked under XP. According to Ontrack's website, Vista is not mentioned as being supported.

I can't really understand why they don't work under Vista, even setting the compatibility mode to XP in their properties. But hey, I'm not a programer, just a user trying my best.

*** tests using VFD ***

I presume that you have no problems in running/installing VFD under Vista.


About VFD under Vista, after "install", "start", and "assign letter A: global", I just use it as ram virtual floppy. I only save the image to a file after running the floppy creator program I am testing. That is, after many tests trying to figure out if there is any difference.

So, after testing it, I can say that now I'm not using it exactly as you described using the 16 steps. Maybe you could clarify to me if there is any behavior's difference between "ram" and "file" mode.

Several observations about VFD in "file" mode (as opposed as "ram" mode):

-In my tests, both under Vista and under VirtualBox's XP, the behavior was the same using "ram" mode or "file" mode.

-The only difference I noticed between "ram" and "file" mode is that when starting with an image file, after running any command or program related to the virtual floppy, when I try to close the file VFD states that the file was changed since I opened it, and asks if I want to save it, either with the same - or with a different - file name.
When using "ram" mode, then VFD also notice the changes and asks if I want to save the new virtual floppy, but there is no previous file name.

-When VFD creates a new virtual floppy, the description states it as a "RAW 1474560" floppy. This is not entirely correct. The just-created floppy, either in "ram" mode or "file" mode, is a FAT12 DOS-compatible formatted floppy, even before actually giving the "format" command. So no, the floppy is not in "RAW" format (or unformatted).

-No matter which mode I use, VFD starts the virtual floppy as a FAT12 formatted one.
This could potentially be a problem if the floppy creator program changes the floppy format (to XDF, or MAC's format, or EMT or MIF or DMF...).
Generally speaking, it is not a problem starting with a DOS FAT12 standard format. The problem could arise when VFD has to save it to an image file.

I'm not sure VFD would save it with the appropriate format, or if it always saves it as FAT12. This could be a problem in some cases. (For the programs I tested based on Ontrack Floppy Creator, this is not a problem, but there are other floppy-creator tools that use other formats than FAT12).

Anyone knows the answer to this question?

I would like to know also, for the purposes I am using VFD and ImDisk, if there is any difference between them. I want to know if there is any point to test both, VFD and ImDisk, in each situation. Either way, I hope not only to improve my situation, but to help improve ImDisk.

It seems VFD will not be developed anymore or updated in any way, But this is just an assumption.

*** other tests I made ***

Besides using VirtualBox to test under XP, I tried several ramdisk tools under Vista.

The only one I found with 1440K support was Gavotte's Rramdisk. I also tried Vsuite, Qsoft and Dataram.

I didn't tried Firadisk, nor WinvBlock, since their respective topics in the forum were a little bit "overwhelming" for me. In spite of that, I'm always willing to learn, so maybe with some guidance I'll try them.

I notice several points about ramdisk tools:
-Gavotte's Rramdisk has a 1440K option, but it didn't lead me to exactly 1474560 bytes (unformatted, or 1457664 bytes FAT12). I maybe made some mistake. I will have to test it further and I will report back if I find anything.
-Other ramdisk tools don't support A: (not as floppy nor as hard drive ramdisk), or they don't support such a little ramdisk.
-Many ramdisk tools changed significantly between previous and newer versions, in order to support Vista.
This is one of the reasons that makes me wonder if the problem is on the virtual floppy tool I use (VFD/ImDisk/other ramdisk tool), the floppy creator programs (based on Ontrack Floppy Creator, or Winimage Self-Extractor for example), or some particular configuration (hardware or software) in my particular system.

BTW, I tried running the floppy creators with command-line parameters like "-?", "/?", "-help", "/help", but they just run without any difference.

I wonder what is that Towodo self-extractor does different from the other two floppy creators that makes it work under Vista.

I'll keep testing and searching for answers, and specially for solutions. Please keep advising. Any help is very much appreciated.

Thank you in advance.

#8 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1,045 posts
  •  
    Belgium

Posted 14 August 2010 - 08:17 PM

WinImage SFX zips the floppy and adds it after the SFX executable. The problem is that WinImage SFX generates a invalid zip file ("Relative offset of local file header" field (offset 42) of the "ZIP central directory file header" is wrong).

I wrote a feature request to the 7-zip developer to support this broken WinImage format:
http://sourceforge.n...amp;atid=364481

I guess you "googled" that topic or you did some similar search.

Look at the forum name of the person who helped you :) .

I wont waste your time repeating here the reasons why dynamite won't work for me , since I myself mentioned them in that same topic at UBCD forums

There is a link to a compiled version.

You can try FileDisk: http://www.acc.umu.se/~bosse/
Or you can install WinImage (which will ask if you want to install FileDisk).

#9 ady

ady

    Frequent Member

  • Advanced user
  • 118 posts

Posted 14 August 2010 - 10:53 PM

Look at the forum name of the person who helped you


For some reason I saw it reversed, as if the author of that post was Wonko and he was "talking" ( "at" simbol ) to "IceCube". Possibly after writing such long posts. :) My mistake.

You can try FileDisk: http://www.acc.umu.se/~bosse/
Or you can install WinImage (which will ask if you want to install FileDisk).


I want to understand correctly. Are you suggesting using Filedisk as a "Dynamite for windows"? Or as a general solution to extract all those images from all those floppy-extractors? Or maybe Filedisk can replace VFD or ImDisk?

Can FileDisk be used as a virtual floppy in the sense of VFD? Or it needs an already-existent image file to mount it?

Thank you in advance.

#10 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1,045 posts
  •  
    Belgium

Posted 14 August 2010 - 11:12 PM

Or maybe Filedisk can replace VFD or ImDisk?

AFAI can tell Filedisk is similar to VFD and ImDisk.

Can FileDisk be used as a virtual floppy in the sense of VFD? Or it needs an already-existent image file to mount it?

Yes it can.
Some examples:
http://www.acc.umu.s...e/filedisk.html

It can create images from scratch.

#11 ady

ady

    Frequent Member

  • Advanced user
  • 118 posts

Posted 17 August 2010 - 11:56 AM

[quote name='Icecube' post='106861' date='Aug 14 2010, 11:12 PM']AFAI can tell Filedisk is similar to VFD and ImDisk.
It can create images from scratch.[/quote]

I have been testing for several days since my last post, and I'm still making tests, but I wanted to give some updates about them, and ask for more help if anyone is so kind.

Apparently, Filedisk complements Winimage. I couldn't find any reference about Filedisk creating a new image file by itself, but I tried it anyway.

Since I have so many images to build, and I'm testing other methods besides Filedisk, I dedicated an hour or so to test Filedisk in Vista. I wasn't succesfull in regards to what I wanted to accomplish, so I move on to other tools and methods.

About using Winimage, maybe it is a partial solution, at least for some of the floppy-creator formats. But Winimage is shareware, and I'd rather use freeware tools, specially when I am not going to deal with this situation in an everyday basis, but an "almost one time" basis. I will try Winimage if necessary, but just for the trial period.

I'm working under Vista now, as I wanted from the start (as opposed to working with VirtualBox and XP as guest) to extract all the images somehow, and then to test them using VFD/ImDisk and other additional tools under Vista.

Most of those floppy images are boot floppy tools. So once I get the IMG file, I still need some method to test it. Is there any method I can test booting the image floppy?

I'm trying a DOS guest in VirtualBox with the floppy image as first boot device, but 2 problems arised:

1- when the boot process loads a mouse driver (cute mouse, they use carldera/freedos dos), in most cases the VirtualBox boot process stalls.

2- when the video resolution in VirtualBox changes, from the text mode (DOS boot process, config.sys and autoexec.bat or their caldera/freedos equivalent) to some graphic mode, the display is not clear, useless. The graphic mode shows the program not centered, with black vertical lines interrupting/interleaving the GUI of the program, and is impossible for me to read anything displayed on the screen.

In both cases, the only thing I can do is to close the VM.

When the program is based on text mode, (like for example ibm disk manager 9.57, or seagate disk manager 9.56a) the VM passes the boot procces and gets to the program itself, including the ability to use the mouse (still, text mode).

I just want to be clear: the loaded program after the boot procces is not a command-line tool, but the display is configured to text mode. The problem described ( #2 ) shows up when the loaded program is configured to be used in graphic mode.

Examples of the tools in graphic mode are:
-Samsung disk manager 10.42
-Seagate Disk Wizard Standard Edition 10.45.06 (2 floppies)

Maybe Qemu is a better option to boot these DOS-Based floppy images, but I don't know anything about Qemu, and Wonko previously said:

[quote]A known workaround is in any case a Qemu VM, but it may be overkill.[/cuote]

and since I'm already learning, testing, trying many other tools, I don't know if rather to start with Qemu, or to try to make it work in any other way.

I was reading about DosBox and Bosch, but until now it is not so clear to me how to boot a floppy image with them. Maybe they are not the correct tools for what I need; I don't know. I'm stiil reading and learning.

Since I'm also new to VirtualBox, but I am already trying with it, is there anything I could try to configure "something" about it that is out of the settings and preferences right there in the VirtualBox GUI?

Any clue about what the problem is?

I really appreciate any help or tips. I'll post back when I have any news.

Thank you in advance.

#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,081 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 17 August 2010 - 12:26 PM

Let's not make it more complex (or too much simple) than needed. :(

You DO NOT need Winimage for getting the image inside Winimage sfx files, a viable solution (freeware) has ALREADY been given:
http://www.essential...s/objectfixzip/

We are looking in some ways to do the same on non-Winimage sfx - but it will take time, I am currently looking into the DlgDiagv504f.exe, but don't expect anything any soon. :(

To test the boot floppy you need to boot them. :cheers:

A Qemu VM is the easiest solution and also one of the more "real Hardware like" solution, BUT these are mostly "special" floppies that may not work if not on real hardware.

Use Qemu manager, which behaves like most other GUI VM's:
http://www.davereyn.co.uk/download.htm

VirtualBox is the LEAST suitable VM around, as it has some peculiarities that often prevents it from working (as you have already found out).

The other "good" VM is VMware, that sometimes can work with something that Qemu cannot manage.

Forget about Virtual PC, unless you have a very old release (by Connectix, before MS bought them), later version (2007) is known to have a number of incompatibilities expecially when booting.

In other words Virtual Machines, in this order:
  • Qemu
  • VMware
  • Virtual PC
  • VirtualBox
can be at the most a pre-test, not exhaustive, the only good thing is that if some of these floppy images do work in Qemu (or in VMware) are VERY likely (like 99%) to boot properly on real hardware, but you will NEVER know.
Compare with:
http://www.boot-land...showtopic=12052

Both IMDISK and filedisk, as said, work at a "higher" level than other drivers.
The fact that VFD also doesn't work means that the stoopid Ontrack based floppies look for a "lower" level.
Firadisk and WinVblock work at a "lower" level, so are worth a try.

Forget about DosBox and Boch (not Bosch) for the moment, they won't work for testing properly those floppies (BTW Qemu uses Boch BIOS, only it has a wider compatibility and - using Qemu Manager - it is much easier to work with).

Please, post a complete list (including links where available) of all the sfx's you are working with, maybe it will be easier to find out how they are compressed by doing comparisons....

Also it is not clear if there is an absolute incompatibility with VFD (or filedisk or IMDISK) virtual drives and the Ontrack sfx under Vista :) ONLY or if these same virtual disk drivers do work with it under a 2K or XP.
Have you made tests in this direction? :(

:)
Wonko

P.S.: Just tested the DlgDiagv504f.exe in XP with IMDISK, and it works nicely.
The problem must be in Vista :smiling9: maybe you need to run it elevated, with UAC off or whatever (driversigning policy off)? :cheers:

#13 ady

ady

    Frequent Member

  • Advanced user
  • 118 posts

Posted 17 August 2010 - 03:03 PM

Let's not make it more complex (or too much simple) than needed. :cheers:

You DO NOT need Winimage for getting the image inside Winimage sfx files, a viable solution (freeware) has ALREADY been given:
http://www.essential...s/objectfixzip/


As I said, I'm still testing all the options and tips. About Winimage and Filedisk, I was just answering to the previous Icecube's post, while he suggested those tools.

About objectfixzip, I still have to try it. One previously suggested tool, ziprepair, was not useful for the floppy creators. The floppy creators are .exe, and they contain some sort of floppy image (bin, ima, img, imz...). Ziprepair only accepts zip files.

Another tool I tried is IzArc, which also has a repair tool. Again, I was not successful.

Either way, as I already stated, the most direct "solution" for Winimage Self-Extractor under Vista is the "ignore, then retry" trick. The only "problem" is that when the user ignores an error, there is no way to really know if the result is 100% acceptable, or if maybe something could be wrong and he won't know about it unless something specific triggers a problem related to that first ignored error.

Also it is not clear if there is an absolute incompatibility with VFD (or filedisk or IMDISK) virtual drives and the Ontrack sfx under Vista :) ONLY or if these same virtual disk drivers do work with it under a 2K or XP.
Have you made tests in this direction?


Look at (my) first post in this same topic for details. Using VirtualBox, Vista as host, XPwSP3 as guest, I used VFD to run most of the floppy creators successfully. Still, I wanted to get some method to run them under Vista with some virtual floppy, and that's how I got to try ImDisk under Vista.

We are looking in some ways to do the same on non-Winimage sfx - but it will take time, I am currently looking into the DlgDiagv504f.exe, but don't expect anything any soon. :(


That is what I wanted. My initial goal was to be able to extract floppy images, something similar to what happens with zip's (or cab's, or z-zip), specially since current PC's don't include floppy drives anymore.

Since I wasn't able to find any tool, I changed my goal to find a virtual floppy, so to run those floppy-creator programs, and then save the images. I was expecting to use VFD and work like 10 minutes for each floppy image and several MB of hard disk space. Failing under Vista, I invest time, several GB's of hard disk space, learning about VM, installing and transferring programs to the VM...

Now, under Vista, I am still testing, comparing results with the floppy images I got from VirtualBox's XP, checking for errors, testing the content, and so on. That's why I didn't report my results yet. I've been using hash checks, folder/directory comparison, byte-by-byte comparison, extracting with several/different tools (z-zip, Izarc, Winimage, Uniextract)...

For most of the floppy creator programs based on Ontrack Floppy Creator, I already used tips I received from you and from Icecube to manually extract the floppy images under Vista, and I am checking those as already described.

Even when I didn't finished checking, (and please take into account that I was not successful in each and every floppy) in general, the following is the method I used under Vista for Ontrack-based floppy creators:

1- ResourceHacker -> RCData -> extract to bin.

You can use any other resource extractor compatible with Vista. The important thing at this point is to find the correct part of the resources that represents the 1440K floppy image, and hope that the resulting *.bin will be correct in every aspect.



2- dynamite bin -> convert/extract to img.

This one was tricky for me. First, Icecube find a dynamite compiled version compatible with windows (he posted it before, in this same topic). The downloaded file was not so easy to expand under Vista, but finally I got dynamite and cygwin1.dll expanded and I put both in the same folder.



3- test img with checksum apps, isobuster, z-zip and other utilities. Specially, I compared all the results with the equivalent floppy image file I got from VirtualBox's XP.

The one thing I wasn't able to compare was the floppy boot sectors, not because of not having a "ViewSector" tool, but because I have no knowledge about what each HEX number and position represents and what to look for. If I really knew about this, I would also compare those floppy images in this regard.

Again, keep in mind that not every Ontrack floppy extractor worked under XP, and not everyone was successfully extracted by this method under Vista. The good thing is that I was successful extracting most of them.

The method is not so simple, direct and low time-consuming as I was hoping in my initial goal; but comparing to downloading and installing VirtualBox, installing XP... The time and resources are much less demanding. So the next time I need to get an image from an Ontrack Floppy Extractor executable, I will know what to try first.

A tool to just extract those images would be the best. It would fulfill my initial goal.

In any case, no matter what method I used, I must test those images, at least in some virtual machine or something similar. The test must get me to boot the floppy image and start the program inside it. For disk managers, the functionality of the program won't be able to be tested, but at least I must get to see that the program is able to run. This is also applicable to all the floppy creators, not only the ones based on Ontrack.

To test the boot floppy you need to boot them. :smiling9:

A Qemu VM is the easiest solution and also one of the more "real Hardware like" solution, BUT these are mostly "special" floppies that may not work if not on real hardware.


That somehow contradicts what you stated before about Qemu in my situation, but I'm willing to try it since VirtualBox failed (with the little knowledge I have about VirtualBox, so maybe there is something I could do to make it work, but right now I don't know what that would be).

Use Qemu manager, which behaves like most other GUI VM's:
http://www.davereyn.co.uk/download.htm

...

In other words Virtual Machines, in this order:

  • Qemu
  • VMware
  • Virtual PC
  • VirtualBox
can be at the most a pre-test, not exhaustive, the only good thing is that if some of these floppy images do work in Qemu (or in VMware) are VERY likely (like 99%) to boot properly on real hardware, but you will NEVER know.


In VirtualBox, the ones already worked (boot and the program stars running) are:

-Western Digital Data LifeGuard Tools 11.2 for DOS
-IBM Disk Manager 9.57
-Seagate Disk Manager 9.56a

It is possible that others also would work in VirtualBox, but as I said, I didn't finished all the previous tests to get to this point with each and every tool.

I will use those images that already worked so to test Qemu, and I will continue with the rest of the floppies from that point.

Both IMDISK and filedisk, as said, work at a "higher" level than other drivers.
The fact that VFD also doesn't work means that the stoopid Ontrack based floppies look for a "lower" level.
Firadisk and WinVblock work at a "lower" level, so are worth a try.


As I explained before, while reading the respective topics about FiraDisk and WinVblock both seemed to me too complicated for my knowledge's level. I also said I am willing to try and learn, but it seems I have really a lot to learn before I could use them.

Forget about DosBox and Boch (not Bosch) for the moment, they won't work for testing properly those floppies (BTW Qemu uses Boch BIOS, only it has a wider compatibility and - using Qemu Manager - it is much easier to work with).


Ok, done, forgotten for the moment. :)

Please, post a complete list (including links where available) of all the sfx's you are working with, maybe it will be easier to find out how they are compressed by doing comparisons....


For starts, there is part of the list in the (my) first post of this same topic. The problem is that I have several of those tools since... Well, for a very long time. For the most part, the Ontrack Disk Managers and other tools alike are for old pc's troubleshooting, and I am the one who helps in my family with those issues.

I will try my best to make a list of possible links where to download those old tools from.

In the meantime, thank you very much for the help.

PS: *** additional info a little bit off-topic, about the ontrack tools ***

For those that maybe don't know, I wouldn't recommend using those tools for current pc's, since the format/partitioning rules are slowly changing, and modern OS's /BIOS's don't need the disk drive overlay (DDO) part of those utilities.

For modern pc's, the most useful part of those utilities is the hard drive testing, but only if the tool is enough updated to support not only modern hard drives, but also current partitioning rules.

#14 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,081 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 17 August 2010 - 04:03 PM

About objectfixzip, I still have to try it. One previously suggested tool, ziprepair, was not useful for the floppy creators. The floppy creators are .exe, and they contain some sort of floppy image (bin, ima, img, imz...). Ziprepair only accepts zip files.

Another tool I tried is IzArc, which also has a repair tool. Again, I was not successful.

Really? :cheers:

Try typing *.* in the filebox of Diskinternals ziprepair and press [ENTER].....:(

There are approximately 7,387 similar zip utilities :cheers:, I found a few of them working (including Diskinternals one :)) that need anyway two steps and one (the "objectfix" thingy) that does it in one step only and you don't try it? :(

I had a look at the Ontrack thingy, the reason why no utility finds any zipped file inside it is because there is NONE.

Crazy as it might seem (and actually is) the stoopid .exe's seemingly embed chunks of bytes (variable between 1 and 7 chunks of 9,216 bytes each) somehow compressed or stored in 16,384 bytes segments (it does use PKWARE library, though).

The creation of the diskette goes like this (simplified):
  • access floppy
  • Write directly 512 bytes to it at offset 716,288
  • Write directly 512 bytes to it at offset 1,474,048
  • Read a chunk of 16,384 bytes from the .exe
  • (uncompress/unencrypt it)
  • Write directly n chunks of 9,216 bytes to the floppy
  • Loop to 4 until end

The direct write is probably what creates problems under Vista :(.

Dynamite (VERY nice find Icecube :smiling9: ) uses 1,024 bytes chunks, and the result (with both dm_creator.exe and the DlgDiagv504f.exe) is larger than expected 1,486,200 or 1,486,437 bytes, but the file is padded with F6, which is allright, one can strip the first 1474560 bytes :(


That somehow contradicts what you stated before about Qemu in my situation, but I'm willing to try it since VirtualBox failed (with the little knowledge I have about VirtualBox, so maybe there is something I could do to make it work, but right now I don't know what that would be).

It doesn't contradict ANYTHING, setting up a VM and an OS on it just to uncompress a few stoopid floppies because you have a "main" stoopid OS, Vista :) that sucks, remains a bit overkill...
...testing the floppy images ince extracted is ANOTHER thing....

:cheers:
Wonko

#15 ady

ady

    Frequent Member

  • Advanced user
  • 118 posts

Posted 17 August 2010 - 06:27 PM

Really? :cheers:

Try typing *.* in the filebox of Diskinternals ziprepair and press [ENTER].....:(

There are approximately 7,387 similar zip utilities :(, I found a few of them working (including Diskinternals one :cheers:) that need anyway two steps and one (the "objectfix" thingy) that does it in one step only and you don't try it? :(


As I said, I didn't tried "objectix" because I used the "ignore first, then retry" trick. I will try it anyway.

I had a look at the Ontrack thingy, the reason why no utility finds any zipped file inside it is because there is NONE.


I didn't expect exactly a zip file, but an img in some way. I really appreciate the time you (and Icecube) have invested in helping me with this.

Crazy as it might seem (and actually is) the stoopid .exe's seemingly embed chunks of bytes (variable between 1 and 7 chunks of 9,216 bytes each) somehow compressed or stored in 16,384 bytes segments (it does use PKWARE library, though).

The creation of the diskette goes like this (simplified):

  • access floppy
  • Write directly 512 bytes to it at offset 716,288
  • Write directly 512 bytes to it at offset 1,474,048
  • Read a chunk of 16,384 bytes from the .exe
  • (uncompress/unencrypt it)
  • Write directly n chunks of 9,216 bytes to the floppy
  • Loop to 4 until end

The direct write is probably what creates problems under Vista :cheers:.

Dynamite (VERY nice find Icecube :( ) uses 1,024 bytes chunks, and the result (with both dm_creator.exe and the DlgDiagv504f.exe) is larger than expected 1,486,200 or 1,486,437 bytes, but the file is padded with F6, which is allright, one can strip the first 1474560 bytes :)


As I said, I used Resource Hacker, then Dynamite, to get to an img file. Then I started testing/comparing, since I had no way to know if those img files were ok. Using this method, not all the bin files were bigger than the final img file.

I'm a simple user, not a programer, so I apologize if this question sounds silly: what do you mean with "padded with F6"?

Can you tell me if the method I used (resource hacker, then dynamite) is correct?
Is it the best method I could achive under Vista for this type of files?

It doesn't contradict ANYTHING, setting up a VM and an OS on it just to uncompress a few stoopid floppies because you have a "main" stoopid OS, Vista :) that sucks, remains a bit overkill...
...testing the floppy images ince extracted is ANOTHER thing....


Ok, I understand what you mean. As I said, I'll give it a try. I'm not being lazy and I'm willing to learn. The tests I already made, before getting to this point, really took many hours, but I want to be thorough.

I didn't explain each and every test I made. For example, you asked about running the programs as administrator, or compatibility mode. I explained part of them in my first post. I tested every combination I thought about:

-run the floppy creator as adminstrator
-run the floppy creator in compatibility mode
-run VFD as adminstrator
-run VFD in compatibility mode
-run ImDisk as adminstrator
-run ImDisk in compatibility mode
-UAC on
-UAC off
-ImDisk service automatically / manually loaded
-ImDisk device automatically / manually loaded
-run under Vista
-run under VirtualBox's XP with floppy emulation
-run under VirtualBox's XP without floppy emulation, with VFD
-run under VirtualBox's XP without floppy emulation, with ImDisk
-instead VFD/ImDisk, I tried Gavotte's Ramdisk, Romex VSuite, Dataram Ramdisk, Qsoft Ramdisk

Additionally, I read and learned about those programs a lot and combined different configurations, and tested the results with checksums, z-zip, isobuster, IZarc, Uniextract, Winimage and probably other tools I don't remember right now.

After all those trials-and-errors, I came back here to report back and keep trying and testing every tip and help, you (Wonko) and Icecube gave me, for which I am very grateful.

So, please forgive me if I didn't get to test all the tools, or if I didn't realize that a tool actually supports some method I failed to see or to use correctly. I intend to check them all.

I apologize for the long posts, which evidently cause that you (or anyone reading this long topic) don't remember all the tests and steps I already reported, and so we maybe went in circles.

About links to tools based on Ontrack Floppy Extractor, this link may be usefull:

http://www.oldversio.....0Drive Utils/

I can't actually be accountable for the contents of the site, since I'm not the publisher, but it seems to be ok.

At that link, there are several DOS floppy versions of the tools originally distributed by hard disk manufacturers, most of them based on Ontrack Floppy Extractor. Most hard disk manufacturers are not providing links to download their old tools anymore.

For example:
http://www.oldversio..._DOS_Floppy.rar

contains the floppy creator for the 2 disks of Seagate DiscWizard 10.45.06 for DOS.

At the same site you can find others, just looking at the DOS floppy titles. Not all of them are floppy creators, but most of them are.

Other possible sites are the ones containing storage drivers, like driverguide, mylostdrivers, and opendrivers, just as examples. Look for storage drivers at these sites.

Also, www.archive.org may be useful. I didn't check it today to look for the links you requested, but I know there should be at least one or two of the tools there.

One additional example for an Ontrack-based program is Maxtor 4.23 at:
http://www.tacktech....tor/PwrMxEn.exe

I hope those links help to find a direct and simple method to extract the image files, specially under Vista and above. I'll be learning and testing Qemu, and I'll report the results back.

I hope you could find some time to answer the questions I posted.

Thank you in advance.

#16 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1,045 posts
  •  
    Belgium

Posted 17 August 2010 - 07:39 PM

On linux you can "repair" the WinImage SFX files with the "zip" utility:
zip -FF MemScope-110.exe --out MemScope-110.img.zip
The "-FF" parameter will remove the non zip part at the beginning of the file (the WinImage SFX extractor) and it will fix the embedded zip file itself (it is corrupt, and therefore 7-zip won't extract it):
http://sourceforge.n...;group_id=14481

Now you can just extract the floppy image from the zip file.

I didn't expect exactly a zip file, but an img in some way. I really appreciate the time you (and Icecube) have invested in helping me with this.

I already gave you the solution more than one week ago.

I hope those links help to find a direct and simple method to extract the image files, specially under Vista and above

The "rescource hacker - dynamite" approach will be the easiest (and fastest) way.
Unless of course someone writes a tool which automatically can extract the right rescource data out of the Ontrack Floppy Creator based programs and uses the dynamite library to decompress the image file.

#17 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,081 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 August 2010 - 09:11 AM

I'm a simple user, not a programer, so I apologize if this question sounds silly: what do you mean with "padded with F6"?


Size of certain elements is "costrained".

A "normal" 3.5" floppy has exactly 2x80x18 sectors= 2,880 sectors, each 512 bytes, i.e. 2,880x512=1,474,560 bytes in size.

Traditionally (cannot remember the reason, probably some "legacy" remainder of even older floppy types or production machines) the "empty" sectors - before writing anything to them - were filled with the hex value "F6", just like empty sectors on hard disks are filled with digital 00's.

So, when you take an image a floppy, you have two "strategies" available:
  • copy only the "used sectors"
  • copy all the 2,880 sectors
the "right one", the one that actually is an image, is the second, but the first one is allright as well, since on a real floppy the "final" part that you do not overwrite when restoring the image will anyway be not used, or will already be F6's.

A third "strategy" for this kind of image is "take the relevant initial sectors only, then write F6's until you reach 1,474,560", this is what is normally called "padding".

If the original floppy was "rightfully" prepared, it's last bytes will always be F6's (unless you managed to fill them with EXACTLY 1,474,560 bytes of data).

To see an example of a badly prepared floppy (with deleted files, etc., etc.) by the good MS guys, check this:
http://www.911cd.net...showtopic=16745

What it seems from my brief experiments with those two Ontrack based SFX's is that Dynamite somehow fails to calculate the number of trailing F6's and add some of them too much, but as said it is not a problem, as we can "trim" the image to the right size.

:(
Wonko

#18 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,081 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 August 2010 - 11:19 PM

OK, attached is a small, dirty (but not so quick :)) batch file, as usual with a number of dependencies.

::UnSfxima.cmd

::Small batch by jaclaz to Uncompress floppy images from commonly used

::self-extracting file formats

::Release ALPHA 0.01 17th August 2010

:: Dependencies:



::gsar

::http://home.online.no/~tjaberg/

::http://home.online.no/~tjaberg/gsar121.zip



::fsz (part of DSFOK toolkit):

::http://members.ozemail.com.au/~nulifetv/freezip/freeware/

::http://members.ozemail.com.au/~nulifetv/freezip/freeware/dsfok.zip



::offzip:

::http://aluigi.altervista.org/mytoolz.htm

::http://aluigi.altervista.org/mytoolz/offzip.zip



::dynamite:

::http://ultimatebootcd.com/forums/viewtopic.php?f=9&t=2550

::http://pagesperso-orange.fr/jotd/software/bin/bitmap_bros_pc_unpack.zip

It works with Winimage Sfx's and with some Ontrack ones.
Tested successfully:
  • DlgDiagv504f.exe (Ontrack)
  • dm_creator.exe (Ontrack)
  • MemScope-110.exe (Winimage)
  • SG_DW_104506_DOS_Floppy.exe (Ontrack) <-it contains TWO floppy images

Failed:
  • FJ_DG_945_DOS_Floppy.exe (Ontrack) <- it is an older format, 16 bit app, Borland compiled, seems like not using ZIP compression :smiling9:

@ady
Now the game is in your hands, ideally you should test the images you use/have and post a report BOTH for those that work and for those that DO NOT :(, for these latter ALSO post a link to where they can be found (when available), please no more "try looking in this directory:", I am not really going to test n images, I'm only interested in those that DO NOT work, in order to (hopefully) better the batch and make it work with these latter ones also.

:D
Wonko

Attached Files



#19 ady

ady

    Frequent Member

  • Advanced user
  • 118 posts

Posted 19 August 2010 - 03:07 PM

OK, attached is a small, dirty (but not so quick :)) batch file, as usual with a number of dependencies.


I'm going to test it and compare the results with the "resources hacker, then dynamite " method.

I gues I should extract all those dependences in the same folder, together with the attached batch?

It works with Winimage Sfx's and with some Ontrack ones.
Tested successfully:

  • DlgDiagv504f.exe (Ontrack)
  • dm_creator.exe (Ontrack)
  • MemScope-110.exe (Winimage)
  • SG_DW_104506_DOS_Floppy.exe (Ontrack) <-it contains TWO floppy images

Failed:
  • FJ_DG_945_DOS_Floppy.exe (Ontrack) <- it is an older format, 16 bit app, Borland compiled, seems like not using ZIP compression :(


The fujitsu floppy is also from Ontrack, but it seems to be based on something they called ADVDisk for Windows, instead of Ontrack Floppy Extractor, and it seems to be compatible with Windows 9x/nt/2k, but there is no mention of xp and above. I've been having problems with this one with almost all my previous tests.

@ady
Now the game is in your hands, ideally you should test the images you use/have and post a report BOTH for those that work and for those that DO NOT :(, for these latter ALSO post a link to where they can be found (when available), please no more "try looking in this directory:", I am not really going to test n images, I'm only interested in those that DO NOT work, in order to (hopefully) better the batch and make it work with these latter ones also.


I'll do that. Thank you for the batch file.

About the "original" images being "righfully" prepared, I can already say not all of them are. I tested them with Isobuster, and found "deleted files" and "fragmented" files. So it seems that some of the original floppies (the ones used to make the floppy extractors from) were not so "clean", and actually were already-been-used floppies.

This means the "F6" you explained is not only located at the final part of the image. While testing the batch, I will double-check those floppies.

In the meantime, I have a question about the tests I should do to say "this one works, this one doesn't?

Each time I get an image file, the checksum is different, even if the files and folders inside are the same.

So, Is it enough to extract the image file content and compare it to the content of previously-obtaind images (from VirtualBox XP)?
Do I need any extra test to say "this image is working"? What about boot blocks and similar sectors that cannot be "translated" as files?


About testing the floppies booting in Qemu, I managed to make it work by changing the virtual video card.

Now, how can I test a set of 2 consecutive floppies in Qemu (i.e. SG_DW_104506 you tested with the batch)? By a "set", I mean that I boot the VM with the first one, and then the boot process requests to change the floppy for the next, so to continue with it. I know how to do this in VirtualBox. I couldn't find how to change the floppy while running the VM in Qemu.

I hope you can answer to these questions (the ones with bigger font size) so I can test the floppies and report back.

Thank you in advance.

#20 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,081 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 August 2010 - 05:14 PM

I gues I should extract all those dependences in the same folder, together with the attached batch?

Yes :(, that's the preferred (and suggested) method ( though ANYWHERE on your disk(s) as long as the path is in your PATH variable, should also work).
Please take note that I rarely (and have definitely NOT done it in this occasion) write batches foreseeing the use of it with paths with SPACES in the name, so, KISS approach, use a directory, somethng like:
C:\unsfxima\
and put in it the needed files and the "source" self-extracting images.

In the meantime, I have a question about the tests I should do to say "this one works, this one doesn't?

No, if in the \Expanded directory you get one (or more) files(s) with the same name of the sfx, but with .ima extension (or with a number added to the name) exactly 1,474,560 bytes in size, it should mean that decompression worked.


Each time I get an image file, the checksum is different, even if the files and folders inside are the same.

Hmm, that's strange, but we may think about it later, I presume there is something not "kosher" in your hashing method.

So, Is it enough to extract the image file content and compare it to the content of previously-obtaind images (from VirtualBox XP)?
Do I need any extra test to say "this image is working"? What about boot blocks and similar sectors that cannot be "translated" as files?

No, I think that is more than needed.

About testing the floppies booting in Qemu, I managed to make it work by changing the virtual video card.

Good. :)

Now, how can I test a set of 2 consecutive floppies in Qemu (i.e. SG_DW_104506 you tested with the batch)? By a "set", I mean that I boot the VM with the first one, and then the boot process requests to change the floppy for the next, so to continue with it. I know how to do this in VirtualBox. I couldn't find how to change the floppy while running the VM in Qemu.

Are you using Qemu Manager 7, aren't you? :(
Simply eject "floppy disk" and "load" the other image. (second icon from the left in lower set of icons at the top - the one that looks a lot like a blue floppy disk :cheers: vertically standing on a floppy disk drive)


:cheers:
Wonko

#21 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1,045 posts
  •  
    Belgium

Posted 19 August 2010 - 09:43 PM

I partly figured out the FJ_DG_945_DOS_Floppy.exe executable.

Hypothesis (not actually tried to run the tool):
I think it needs a formatted floppy. It will copy the boot sector to the floppy and afterwards or before that event, it copies the needed files to the formatted floppy.
I don't think the full image (even compressed is available in the executable).

I found a boot sector at offset 442048 in the executable:
00042880  53 5a 44 44 88 f0 27 33  41 65 20 7a 00 00 ff 4d  |SZDD..&#39;3Ae z...M|00042890  5a 50 00 02 00 00 00 ff  04 00 0f 00 ff ff 00 00  |ZP..............|000428a0  39 b8 f5 f0 01 01 40 00  1a 01 04 11 0d fe 1d 08  |9.....@.........|000428b0  01 00 00 ba 10 00 0e ff  1f b4 09 cd 21 b8 01 4c  |............!..L|000428c0  ff cd 21 90 90 54 68 69  73 ff 20 70 72 6f 67 72  |..!..This. progr|000428d0  61 6d ff 20 6d 75 73 74  20 62 65 ff 20 72 75 6e  |am. must be. run|000428e0  20 75 6e 64 ff 65 72 20  57 69 6e 33 32 0f 0d 0a  | und.er Win32...|--00047100  53 5a 44 44 88 f0 27 33  41 65 00 b6 03 00 ff 4d  |SZDD..&#39;3Ae.....M|00047110  5a 50 00 02 00 00 00 ff  04 00 0f 00 ff ff 00 00  |ZP..............|00047120  89 b8 f5 f0 01 01 40 01  04 0f 0d 1c 09 90 fe f5  |......@.........|00047130  f0 ba 10 00 0e 1f b4 09  ff cd 21 b8 01 4c cd 21  |..........!..L.!|00047140  90 ff 90 54 68 69 73 20  70 72 ff 6f 67 72 61 6d  |...This pr.ogram|00047150  20 6d 75 ff 73 74 20 62  65 20 72 75 ff 6e 20 75  | mu.st be ru.n u|00047160  6e 64 65 72 20 ff 4d 69  63 72 6f 73 6f 66 ff 74  |nder .Microsof.t|--00064740  53 5a 44 44 88 f0 27 33  41 70 65 55 00 00 ff 3f  |SZDD..&#39;3ApeU...?|00064750  5f 03 00 b7 00 00 00 7d  ff f8 f0 65 55 00 00 a7  |_......}...eU...|00064760  f5 f0 fd 9e f5 f0 00 6c  03 15 00 01 bf 00 e7 05  |.......l........|00064770  e9 33 00 0c 00 0f ff 00  43 44 20 55 70 64 61 ff  |.3......CD Upda.|00064780  74 65 20 48 65 6c 70 00  37 03 00 04 05 01 00 02  |te Help.7.......|00064790  0c 00 29 00 ff 10 00 42  72 6f 77 73 65 ff 42 75  |..)....Browse.Bu|000647a0  74 74 6f 6e 73 28 ff 29  00 06 00 5a 00 87 00 ff  |ttons(.)...Z....|--00067080  53 5a 44 44 88 f0 27 33  41 00 00 6a 00 00 ff eb  |SZDD..&#39;3A..j....|00067090  0b 90 4f 4e 54 52 41 ff  43 4b 20 01 01 2b c0 8e  |..ONTRA.CK ..+..|000670a0  ff d8 8e c0 be 00 7c bf  00 ff 7e b9 00 01 fc f3  |......|...~.....|000670b0  a5 e9 ff 00 02 90 90 be  00 06 81 ff 7c 02 be 01  |............|...|000670c0  73 09 03 74 ff 02 81 3c  aa 55 74 11 b8 ff 35 02  |s..t...<.Ut...5.|000670d0  bb 00 80 b9 0b 00 df ba  80 00 cd 13 f0 f0 bf 00  |................|000670e0  ff 80 b5 35 b1 0b e8 6c  00 ff 73 03 e9 e3 00 be  |...5...l..s.....|--0006c0c0  53 5a 44 44 88 f0 27 33  41 65 80 02 0f 00 ff 4d  |SZDD..&#39;3Ae.....M|0006c0d0  5a 50 00 02 00 00 00 ff  04 00 0f 00 ff ff 00 00  |ZP..............|0006c0e0  89 b8 f5 f0 01 01 40 01  04 0f 0d 1c 09 90 fe f5  |......@.........|0006c0f0  f0 ba 10 00 0e 1f b4 09  ff cd 21 b8 01 4c cd 21  |..........!..L.!|0006c100  90 ff 90 54 68 69 73 20  70 72 ff 6f 67 72 61 6d  |...This pr.ogram|0006c110  20 6d 75 ff 73 74 20 62  65 20 72 75 ff 6e 20 75  | mu.st be ru.n u|0006c120  6e 64 65 72 20 ff 4d 69  63 72 6f 73 6f 66 ff 74  |nder .Microsof.t|--000cbd00  53 5a 44 44 88 f0 27 33  41 70 2c 74 02 00 ff 3f  |SZDD..&#39;3Ap,t...?|000cbd10  5f 03 00 ff 48 00 00 7d  ff f8 f0 2c 74 02 00 ef  |_...H..}...,t...|000cbd20  f5 f0 9d e6 f5 f0 00 42  4d 04 02 06 00 76 fa 06  |.......BM....v..|000cbd30  00 28 06 00 e6 01 00 00  4c 2e 06 00 01 00 04 0d  |.(......L.......|000cbd40  02 70 0c 04 0d 01 e9 10  34 04 0d 03 80 43 02 00  |.p......4....C..|000cbd50  80 80 70 47 03 52 01 45  01 4c 00 c0 c0 c0 06 00  |..pG.R.E.L......|000cbd60  81 ff 63 02 f7 f0 67 03  72 01 65 01 6c 00 44 00  |..c...g.r.e.l.D.|--00102480  53 5a 44 44 88 f0 27 33  41 00 13 90 03 00 ff 20  |SZDD..&#39;3A...... |00102490  96 05 0f 9d 28 13 e3 ff  14 7f 7f 43 2c 67 17 b0  |....(......C,g..|001024a0  ff 09 d9 7c ef ec 54 61  ad ff 10 ec b0 99 17 3e  |...|..Ta.......>|001024b0  58 64 ff 46 59 c7 97 b0  09 23 05 ff 81 0f 21 1b  |Xd.FY....#....!.|001024c0  e5 ec 02 a8 ff 7b e0 29  80 82 9b ac 82 ff 5f 3a  |.....{.)......_:|001024d0  18 f9 49 05 77 ce ff f0  4a 4c 09 e1 01 4f a2 ff  |..I.w...JL...O..|001024e0  9e 8d f0 14 87 f0 82 0c  ff 63 34 02 a8 74 09 91  |.........c4..t..|--0012ab40  53 5a 44 44 88 f0 27 33  41 00 d8 c6 00 00 ff 5d  |SZDD..&#39;3A......]|0012ab50  04 35 06 e5 00 b2 7c 7f  01 00 00 00 35 00 36 f9  |.5....|.....5.6.|0012ab60  f0 f7 1a 00 50 f9 f0 e5  03 35 04 ff 00 00 14 01  |....P....5......|0012ab70  49 05 00 00 ff ae 02 f7  07 00 00 9b 00 ff 92 08  |I...............|0012ab80  00 00 ec 00 7e 09 df 00  00 4f 00 cd 23 00 32 01  |....~....O..#.2.|0012ab90  ff ff 0a 00 00 dc 02 db  0d bf 00 00 3a 01 15 0f  |............:...|0012aba0  24 00 02 ff 64 11 00 00  88 03 ec 14 ff 00 00 b8  |$...d...........|--0013a3c0  53 5a 44 44 88 f0 27 33  41 65 b0 46 01 00 ff 4d  |SZDD..&#39;3Ae.F...M|0013a3d0  5a b0 00 a4 00 e7 02 ff  20 01 00 00 ff ff 43 13  |Z....... .....C.|0013a3e0  eb 80 00 01 03 3e 01 00  01 00 fb 87 61 6a 72 01  |.....>......ajr.|0013a3f0  04 18 0d 01 02 f9 f0 00  7d 4a f9 f0 f1 03 22 09  |........}J....".|0013a400  cd 37 00 55 bd 37 00 96  37 00 69 37 00 59 37 00  |.7.U.7..7.i7.Y7.|0013a410  5f b2 02 22 09 7f 4f 00  3c 4f 00 d5 27 4f 00 15  |_.."..O.<O..&#39;O..|0013a420  4f 00 06 4f 00 f6 01 57  22 09 b7 67 00 86 67 00  |O..O...W"..g..g.|--00147340  53 5a 44 44 88 f0 27 33  41 00 fe 02 00 00 f7 00  |SZDD..&#39;3A.......|00147350  00 01 f1 f0 20 20 10 00  be f9 f1 e8 02 00 00 16  |....  ..........|00147360  f9 f0 28 ec f9 f0 ef f0  00 40 f9 f0 01 00 04 a2  |..(......@......|00147370  f9 f2 80 ff f0 1d 0d 24  03 80 32 02 00 e3 80 80  |.......$..2.....|00147380  36 03 41 01 34 00 c0 c0  c0 74 3a 00 37 01 ff 52  |6.A.4....t:.7..R|00147390  02 00 ff ff 56 03 70 61  01 54 01 66 01 6e 0d 00  |....V.pa.T.f.n..|001473a0  78 88 81 07 16 37 01 78  77 91 06 78 8c 0d 9c 02  |x....7.xw..x....|--00147480  53 5a 44 44 88 f0 27 33  41 74 f1 15 00 00 c1 3d  |SZDD..&#39;3At.....=|00147490  f0 fd 00 0d 10 0d 20 0d  26 02 0d 0a ff 09 09 09  |...... .&.......|001474a0  46 69 6c 65 43 ff 6f 70  79 2e 74 78 74 20 7f 56  |FileC.opy.txt .V|001474b0  32 2e 30 36 0d 0a 26 0d  f0 5e 0d 6e 0d 7e 0d 30  |2.06..&..^.n.~.0|001474c0  05 52 55 4e 4e ff 49 4e  47 20 46 49 4c 45 ff 43  |.RUNN.ING FILE.C|001474d0  4f 50 59 0d 0a 20 20 7f  54 6f 20 72 75 6e 20 3b  |OPY..  .To run ;|001474e0  05 ff 20 66 72 6f 6d 20  44 4f ff 53 2c 20 74 79  |.. from DO.S, ty|--00147f80  53 5a 44 44 88 f0 27 33  41 00 fa 09 00 00 ff 44  |SZDD..&#39;3A......D|00147f90  69 73 6b 20 4d 61 6e ff  61 67 65 72 a8 0d 0a 4c  |isk Man.ager...L|00147fa0  ff 65 20 50 72 65 6d 69  65 fd 72 01 00 6f 67 72  |.e Premie.r..ogr|00147fb0  61 6d 6d ff 65 20 64 27  49 6e 73 74 ff 61 6c 6c  |amm.e d&#39;Inst.all|00147fc0  61 74 69 6f 6e b7 20 64  65 ef f1 71 75 24 00 75  |ation. de..qu$.u|00147fd0  ff 72 0d 0a 0d 0a 41 76  61 cb 6e 74 13 00 69 17  |.r....Ava.nt..i.|00147fe0  03 07 00 76 6f 5f 74 72  65 20 27 f0 f9 27 e2 fb  |...vo_tre &#39;..&#39;..|--00148500  53 5a 44 44 88 f0 27 33  41 00 1c 0a 00 00 ff 44  |SZDD..&#39;3A......D|00148510  69 73 6b 20 4d 61 6e ff  61 67 65 72 a8 0d 0a 44  |isk Man.ager...D|00148520  ff 61 73 20 4f 72 69 67  69 ff 6e 61 6c 64 69 65  |.as Origi.naldie|00148530  6e 73 ff 74 70 72 6f 67  72 61 6d ff 6d 20 7a 75  |ns.tprogram.m zu|00148540  72 20 46 65 fe 0f 00 6c  61 74 74 65 6e 69 f6 0e  |r Fe...latteni..|00148550  00 61 6c 23 00 69 6f 6e  0d ff 0a 0d 0a 42 65 76  |.al#.ion.....Bev|00148560  6f 72 ff 20 53 69 65 20  49 68 72 6b 65 6e ef fa  |or. Sie Ihrken..|--00148a80  53 5a 44 44 88 f0 27 33  41 00 fb 14 00 00 ff 4d  |SZDD..&#39;3A......M|00148a90  5a fb 00 0b 00 00 00 7d  04 f5 f0 ff ff 00 00 b8  |Z......}........|00148aa0  f5 f0 a2 01 01 40 01 04  0f 0d 1c 09 80 f5 f0 0e  |.....@..........|00148ab0  ff 1f ba 0e 00 b4 09 cd  21 ff b8 01 4c cd 21 54  |........!...L.!T|00148ac0  68 69 ff 73 20 70 72 6f  67 72 61 ff 6d 20 63 61  |hi.s progra.m ca|00148ad0  6e 6e 6f 74 ff 20 62 65  20 72 75 6e 20 ff 69 6e  |nnot. be run .in|00148ae0  20 44 4f 53 20 6d 7f 6f  64 65 2e 0d 0a 24 1c 05  | DOS m.ode...$..|--00149340  53 5a 44 44 88 f0 27 33  41 73 cd e3 00 00 3f 42  |SZDD..&#39;3As....?B|00149350  4c 41 4e 4b 00 f5 fd 05  0d fe 0d 04 04 10 00 3f  |LANK...........?|00149360  00 02 00 b7 47 00 04 0d  00 42 4c f3 f3 a4 ff 0a  |....G....BL.....|00149370  00 00 28 40 2a 00 54 73  55 f7 0d 0d 4a 0a ff 43  |..(@*.TsU...J..C|00149380  44 4a 0d fc 6c 0d 12 0d  03 00 43 00 a8 00 db 01  |DJ..l.....C.....|00149390  00 5b 05 80 28 34 03 50  51 fc 3c 0d 4c 0c 46 55  |.[..(4.PQ.<.L.FU|001493a0  4a 49 54 53 ff 55 20 4d  31 36 32 33 54 69 41 b5  |JITS.U M1623TiA.|--0014df80  53 5a 44 44 88 f0 27 33  41 74 2f 17 00 00 ff 0d  |SZDD..&#39;3At/.....|0014df90  0a 44 69 73 6b 47 6f ff  21 20 28 52 29 20 4c 69  |.DiskGo.! ® Li|0014dfa0  ff 63 65 6e 73 65 20 41  67 ff 72 65 65 6d 65 6e  |.cense Ag.reemen|0014dfb0  74 0d ff 0a 4e 4f 54 49  43 45 20 ff 54 4f 20 43  |t...NOTICE .TO C|0014dfc0  55 53 54 4f ff 4d 45 52  3b 20 20 54 48 ff 49 53  |USTO.MER;  TH.IS|0014dfd0  20 4c 45 47 41 4c ff 20  41 47 52 45 45 4d 45 ff  | LEGAL. AGREEME.|0014dfe0  4e 54 20 42 45 54 57 45  ff 45 4e 20 59 4f 55 20  |NT BETWE.EN YOU |--0014ed40  53 5a 44 44 88 f0 27 33  41 00 bb 09 00 00 ff 44  |SZDD..&#39;3A......D|0014ed50  69 73 6b 47 6f 21 20 ff  68 61 73 20 6e 6f 74 20  |iskGo! .has not |0014ed60  ff 64 65 74 65 63 74 65  64 ff 20 61 6e 20 41 54  |.detected. an AT|0014ed70  41 20 ff 64 72 69 76 65  20 6f 6e ff 20 79 6f 75  |A .drive on. you|0014ed80  72 20 73 79 ff 73 74 65  6d 2e 20 20 53 ff 65 76  |r sy.stem.  S.ev|0014ed90  65 72 61 6c 20 0d ff 0a  72 65 61 73 6f 6e 73 fb  |eral ...reasons.|0014eda0  20 63 09 00 63 61 75 73  65 fe ef f6 74 6f 20 6d  | c..cause...to m|--0014f2c0  53 5a 44 44 88 f0 27 33  41 00 e2 6f 00 00 ef e9  |SZDD..&#39;3A..o....|0014f2d0  1d 0b 00 f3 f9 43 4f 4d  ff 50 53 45 43 3d 41 3a  |.....COM.PSEC=A:|0014f2e0  5c ff 4f 44 49 4b 52 4e  4c 2e 3e 00 00 00 50 41  |\.ODIKRNL.>...PA|0014f2f0  54 48 07 01 f3 fa 00 2b  0d 3b 0d 4b 0d 5b 0d 6b  |TH.....+.;.K.[.k|0014f300  0d 7b 0d 8b 0d 9b 0d c0  ab 0d bb 0d cb 0d db 0d  |.{..............|0014f310  eb 0d f3 f1 53 74 3f 61  63 6b 78 78 78 00 1d 10  |....St?ackxxx...|0014f320  1d 00 20 1d 30 1d 40 1d  50 1d 60 1d 70 1d 80 1d  |.. .0.@.P.&#96;.p...|--00153d00  53 5a 44 44 88 f0 27 33  41 00 ef 33 00 00 fd ff  |SZDD..&#39;3A..3....|00153d10  f0 f0 c2 28 12 00 29 00  fe f9 f5 2e 8c 06 22 09  |...(..).......".|00153d20  2e 89 ff 1e 20 09 cb 4f  4e 54 52 ff 41 43 4b 44  |.... ..ONTR.ACKD|00153d30  2e 53 59 53 ff 50 53 51  52 56 57 55 06 ff 1e 2e  |.SYS.PSQRVWU....|00153d40  c6 06 1f 09 01 8c ff c8  8e d8 89 26 19 09 8c ff  |...........&....|00153d50  16 1b 09 fa bc 19 09 8e  ef d0 fb fc c4 09 00 26  |...............&|00153d60  8a 47 ff 02 3c 1a 90 90  72 03 b0 ff 1a 90 2a e4  |.G..<...r.....*.|--00155940  53 5a 44 44 88 f0 27 33  41 36 7d 2b 00 00 ff 4d  |SZDD..&#39;3A6}+...M|00155950  5a 7d 01 16 00 01 00 bf  20 00 00 00 ff ff f9 f0  |Z}...... .......|00155960  00 87 9a fc 40 f9 f0 04  01 0b 0d 1b 0d 00 0f 04  |....@...........|00155970  00 00 41 1d 0d 40 0d 50  0d 60 0d 00 70 0d 80 0d  |..A..@.P.&#96;..p...|00155980  90 0d a0 0d b0 0d c0 0d  d0 0d e0 0d 00 f0 0d 00  |................|00155990  1d 10 1d 20 1d 30 1d 40  1d 50 1d 60 1d 00 70 1d  |... .0.@.P.&#96;..p.|001559a0  80 1d 90 1d a0 1d b0 1d  c0 1d d0 1d e0 1c f9 03  |................|--00156940  53 5a 44 44 88 f0 27 33  41 00 62 40 00 00 ff 4d  |SZDD..&#39;3A.b@...M|00156950  5a 62 00 21 00 00 00 7d  04 f5 f0 ff ff 00 00 b8  |Zb.!...}........|00156960  f5 f0 a2 01 01 40 01 04  0f 0d 1c 09 80 f5 f0 0e  |.....@..........|00156970  ff 1f ba 0e 00 b4 09 cd  21 ff b8 01 4c cd 21 54  |........!...L.!T|00156980  68 69 ff 73 20 70 72 6f  67 72 61 ff 6d 20 63 61  |hi.s progra.m ca|00156990  6e 6e 6f 74 ff 20 62 65  20 72 75 6e 20 ff 69 6e  |nnot. be run .in|001569a0  20 44 4f 53 20 6d 7f 6f  64 65 2e 0d 0a 24 1c 05  | DOS m.ode...$..|--001588c0  53 5a 44 44 88 f0 27 33  41 00 31 1c 00 00 fc e0  |SZDD..&#39;3A.1.....|001588d0  fd f4 f1 57 65 6c 63 6f  6d ff 65 20 74 6f 20 44  |...Welcom.e to D|001588e0  69 73 ff 6b 47 6f 21 0d  0a 0d 0a fe 0f 04 20 69  |is.kGo!....... i|001588f0  73 20 61 20 57 ff 69 6e  64 6f 77 73 2d 62 ff 61  |s a W.indows-b.a|00158900  73 65 64 20 69 6e 73 ff  74 61 6c 6c 61 74 69 6f  |sed ins.tallatio|00158910  ff 6e 20 75 74 69 6c 69  74 ff 79 20 74 68 61 74  |.n utilit.y that|00158920  20 6d ff 61 6b 65 73 0d  0a 61 64 ef 64 69 6e 67  | m.akes..ad.ding|--00159ac0  53 5a 44 44 88 f0 27 33  41 00 60 88 01 00 ff 4d  |SZDD..&#39;3A.&#96;....M|00159ad0  5a 42 00 02 00 00 00 fd  20 f5 f0 ff ff 05 00 00  |ZB...... .......|00159ae0  01 f4 f5 f0 f5 f0 40 f5  f0 01 00 fb 61 23 6a 72  |......@.....a#jr|00159af0  02 03 17 0d 02 01 50 f4  f1 30 0d 00 40 0d 50 0d  |......P..0..@.P.|00159b00  60 0d 70 0d 80 0d 90 0d  a0 0d b0 0d 00 c0 0d d0  |&#96;.p.............|00159b10  0d e0 0d f0 0d 00 1d 10  1d 20 1d 30 1d 00 40 1d  |......... .0..@.|00159b20  50 1d 60 1d 70 1d 80 1d  90 1d a0 1d b0 1d f8 c0  |P.&#96;.p...........|--00166c00  53 5a 44 44 88 f0 27 33  41 63 fd 83 00 00 ff 5b  |SZDD..&#39;3Ac.....[|00166c10  56 49 45 57 54 4f 50 ff  5d 0d 0a 50 6c 65 61 73  |VIEWTOP.]..Pleas|00166c20  df 65 20 63 6c 6f ff f0  74 68 ff 69 73 20 77 69  |.e clo..th.is wi|00166c30  6e 64 6f ff 77 20 77 68  65 6e 20 64 7f 6f 6e 65  |ndo.w when d.one|00166c40  20 76 69 65 0d 00 ff 67  20 69 6e 73 74 72 75 ff  | vie...g instru.|00166c50  63 74 69 6f 6e 73 2e 0d  c3 0a 2a 35 0d 45 0d 55  |ctions....*5.E.U|00166c60  0d 5e 05 0d 0a fb 0d 0a  f0 f2 42 4f 54 54 4f 01  |.^........BOTTO.|--001694c0  53 5a 44 44 88 f0 27 33  41 65 d0 2d 01 00 ff 4d  |SZDD..&#39;3Ae.-...M|001694d0  5a 50 00 02 00 00 00 ff  04 00 0f 00 ff ff 00 00  |ZP..............|001694e0  89 b8 f5 f0 01 01 40 01  04 0f 0d 1c 09 90 fe f5  |......@.........|001694f0  f0 ba 10 00 0e 1f b4 09  ff cd 21 b8 01 4c cd 21  |..........!..L.!|00169500  90 ff 90 54 68 69 73 20  70 72 ff 6f 67 72 61 6d  |...This pr.ogram|00169510  20 6d 75 ff 73 74 20 62  65 20 72 75 ff 6e 20 75  | mu.st be ru.n u|00169520  6e 64 65 72 20 ff 4d 69  63 72 6f 73 6f 66 ff 74  |nder .Microsof.t|--001733c0  53 5a 44 44 88 f0 27 33  41 00 ed 52 00 00 ff 4d  |SZDD..&#39;3A..R...M|001733d0  5a ed 00 2a 00 05 00 7f  20 00 01 00 ff ff 00 fe  |Z..*.... .......|001733e0  f0 7f f8 0a ac 32 00 00  1e fe f0 57 01 00 11 fe  |.....2.....W....|001733f0  f0 15 fe f0 1b fe f0 0d  a8 05 00 26 33 fe f1 23  |...........&3..#|00173400  0d 33 0d 43 0d 00 53 0d  63 0d 73 0d 83 0d 93 0d  |.3.C..S.c.s.....|00173410  a3 0d b3 0d c3 0d 00 d3  0d e3 0d f3 0d 03 1d 13  |................|00173420  1d 23 1d 33 1d 43 1d 00  53 1d 63 1d 73 1d 83 1d  |.#.3.C..S.c.s...|
Update:after looking at the source code comments, the above mentioned findings are not completely correct:http://www.kyzer.me.uk/pack/xfd/#SZDD (link found by Wonko, see next post)

; Files in the SZDD file format are created with Microsoft's COMPRESS.EXE; program, and decompressed with Microsoft's EXPAND.EXE program. The file,; when compressed, usually has an underscore as the last character in its
; filename, ie HELLO.EX_ or VBRUN666.DL_
;
; File header format:
; 4 bytes : "SZDD" (0x53,0x5A,0x44,0x44) - magic ID
; 4 bytes : 0x88,0xF0,0x27,0x33 - more magic ID
; 1 byte : compression mode - only 'A' (0x41) known
; 1 byte : the character missing from the end of the filename (0=unknown)
; 4 bytes : A,B,C,D. unpacked size of file is (D<<24)|(C<<16)|(B<<8)|(A)
; n bytes : the compressed data



#22 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,081 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 August 2010 - 10:44 AM

Good find. :)

The 535a4444 means "SZDD" :(:
http://www.msfn.org/...showtopic=44909
http://www.kyzer.me.uk/pack/xfd/#SZDD

I'll try a couple of things and report.

:(
Wonko

P.S.: Files can be extracted allright with "normal" MS EXPAND.EXE.
The file Photorec found is a kind of index, it is at offset 0x159640 and the complete chunk is:
[FILE TIMES]Month=7Day=30Year=18Hour=2Minute=41Second=9[FILE NAMES]ODIKRNLBIN=ODIKRNL.BI_ ODIKRNL.BIN 1 18955DDLOADERBIN=DDLOADER.BI_ DDLOADER.BIN 1 20029CDREGEX_=0 CDREG.EX_ 0 18555CDUPDATEEX_=0 CDUPDATE.EX_ 0 120346CDUPDATEHL_=0 CDUPDATE.HL_ 0 10541DMEXE=0 DM.EXE 0 35845DM1EXE=0 DM1.EXE 0 165180FILECOPYEX_=0 FILECOPY.EX_ 0 53058FILECOPYICO=FILECOPY.IC_ FILECOPY.ICO 1 275DM1REC=DM1.RE_ DM1.REC 1 27710DM1HLP=DM1.HL_ DM1.HLP 1 165568GERMANTXT=GERMAN.TX_ GERMAN.TXT 1 1386FRENCHTXT=FRENCH.TX_ FRENCH.TXT 1 1372FILECOPYTX_=0 FILECOPY.TX_ 0 2791DISKGOEX_=0 DISKGO!.EX_ 0 392255DISKGOHL_=0 DISKGO!.HL_ 0 57897JUMPERSDB_=0 JUMPERS.DB_ 0 13503LICTX_=0 LIC.TX_ 0 3503INT13386=INT13.38_ INT13.386 1 2229NOATADRVTXT=NOATADRV.TX_ NOATADRV.TXT 1 1376ONTRACKDSYS=ONTRACKD.SY_ ONTRACKD.SYS 1 7191ONTRACKW386=ONTRACKW.38_ ONTRACKW.386 1 8059READMETXT=README.TX_ README.TXT 1 3413SETUPEXE=SETUP.EX_ SETUP.EXE 1 53532ONTRACKS38_=0 ONTRACKS.38_ 0 4084TXTSECTSSR_=0 TXTSECTS.SR_ 0 10393UNINSTALEX_=0 UNINSTAL.EX_ 0 40676XBIOSOVL=XBIOS.OV_ XBIOS.OVL 1 16676
Size of each file is (slightly smaller that the actual compressed data - that would account for the 00 padding)Right now problem appears to be that the order of the stored files is different from that of the "index", so assigning the right filename seems like a problem.....looking into it.Nevermind, files are stored re-sorted Alphabetically from their filename entry :cheers:

OT, but sometimes I have this urge to kill programmers :smiling9: the utter stupidity permeating this archive setup is appalling...

The file list contains 28 files.
There are 26 "SZDD" hits, it seems like files:
  • DISKGO!.HL_ and DM1.EXE are stored together in "item" #6, first one compressed and second one stored
  • DM1.RE_ and DM.EXE are stored together in "item" #8, first one compressed and second one stored


#23 ady

ady

    Frequent Member

  • Advanced user
  • 118 posts

Posted 20 August 2010 - 04:40 PM

Yes :(, that's the preferred (and suggested) method ( though ANYWHERE on your disk(s) as long as the path is in your PATH variable, should also work).
Please take note that I rarely (and have definitely NOT done it in this occasion) write batches foreseeing the use of it with paths with SPACES in the name, so, KISS approach, use a directory, somethng like:
C:\unsfxima\
and put in it the needed files and the "source" self-extracting images.


One of the advantages of Vista/Seven (comparing to XP) is that MS reordered and renamed the folders/directories so that the spaces issue would be less problematic. Users didn't see it that way, and complained about the changes (e.g. "Documents and Settings" -> Documents, "Application Data" -> AppData).

The absolute path has no spaces, and the folder contains:

cygwin1.dll
dynamite.exe
Expanded (DIR)
fsz.exe
gsar.exe
offzip.exe
UnSfxima.cmd

and I add the Ontrack exe to the same folder each time I want to process it. I leaved out all other files inside the original zip's (all the ones you told me to download). Did I miss something? I don't think so, but you know better so you tell me.

No, if in the \Expanded directory you get one (or more) files(s) with the same name of the sfx, but with .ima extension (or with a number added to the name) exactly 1,474,560 bytes in size, it should mean that decompression worked.


According to what I could understand from your code, the only floppy format supported is 1440K, so I guess that if it results in "something", it will always be of 1440K.

I wanted to be thorough, so I checksum the results with the ones obtained manually by "resource hacker bin -> dynamite img". In the cases where both methods were successful, the hashes were the same.

I still have to check the images with Qemu or VirtualBox (I didn't finish with the previously obtained floppy images yet), but from the point of view of extracting them, the code, in general, works.

Hmm, that's strange, but we may think about it later, I presume there is something not "kosher" in your hashing method.


The checksum program is working fine. The hash codes I received under Vista were the same, as I just mentioned. But the hash codes from the "same" floppy images I got using XP in VirtualBox are different. I have more examples of this situations, but as you said, we can check this later.


Are you using Qemu Manager 7, aren't you? :cheers:
Simply eject "floppy disk" and "load" the other image. (second icon from the left in lower set of icons at the top - the one that looks a lot like a blue floppy disk :( vertically standing on a floppy disk drive)


Thank you, that worked.

Now, a request about the batch, if I may. In cases where more than one floppy image is present, the first one has the same number as the floppy-creator exe, and the second one has a number "1" added. While making the floppies using the actual floppy creator, there are references to the first floppy as "1", and to the second as "2". During the boot process using the created floppies, the same references are used ("please insert the floppy named ... two").

Is it possible to adapt the batch to the same references? The ideal would be:
- if just 1 floppy is created, the original name stands, with the extension changed.
- if more than 1 floppy is created from the same floppy creator, the first floppy should be named as the original floppy creator with the number "1" added to its end, and before the changed extension. The second floppy would be <filename2.ima>, and so on.

I understand this is a "dirty" batch and is your free time we are talking about. My request is only to remain consistent/coherent to the naming scheme already in use. So if it's not very time-consuming, I'd appreciate if you could change it accordingly. If it's not so simple, or you assess it is not convenient for some/any reason, then that's ok. You're the boss.

Now, about testing the batch.

I have already compared many images to the "manual" method, and have several floppy-creators based on Ontrack which failed. How would you like me to report the results? Which information is necessary and which is not?

I took note of several things I saw. I have examples of failing both methods (manual and batch), failing in different manners, and failing only the batch method. I even have several examples that failed the methods, but worked directly under Vista, with several different reasons for failing.

Please point me to the correct direction so I can be useful to improve the batch and not to waste your time.

Thank you in advance.

#24 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,081 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 August 2010 - 06:46 PM

One of the advantages of Vista/Seven (comparing to XP) is that MS reordered and renamed the folders/directories so that the spaces issue would be less problematic. Users didn't see it that way, and complained about the changes (e.g. "Documents and Settings" -> Documents, "Application Data" -> AppData).

Actually the same thing can be seen the other way round, in a foolish attempt to mock the Macintosh filename capabilities, the good MS guys managed to mess up big, creating more problems to unexperienced users and unneededly complicating the life of batch (and more generally programmers) and "advanced" users.

Then someone with a minimal amount of brain understood that 3/4 of MS own stuff has problems with filenames containing spaces and used a bit of common sense in naming most used folders.

Anyway, Vista :) has NO known advantages (if not that of slowing down an otherwise perfectly functional PC, making otherwise perfectly working software useless, etc. etc.).

You should be banned :( for having used the term "advantage" in a sentence containing the word "Vista" :cheers: if you had said that aloud, your mom would have had you washing your mouth with soap! :(

BTW, do you know that there is at least one chap on the board that has problems with virtual floppy dirivers under Vista? :(
:cheers:

According to what I could understand from your code, the only floppy format supported is 1440K, so I guess that if it results in "something", it will always be of 1440K.

I may be wrong :cheers:, but I like to treat exceptions as "exceptions" ;), with all due respect :) you have a very "programmatical" approach (for not being a programmer).
Till now, all I have seen are 1440K floppy images, you first find a Sfx containing a floppy image that is NOT 1440K in size, then you post a link to where it can be downloaded from and then I will take the problem into consideration.
At the moment it is a non-problem, only a gratuitios speculation or assumption....:(

Like "What would happen if ...." :): let's make it first happen and later find a "cure" for it....



Now, a request about the batch, if I may. In cases where more than one floppy image is present, the first one has the same number as the floppy-creator exe, and the second one has a number "1" added. While making the floppies using the actual floppy creator, there are references to the first floppy as "1", and to the second as "2". During the boot process using the created floppies, the same references are used ("please insert the floppy named ... two").

Is it possible to adapt the batch to the same references? The ideal would be:
- if just 1 floppy is created, the original name stands, with the extension changed.
- if more than 1 floppy is created from the same floppy creator, the first floppy should be named as the original floppy creator with the number "1" added to its end, and before the changed extension. The second floppy would be <filename2.ima>, and so on.

I understand this is a "dirty" batch and is your free time we are talking about. My request is only to remain consistent/coherent to the naming scheme already in use. So if it's not very time-consuming, I'd appreciate if you could change it accordingly. If it's not so simple, or you assess it is not convenient for some/any reason, then that's ok. You're the boss.

NO problem, though of course it's introducing a pretty much unneeded complication in the check for existing .ima's in the \Expanded\ directory (that I will fix later)
Try replacing this (in the :OTDM section of the batch):
IF EXIST .\%TargetDir%\%ImaName%.ima &#40;

PAUSE

GOTO &#58;EOF

&#41;
with:
IF EXIST .\%TargetDir%\%ImaName%.ima &#40;

PAUSE

IF EXIST .\%TargetDir%\%ImaName%2.ima REN .\%TargetDir%\%ImaName%.ima .\%TargetDir%\%ImaName%1.ima

GOTO &#58;EOF

&#41;

Please don't ask me what will happen if a Sfx .exe contains more that two floppy images. ;)


Now, about testing the batch.

I have already compared many images to the "manual" method, and have several floppy-creators based on Ontrack which failed. How would you like me to report the results? Which information is necessary and which is not?

I took note of several things I saw. I have examples of failing both methods (manual and batch), failing in different manners, and failing only the batch method. I even have several examples that failed the methods, but worked directly under Vista, with several different reasons for failing.

Please point me to the correct direction so I can be useful to improve the batch and not to waste your time.

Thank you in advance.


The "manual" way (using dynamite) will often result in a file that is LARGER than the intended size (see previous posts).
There is no sense in comparing the results of the "manual way" using dynamite with the results of the batch, they will always differ.
Ideally you shouldn't even use ANYMORE the manual method.

Suggested testing procedure:
  • choose a Sfx, say <filename>.exe
  • run the batch against it
  • does one file, named <filename>.ima, exactly 1474560 bytes in size "appear" inside the \Expanded\ directory? (or two, named <filename>1.ima and <filename>2.ima)
    • If Yes, write down the <filename> and write next to it "OK"
    • If No, write down the <filename> and write next to it "FAIL"
  • choose another Sfx and loop to #2 untill all Sfx files have been tested

Post a list in the form:

-----Sfx name------Test------Available


Example:

DlgDiagv504f.exe-----OK
dm_creator.exe-----OK
MemScope-110.exe-----OK
SG_DW_104506_DOS_Floppy.exe-----OK
FJ_DG_945_DOS_Floppy.exe-----FAIL------ http://www.oldversio..._DOS_Floppy.rar


I would estimate the probability of the batch working in a binary 0/1 On/Off way (EITHER it works, and when it works it works allright OR it fails, and when it fails it does so miserably ;)) around 99.99% ;) but you know anyone can say anything with probabilities, percentages and statistics: 14% of people knows this....
;)

:)
Wonko

#25 ady

ady

    Frequent Member

  • Advanced user
  • 118 posts

Posted 21 August 2010 - 05:42 AM

Actually the same thing can be seen the other way round, in a foolish attempt to mock the Macintosh filename capabilities, the good MS guys managed to mess up big, creating more problems to unexperienced users and unneededly complicating the life of batch (and more generally programmers) and "advanced" users.

Then someone with a minimal amount of brain understood that 3/4 of MS own stuff has problems with filenames containing spaces and used a bit of common sense in naming most used folders.

Anyway, Vista :( has NO known advantages (if not that of slowing down an otherwise perfectly functional PC, making otherwise perfectly working software useless, etc. etc.).

You should be banned :cheers: for having used the term "advantage" in a sentence containing the word "Vista" :( if you had said that aloud, your mom would have had you washing your mouth with soap! :(

BTW, do you know that there is at least one chap on the board that has problems with virtual floppy dirivers under Vista? :(
:cheers:


I am just saying that almost everything has both, advantages and disadvantages. For example, the folder I put those dependencies and the batch itself. Before I read your recommendations, I even didn't think about putting it in a free-spaces path. If I were using xp, I would have had problems with this. On the other hand, using xp would have let me with less problems with VFD/ImDisk.

You see, I had the same pc for more than 10 years. Then in August 2007 I bought my current one. In those days, I had the option to buy a "new" XP, which went public in 2001, 6 years before, or to buy Vista with 1 year in the streets. (Of course, there are other options available, but that's for another day/topic) I made a choice between the 2. Maybe I made a bad choice, maybe not. Doesn't matter now. For any choice, there are always disadvantages, and advantages too. I am not defending Vista, nor against it either.

I may be wrong :(, but I like to treat exceptions as "exceptions" :cheers:, with all due respect :cheers: you have a very "programmatical" approach (for not being a programmer).


Advantages and disadvantages. ;) A programmatic approach? If you say so! ( good thing? Bad thing?, who knows? ) I just took a look at the batch. Still, I'm not a programmer.

Till now, all I have seen are 1440K floppy images, you first find a Sfx containing a floppy image that is NOT 1440K in size, then you post a link to where it can be downloaded from and then I will take the problem into consideration.
At the moment it is a non-problem, only a gratuitios speculation or assumption....:(

Like "What would happen if ...." ;): let's make it first happen and later find a "cure" for it....


I actually agree with you. I wasn't requesting to expand it to something more (or less) than 1440K. I am saying that it seems to me that testing the batch results with just "seeing" a 1440K file wasn't enough testing, IMHO. The batch results are one and just one of the following options:

A- The input is wrong (e.g. filling the wrong input filename)
B- The batch failed to create some 1440K file, no file is created
C- The batch created at least one 1440K file.

IMHO, the real test (from the "batch" point of view) is knowing the resulting file is actually the floppy image we want to achieve, not just some file being 1440K in size. Of course, from my point of view, the final test would be actually using the floppy image successfully in some troubleshooting computer-related problem ;) . But that's not what we are testing right now

NO problem, though of course it's introducing a pretty much unneeded complication in the check for existing .ima's in the \Expanded\ directory (that I will fix later)
Try replacing this (in the :OTDM section of the batch):

IF EXIST .\%TargetDir%\%ImaName%.ima &#40;

PAUSE

GOTO &#58;EOF

&#41;
with:
IF EXIST .\%TargetDir%\%ImaName%.ima &#40;

PAUSE

IF EXIST .\%TargetDir%\%ImaName%2.ima REN .\%TargetDir%\%ImaName%.ima .\%TargetDir%\%ImaName%1.ima

GOTO &#58;EOF

&#41;

Please don't ask me what will happen if a Sfx .exe contains more that two floppy images. ;)


OK, I won't ask, for now ;) As I said, I want to be thorough, so in some point of the near future, after having all those floppy images and the batch working for all of them, I may test it for those other situations. Who knows? :)

The "manual" way (using dynamite) will often result in a file that is LARGER than the intended size (see previous posts).
There is no sense in comparing the results of the "manual way" using dynamite with the results of the batch, they will always differ.
Ideally you shouldn't even use ANYMORE the manual method.


No offense, please. It is not at all my intention. I know my posts were long and probably boring to read, but I already wrote at least 3 times about the manual method under Vista:

1- Resource Hacker: in Ontrack's floppy extractors' cases, usually RCData -> 1531 gives you the bin file. This bin file can be bigger or smaller than 1440K. I have examples of the ones succeeding and the ones failing; and bin files being bigger and others being smaller than 1440K.

2- Taking the bin file obtained from resource hacker (whatever size the bin file is) as input file to dynamite, then I usually get a floppy image of exactly 1440K.

There are exceptions:

A- More than one floppy image contained in the floppy extractor. Usually Resource Hacker would find RCData -> 1532. I make 2 bin files, each one has different sizes and the sizes are not 1440K. Maybe one is bigger and the other is smaller than 1440K. Using Dynamite for each bin I usually get 2 floppy image files, each of 1440K.

B- Using resource hacker, I haven't seen RCData -> 1533 (a third floppy image) yet :) , but I have seen other situations like "no 1531", or "1541", or "no RCData at all. Those situations are part of the cases where at least one of the methods (manual and/or batch) failed in some way or another.

C- I have floppy creators failing both methods, or failing one, and also not running completely successfully under Vista.

D- I have floppy creators failing both methods, or failing one, but succeeding running directly under Vista. The ones in this category are succeeding or failing for different reasons. Not all of them have the same reason to fail one method and to run successfully under Vista.

That is why I am still comparing the hash codes of the resulting floppy images from different methods. Under Vista, usually they are the same hash codes. The ones I got from XP are not the same checksums But from previous tests (before testing your batch file), the contents of the floppy images obtained from XP are usually the same of those obtained under Vista. Contents yes, floppy image file checksums no.

I hope this time I was clear enough about the manual method and why I test the results with checksums.

Suggested testing procedure:

  • choose a Sfx, say <filename>.exe
  • run the batch against it
  • does one file, named <filename>.ima, exactly 1474560 bytes in size "appear" inside the \Expanded\ directory? (or two, named <filename>1.ima and <filename>2.ima)
    • If Yes, write down the <filename> and write next to it "OK"
    • If No, write down the <filename> and write next to it "FAIL"
  • choose another Sfx and loop to #2 untill all Sfx files have been tested

As I said, I don't expand the contents if the hash code corresponds to any previous method I used. But I am still checking at least the hash code of the resulting floppy image file.

I would estimate the probability of the batch working in a binary 0/1 On/Off way (EITHER it works, and when it works it works allright OR it fails, and when it fails it does so miserably :)) around 99.99% :) but you know anyone can say anything with probabilities, percentages and statistics: 14% of people knows this....
:)


I agree.

I'll prepare a list of the results and I'll post back. BTW, which is the most appropriate method to post a table in the forum?

Thank you in advance.




2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users