Forum Replies Created
-
Posts
-
Hi, did you install the 32-bit version of Debugging tools for Windows and specify the correct path in VisualDDK settings?
As far as I know, it is only possible for the USB devices.
However, you can try making a “dummy PCI driver” that will forward the requests to a named pipe and then develop the high-level logic in user-mode. However, for certain device types this might be impossible due to performance constraints.OK, will check the file. However, note that WinCDEmu wil only mount the ISO tracks of such images. Making a kernel-mode mp3 decoder would be a very complicated (and useless) way to achieve the same result, as if you open the mp3 files in your favourite player 😉
As for Windows 7, some people like it, some don’t, but the goal of WinCDEmu is to make image mounting really easy. So, as long as a particular OS version is popular, WinCDEmu supports it 😉Investigated. It looks like the ISO file you provided has some additional padding after the end ot the file system data.
WinCDEmu does not analyze the filesystem and simply reports that the CD size is the ISO size + the “gap”. However, when you try to create the image, the Windows CDFS driver detects that you’re reading behind the end of FS and fails those reads.
The original ISO file size is 176160768 bytes. If I create the image using WinCDEmu, mount the image, create another image and so on, the size becomes 175722496 bytes. However, if I mount the original ISO to a virtual VMWare drive and create an ISO, I still get a 175722496-byte image. I.e. 214 sectors at the end of the original ISO file (filled with zero bytes) are discarded by VMWare.In simple words, the images created by WinCDEmu in your case are valid and you can ignore the error report. Also when you mount such images, they will be perfectly readable, as the FS driver will get the size from the FS headers.
As the reported issue does not occur in any real use cases (mounting images/creating ISOs of real discs) and does not cause any data corruption, I dontt think it’s reasonable to add any additional FS parsers to WinCDEmu to address it.This can be an issue of some emulators (in fact, old WinCDEmu versions as well). The ISO file does not contain the gap after the data track, however, the disc size reported by the drive should include it. If an emulator does not perform the transformation, you will see the issue.
If you do it with normal “physical” drives, the ISO file will be determined correctly.The option is now handled by WinCDEmuContextMenu.dll and is automatically translated to your UI language. If it actually does not appear, please try re-registering the DLL by running the following command:
regsvr32 “C:Program Files (x86)WinCDEmux64WinCDEmuContextMenu.dll”
or
regsvr32 “C:Program FilesWinCDEmux86WinCDEmuContextMenu.dll”HI.
No clue so far. Other things have higher priority.
Why do you need it, maybe I could suggest a workaround?It’s theoretically possible to make it if you modify the source files, however, the network latencies will make it quite a slow experience. To my knowledge, several people tried to make network versions, but nobody has achieved a reasonable debugging speed.
Not tested specifically with SP1, but did not have any problems with VS2010. If you encounter any, you’re welcome to post here.
As far as I have seen now, MDX is some kind of an obfuscated format:
http://askubuntu.com/questions/22240/how-to-mount-daemon-tools-mdx-file
http://sourceforge.net/tracker/index.php?func=detail&aid=3055342&group_id=93175&atid=603426
So, unless someone provides a clear format description, WinCDEmu won’t support it.
