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.
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. But is possible that being a bit dated has problems on Vista.
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:
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:
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.
@ 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):
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.
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.
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.
The "insert floppy disk/Ignore/Retry" is a nice trick
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).
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 has potential.
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.
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.
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).
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?
[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.
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.
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.
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 maybe you need to run it elevated, with UAC off or whatever (driversigning policy off)?
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/
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.
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).
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.
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?
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 ) 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 ) 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....
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 ) 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 .
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:
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.
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.
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.
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.
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).
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.
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
@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.
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.
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 vertically standing on a floppy disk drive)
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:
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
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:
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
OT, but sometimes I have this urge to kill programmers 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
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:
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? 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.
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" 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?
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 , 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 (
PAUSE
GOTO :EOF
)
with:
IF EXIST .\%TargetDir%\%ImaName%.ima (
PAUSE
IF EXIST .\%TargetDir%\%ImaName%2.ima REN .\%TargetDir%\%ImaName%.ima .\%TargetDir%\%ImaName%1.ima
GOTO :EOF
)
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
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....
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" 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?
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" , with all due respect 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 (
PAUSE
GOTO :EOF
)
with:
IF EXIST .\%TargetDir%\%ImaName%.ima (
PAUSE
IF EXIST .\%TargetDir%\%ImaName%2.ima REN .\%TargetDir%\%ImaName%.ima .\%TargetDir%\%ImaName%1.ima
GOTO :EOF
)
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?
But is possible that being a bit dated has problems on Vista.
maybe you need to run it elevated, with UAC off or whatever (driversigning policy off)? 
