Forum Replies Created
-
Posts
-
DDKDebugLauncher is a .Net module and should not be causing missing DLL problems. Could you download VisualDDK sources from SourceForge, compile DDKDebugLauncher (it will register itself automatically), set a breakpoint in BasicMSDbgSession::CreateClient() and step through to see what fails?
Have you specified the path to Debugging Tools in VisualDDK settings? (Tools->VisualDDK settings in VS).
You can either create a new “make project” so that Visual Studio will invoke “build”, or use VisualDDK project wizard and select “use existing files” to have the project created for you.
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.
