Forum Replies Created
-
AuthorPosts
-
supportKeymaster
You can always change the DLL path by selecting Tools->VisualDDK Options in Visual Studio.
BTW, does the 1394:// prefix work correctly?supportKeymasterNo, but you can try redirecting the host-side named pipe to the other VM using the GuestRPC protocol (http://articles.sysprogs.org/kdvmware/guestrpc.html). (You’ll need to modify the sources)
supportKeymasterNo idea, but you can google for something like “windows 7 testsigning desktop icons disappeared”. It is not specific to WinCDEmu.
supportKeymasterCheck your system settings regarding unsigned drivers:
This article can be helpful: http://www.mydigitallife.info/2007/12/07/disable-unsigned-driver-installation-dialog-prompt-in-windows-xp/supportKeymasterNo, the mounted images are read-only. If you want a free tool to create ISO images from existing files, see mkisofs (http://en.wikipedia.org/wiki/Cdrtools).
supportKeymasterOk, this seems to be some kind of incompatibility. WinCDEmu 3.x uses a new ‘virtual SCSI’ model to create virtual drives. However, most advanced commands (that go beyond just reading some data) are replied with “not supported” status. I guess, this confuses many 3rd-party products (e.g. Roxio) and causes them to crash. That also explains why I cannot reproduce the bug on any of my machines.
I will look towards including a ‘debug mode’ in the next release of WinCDEmu that will collect precise records of all received requests, so I will be able to understand why the 3dr-party components get confused. You can also e-mail Roxio techsupport, as, if their driver actually causes blue screens, the bug is contained in it and WinCDEmu can just provide a workaround by responding to more non-essential requests…supportKeymasterUnderstood. Your case is quite rare and WinCDEmu was not designed to handle such use. I guess, you need a more advanced imaging system then… Good luck in finding it 😉
supportKeymasterUnfortunately, I don’t have much time to look into details right now. However, I don’t think that relying on undocumented _CxxThrowException(), that can be changed in future versions, is a good idea. Moreover, I don’t explicitly see whether your example is compatible with x64.
I would suggest redefining __THROW_BAD_ALLOC using SEH. As SEH is already supported by WDK, that should not be a problem. We won’t get a full equivalent of C++ exceptions, however, this particular problem (handle npagednew() for STL containers) will be solved smoothly.supportKeymasterIf I remember correctly, a call to exit(), that is equivalent to KeBugCheck(). You need to patch STLPort to handle such cases correctly.
supportKeymasterYes, BazisLib fully supports writing kernel-mode drivers and even has several examples of compact and efficient object-oriented drivers.
The discussion about “only C” is caused by the fact that misuse of C features would cause one write more lines, but misuse of C++ features causes one source line generate much more binary code (e.g. use of implicit std::string constructor from a constant string, when not needed), that results performance drop not noticeable by developer directly. That’s why, rather than carefully design C++ programs and check the result in disassembler for some cases, many developers prefer using “old plain C”.supportKeymasterThis was originally done to make Device Manager display correct image names as device names. However, the overhead of “new device found” every time really seams unreasonable. It will be fixed in the next version.
supportKeymasterPlease try this fix: http://wincdemu.sysprogs.org/wcdcleanup.exe
Please inform me whether it solves your problem. If it does, I’ll fix the next version of WinCDEmusupportKeymasterOk, does the COM-based or VM-based debugging work on your machine? Maybe, the problem global to VisualDDK and not related to 1394 directly? Additionally, maybe it is some kind of a problem with UAC? Does Visual Studio have the same access level, as WinDbg?
supportKeymasterOK, is WinDbg closed when you are connecting from VisualDDK? Have you specified the path to the latest version of Debugging tools in VisualDDK settings? When you use WinDbg, did you specify “1934:channel=0” in command line, or did you use the dialog box?
supportKeymasterInstalling WinCDEmu has enabled the “testsigning” mode (http://msdn.microsoft.com/en-us/library/dd419910.aspx). Without this mode, Windows 7 cannot load unsigned drivers (signing is not free). You can read more about testsigning (including how to disable it) here: http://www.sysprogs.org/signing/
-
AuthorPosts