J. P. Gilliver (John) wrote:
In message , Ed Cryer
writes:
[]
I've found out that Win10 has its own generic iso-mounting capability.
It's in the context menu of iso files, but with the restriction that
they have to be on an NTFS-formatted medium.

Ed

What possible reason can there be for that restriction, other than
personal prejudice on the part of the programmer? I know NTFS is
generally considered better in many ways, but I can't see why what
format (?) the supporting media is, should have any bearing on whether
an iso-mounting capability works or doesn't. (I'm assuming here we're
talking of a read-only ISO, i. e. an image of a CD or DVD.)

OK, I remember what this reference is about.

It's the same issue as VHDMount.

It's the partition the *operating system* is on.

VHDMount only worked if C: for the operating system was NTFS.
If your copy of WinXP was installed on a FAT32 volume,
VHDMount wouldn't work.

It's possible the ISO mounter uses a similar hook, and
you have nothing to worry about, as the Vista+ OSes all
use NTFS for C: .

Maybe that's where the reference comes from. It's the
anchor point and namespace for the backend of the mounter,
rather than the supported optical disc formats.

And the funny part would be, that other people make
mounters, that run on anything. For example, Macrium
can mount an MRIMG on WinXP where C: is FAT32, so they
don't have such a restriction for what the mount point
can be on.

And I don't think there was such a restriction (as such)
on IFS (installable file systems). You can support
practically anything on Windows via the IFS mechanism,
as long as someone writes a driver. I think there
might be two EXT mounters as an example, one of
which was only compatible with a very early version
of EXT (Linux) file system.

So if there were restrictions, I've been unable to
find a technical reference to where the restriction
is coming from. Over the years I've believed it
to be bogus, but have been unable to find any
article to shine light on why Microsoft does
that sort of check at mount time.

It's like the nonsense idea, that mounting a VHDX
on Windows 10, absolutely has to have Hyper-X installed.
Writing mounters in 2018 is a doddle (it's part
of virtual machine hosting stack), and simply packaging
up some DLL should be enough to do it, without torturing
people with pudgy suites to install, just to get one
stinking DLL. Microsoft management do come up with the
strangest ideas. And when they do **** like that,
all they do is marginalize their tech (Paul won't
install Hyper-V in any case, so Paul won't *ever*
put .vhdx into *any* workflow - see how .vhdx
gets doomed by this sort of behavior ? This also
puts Windows 7 Backup in Win10 "out of bounds"
as it uses .vhdx.).

Paul