Atari disk images as virtual disks in Winsows XP

ppera · Post by **ppera** » Sat Jun 30, 2007 8:49 am

Since Windows, DOS use same FAT filesystem as Atari GEMDos, it may be a good way that we mount image files as virtual drives under Win XP.
I found some freeware program which can do it for partitions and floppy images (VDK).

Adding some GUI and GEMDos hard disk image support would make it pretty useful for data transfer - can do all operations in your favourite program as Total Commander...

In GUI should be opening image file (and drives too), then show all partitions. Then may assign GemDOS partitions to some letter in Win.
Some ideas for better usage ?

It will work with floppy images too.

alexh · Post by **alexh** » Sat Jun 30, 2007 9:51 am

The best tool I've seen like this was for Amiga disk images.

http://www.viksoe.dk/adfview/

It basically turned all disk images into "archives" just like ZIP under windows xp.

All the features of windows explorer are available.

Post by **ijor** » Sat Jun 30, 2007 7:13 pm

alexh wrote:It basically turned all disk images into "archives" just like ZIP under windows xp...All the features of windows explorer are available.

But "all" the features of Explorer are not the same as actually mounting a disk image. The difference is that a mounted image can be accessed at the commmand prompt and by any program, not just explorer.

But a couple of notes/caveats about disk image mounting software as VDK. It requires a custom kernel driver. A custom kernel driver always involves a potential risk. This doesn't mean it can't/shouldn't be used. Just that the user should be aware about the issue.

Second, seems that VDK (as most of this type of software) is based on stoled code. Again, I am not going to say that it can't/shouldn't be used, it's up to everybody to judge and decide.

Desty · Post by **Desty** » Sat Jun 30, 2007 11:13 pm

It would be nice if there was a way of doing this from user-mode to avoid that problem; explorer on my laptop is crashing a lot in WinXP because of an ext2 filesystem driver.

Does Daemon Tools (the ISO image mounter) use a kernel driver to do it, or is there some trick?

Post by **ijor** » Sun Jul 01, 2007 1:27 am

Desty wrote:It would be nice if there was a way of doing this from user-mode to avoid that problem; explorer on my laptop is crashing a lot in WinXP because of an ext2 filesystem driver.

You can't do it at user space. You do can implement somebody like Alexh mentioned that works at Explorer, but not something that actually mounts the image.

But please note that the required kernel driver is not actually a file system. It is something much simpler. Implementing a full Windows file system driver (as you need for adding ext2 support) is perhaps the most challenging task for Windows development. So while any custom kernel driver involves some risk, it's not nearly the same as the one involved with a custom file system driver.

Does Daemon Tools (the ISO image mounter) use a kernel driver to do it, or is there some trick?

I'm not very familiar with it (I use Nero Imagedrive instead), but all those ISO mounters/virtual CD software do include a custom kernel driver. Usually just a kernel driver, not a filesystem one.

ppera · Post by **ppera** » Sun Jul 01, 2007 8:56 am

Point is in usage of existing code (in Window) - we don't need filesystem driver, just image/attached disk partition recognition and simple driver.

Stolen code? I don't know - at VDK stays that he self examined VNC structure, what is not interesting for us. Kernel driver for mapping image as logical drive should be simple. If MS would have little better organized documentation I would not look for freeware sources.

Post by **ijor** » Mon Jul 02, 2007 1:50 am

ppera wrote:Stolen code? I don't know - at VDK stays that he self examined VNC structure, what is not interesting for us.

I don't know what you mean by "VNC structure", but VDK is based on FileDisk. And it is Vox Populi that FileDisk is (originally) stolen code. I noted that VDK has a different copyright than FileDisk, so technically, it might be not exactly derived from FileDisk. I don't know from the legal point of view, but morally, it smells the same thing, still indirectly based on stolen code.

Kernel driver for mapping image as logical drive should be simple. If MS would have little better organized documentation I would not look for freeware sources.

It should be simple, but it is not. Again, not as complicated as a file system driver, but still not simple. The documentation is there, but the main problem is that it is not a concept fully supported by Microsoft. Then most implementations are a bit of a hack. It is really a shame, Windows should support a file based disk out of the box, but it doesn't.

ppera · Post by **ppera** » Mon Jul 09, 2007 11:46 am

Unfortunatelly, it will not work as I expected at first.
After some tests I see that WinXP can not handle all GEMDos partition types.

As I see, it expects sector size to be 512 bytes always, and works with clusters of many sectors (up to 64). While Atari uses practically always 2 sectors/cluster, and 'Big sectors' up to 8192 to achieve bigger clusters.
Linux for instance works fine with all Atari partitions (at least I didn't see that not).
So, whole idea is good for floppies only.
Perhaps some dirty trick to remap bigger sectors to 512 byte sector, more sect./cluster combination... ? (With recalc of FAT len and some other params). Or continue Drive Image, and add DIR copy and delete...

Post by **ijor** » Mon Jul 09, 2007 7:14 pm

ppera wrote:Unfortunatelly, it will not work as I expected at first.
After some tests I see that WinXP can not handle all GEMDos partition types. As I see, it expects sector size to be 512 bytes always, and works with clusters of many sectors (up to 64). While Atari uses practically always 2 sectors/cluster, and 'Big sectors' up to 8192 to achieve bigger clusters.

Windows does support bigger sector sizes (I think upto 4k, would need to check). But VDK probably doesn't.

Or continue Drive Image, and add DIR copy and delete...

I'd consider implementing a shell extension. Still not the same as actual mounting, but probably good enough for most purposes and you avoid the need of a kernel driver.

Lautreamont · Post by **Lautreamont** » Tue Jul 10, 2007 5:39 am

ijor wrote:VDK is based on FileDisk. And it is Vox Populi that FileDisk is (originally) stolen code. I noted that VDK has a different copyright than FileDisk, so technically, it might be not exactly derived from FileDisk. I don't know from the legal point of view, but morally, it smells the same thing, still indirectly based on stolen code.

It looks like FileDisk and VDK are released under the same license: GNU GPL.
Legally, it's ok to take someone's code and release it under the same license without asking the author.
I don't believe that VDK can be blamed if FileDisk is stolen code, but the author should be warned that FileDisk is suspicious.
If he already knows, he should be frowned at.
The source files which don't have the author of FileDisk as the copyright holder are not tainted though.

Post by **ijor** » Tue Jul 10, 2007 6:21 am

Hi Lautremont,

Lautreamont wrote:It looks like FileDisk and VDK are released under the same license: GNU GPL. Legally, it's ok to take someone's code and release it under the same license without asking the author.

Hmm, I don't get you, or you didn't get my point. I didn't mean that they are released under a different license, but under a different copyright holder. Obviously, and I guess we agree, I can't get your code (with your copyright), and release it under my own copyright, disregarding any licensing issues.

So my point was that VDK might be (see below), legally, not a derivative work from FileDisk.

I don't believe that VDK can be blamed if FileDisk is stolen code, but the author should be warned that FileDisk is suspicious. If he already knows, he should be frowned at. The source files which don't have the author of FileDisk as the copyright holder are not tainted though.

Hard to believe that VDK author is not aware about the issue, but it is of course possible. I actually suspect (or at least, it smells like this to me) that changing copyright was done on purpose to avoid this issue.

Instead of adapting/modifying FileDisk (which would have been risky for VDK because of the possible ilegal status of FileDisk), he "re-coded" the software and put his own copyright. Then, not being "legally derived" from FileDisk, but just inspired or conceptually based from it, the whole issue is avoided.

I've seen other cases already of "inspired but not derived" where I had no doubts whatsoever it was derived (even when there was no cut and paste at all). I didn't study both codes here, to actually judge and be certain if this the case or not.

In the best case, it still stinks morally. If VDK "simply could not happen without his great works" (quoted from VDK, and mentioning FileDisk author), then it could not happen without the real original author (that is never mentioned).

tobe · Post by **tobe** » Tue Jul 10, 2007 10:54 am

Oh please go for the shell extension

ppera · Post by **ppera** » Tue Jul 10, 2007 12:06 pm

ijor wrote: Windows does support bigger sector sizes (I think upto 4k, would need to check). But VDK probably doesn't.

I'd consider implementing a shell extension. Still not the same as actual mounting, but probably good enough for most purposes and you avoid the need of a kernel driver.

I did not test it with VDK. It was test with hard disk - DOS partition table and GEMDos partition. And I'm not sure that we talk about same VDK - it should be only driver (virtual disk), and has not much with filesystem. And Winimage too did not recognise partition (Linux did). Sector size was 2K, btw.

Shell extension, oh no... rather switch to Linux,

(Spring Mandriva is very nice) or maybe Total Commander plugin...
Will see. At moment I do reversed thing on ST . work with multi sector clusters on ST without BigDOS.

Post by **ijor** » Tue Jul 10, 2007 4:12 pm

ppera wrote:
ijor wrote:Windows does support bigger sector sizes (I think upto 4k, would need to check). But VDK probably doesn't.
I did not test it with VDK. It was test with hard disk - DOS partition table and GEMDos partition. And I'm not sure that we talk about same VDK - it should be only driver (virtual disk), and has not much with filesystem. And Winimage too did not recognise partition (Linux did). Sector size was 2K, btw.

Yes, you will get the same issue with VDK, Winimage, FileDisk or whatever. The Windows FAT filesystem driver does support bigger sector sizes, but it requires support (for the bigger sector size) from the lower driver as well.

And it won't work (without a special driver) using physical disks, the physical and logical sector size must match. You'll need a custom filter below the FAT driver.

ppera · Post by **ppera** » Tue Jul 10, 2007 4:26 pm

ijor wrote: Yes, you will get the same issue with VDK, Winimage, FileDisk or whatever. The Windows FAT filesystem driver does support bigger sector sizes, but it requires support (for the bigger sector size) from the lower driver as well.

I don't think that Winimage should depend on some lower level driver when works with image files.
Of course that lower level driver must support bigger sector sizes. - According to BPB values it must supply proper count of bytes by sector size.
Plus positioning inside partition.

But as I see, smaller FAT16 partitions use 512 sector sizes only. Must do some tests about sizes over 256MB, to 2GB - time...

Post by **ijor** » Tue Jul 10, 2007 4:51 pm

ppera wrote:I don't think that Winimage should depend on some lower level driver when works with image files.

Winimage is the lower driver in this case. Lower is in relation to the FAT driver.

Of course that lower level driver must support bigger sector sizes. - According to BPB values ...

But the problem is that the lower driver (Winimage in this case) doesn't parse the BPB. And the FAT driver doesn't tell Winimage about the bigger sector size (it is actually the other way around).

But as I see, smaller FAT16 partitions use 512 sector sizes only. Must do some tests about sizes over 256MB, to 2GB - time...

Again, logical sector size must match the physical sector size. So the partition size is not relevant.

In other words, the FAT driver doesn't have a concept of "logical" sector size. It assumes, and it will insist on the logical sector size (as indicated by the BPB) to match the sector size on the physical geometry (as reported by the driver underneath the FAT driver).

So to make the whole thing work, the lower driver (WinImage, VDK, FileDisk, or a custom filter when using a physical disk) would need to be aware about this. It would need to parse the BPB, and "fool" the FAT driver by reporting a physical geometry according to the logical sector size (or otherwise try the idea of patching the cluster size, or otherwise make a custom FAT filesystem driver).

Lautreamont · Post by **Lautreamont** » Tue Jul 10, 2007 9:07 pm

ijor wrote:I didn't mean that they are released under a different license, but under a different copyright holder. Obviously, and I guess we agree, I can't get your code (with your copyright), and release it under my own copyright, disregarding any licensing issues.

We agree, you can't take my source files, claim that you're the author of them in your package and make me disappear.
When I read your post, I thought that some of the source files of VDK were taken from FileDisk.
The only case when it's possible without asking the permission to the author of FileDisk is if the VDK package is released under the same license.
It is and FileDisk is credited by the author of VDK on his homepage.
I didn't see anything suspicious in the behaviour of the author of VDK.

ijor wrote:Hard to believe that VDK author is not aware about the issue, but it is of course possible. I actually suspect (or at least, it smells like this to me) that changing copyright was done on purpose to avoid this issue.

Instead of adapting/modifying FileDisk (which would have been risky for VDK because of the possible ilegal status of FileDisk), he "re-coded" the software and put his own copyright. Then, not being "legally derived" from FileDisk, but just inspired or conceptually based from it, the whole issue is avoided.
[...]
I didn't study both codes here, to actually judge and be certain if this the case or not.
[...]
In the best case, it still stinks morally. If VDK "simply could not happen without his great works" (quoted from VDK, and mentioning FileDisk author), then it could not happen without the real original author (that is never mentioned).

I agree with you and wouldn't use VDK without investigating that.

ppera · Post by **ppera** » Wed Jul 11, 2007 1:56 pm

ijor wrote: Winimage is the lower driver in this case. Lower is in relation to the FAT driver.

But the problem is that the lower driver (Winimage in this case) doesn't parse the BPB. And the FAT driver doesn't tell Winimage about the bigger sector size (it is actually the other way around).

But as I see, smaller FAT16 partitions use 512 sector sizes only. Must do some tests about sizes over 256MB, to 2GB - time...
Again, logical sector size must match the physical sector size. So the partition size is not relevant.

.

In case of image files program should to do all self, at least I did so. Without any driver actually.

That about sector sizes I said according to some tables about usual partitions by diverse Win versions.

Physical sector size by hard disks is always 512. I don't know how you mean that logical must be same as physical...
I talk here only about FAT 16, btw.

Post by **ijor** » Wed Jul 11, 2007 3:45 pm

ppera wrote:In case of image files program should to do all self, at least I did so. Without any driver actually.

Sorry, I mixed up things with WinImage (was thinking WinImage with a VDK functionality). So I assume WinImage simply doesn't support bigger sector sizes. It easily could, but it probably doesn't because they are (almost) never used by DOS or Windows.

I guess if somebody would contact the WinImage author, he could add support for bigger sector sizes.

Physical sector size by hard disks is always 512. I don't know how you mean that logical must be same as physical...

By logical sector size I mean the sector size as indicated in the FAT BPB. Physical sector size is the sector size of the physical device (Hard disk or whatever). They must match from the point of view of the Windows FAT driver. That is, the FAT driver expects the sector size in the BPB to be identical to the physical sector size.

They don't actually need to be the same size. The FAT driver asks the lower driver about the device geometry. So as long as the lower disk driver reports a physical geometry with a sector size identical to the sector size in the BPB, then it should work.

ppera · Post by **ppera** » Thu Jul 12, 2007 10:54 am

I did some tests - all FAT 16 partitions up to 2GB have 512 byte logical sector size. Maybe Win NT had bigger sectors, since it had clusters over 64KB, but it is completly obsolete and irrelevant here.
So, no wonder that larger sector sizes are not supported.

"They don't actually need to be the same size. The FAT driver asks the lower driver about the device geometry. So as long as the lower disk driver reports a physical geometry with a sector size identical to the sector size in the BPB, then it should work."

It may be case, but because we don't have such hard disks, it is only academic issue.

Atari went little different way in 80-es than IBM-Microsoft in FAT16 case.
In case of TOS limitations are 'acceptable' - it is old, in limited lengthy ROM.
Win XP prooved again as inflexible, supporting only own structures.
People, go to Linux

tobe · Post by **tobe** » Thu Jul 12, 2007 11:05 am

ppera wrote:People, go to Linux

After years under Linux i've switched back to windows and i don't think i'll switch back to Linux in a near futur

ppera · Post by **ppera** » Thu Jul 12, 2007 3:06 pm

tobe wrote:
ppera wrote:People, go to Linux
After years under Linux i've switched back to windows and i don't think i'll switch back to Linux in a near futur

Best is to have both - not problem with today's big drives...

Post by **simonsunnyboy** » Thu Jul 12, 2007 3:57 pm

Yeah and use Windows for games only

Post by **ijor** » Thu Jul 12, 2007 5:18 pm

ppera wrote:I did some tests - all FAT 16 partitions up to 2GB have 512 byte logical sector size.

Once again, the system will format a partition using a sector size identical to the one in the drive geometry, disregarding the partition size.

"They don't actually need to be the same size. The FAT driver asks the lower driver about the device geometry. So as long as the lower disk driver reports a physical geometry with a sector size identical to the sector size in the BPB, then it should work."
It may be case, but because we don't have such hard disks, it is only academic issue.

It is not academic. You don't actually need such a hard disk, you "only" need to add a filter driver that would report the geometry you want to the FAT driver.

ppera · Post by **ppera** » Thu Jul 12, 2007 6:52 pm

ijor wrote: Once again, the system will format a partition using a sector size identical to the one in the drive geometry, disregarding the partition size.

It is not academic. You don't actually need such a hard disk, you "only" need to add a filter driver that would report the geometry you want to the FAT driver.

OK. I just said what is used. But I don't want to do such things - multi layer drivers and similar, at least not if things can be done simpler. Goal is to attach drive (media) to PC and work with it without any extra SW. Attach to Atari, and work with same partitions - it will need special partitioning and driver. Such thing exists in Hddriver, but there it is limited to only 1 partition...