Forum Replies Created
-
Posts
-
Well, if you are already debugging your machine with WinDbg, how can VisualDDK attach to it? The pipe is obviously occupied by WinDbg instance. However, if you close the WinDbg (and uncheck ‘automatically start the debugger’ in VMMON, or just close VMMON, as it is no needed for VisualDDK), debugging from VisualDDK should work.
Bridging is required for automatic driver binary updating, however, is not mandatory for debugging with VisualDDK. If WinDbg/VirtualKD works, and VisualStudio with VisualDDK fails, you can try using Debug->Attach command, selecting “Kernel-mode connections” and picking your OS manually. You will get either a working debug session, or a more detailed error message.
Sure, however, with relatively small DriverEntry this will not give any noticeable effect. On the other hand, moving some initialization functions to .init section may cause failures, in case such functions are accidentally called after initialization. So, IMHO, freeing up to 10K of RAM (typically less than 1K) on a 1-4GB machine at a cost of making the code potentially unstable (if later one forgets that a certain function is in .init) is not very reasonable. However, this is just my IMHO.
So, if i understand correctly, i can use new/delete/npagednew in KM C++ if i include stlsup.cpp?
Yes. Otherwise you will simply get a linker error stating that “operator new()” is undefined.
Just try DDKWizard, why you not use RTL_CONSTANT_STRING to define DeviceName and Win32Device instead of RtlInitUnicodeString?
Sample files for DDKWizard were copy-pasted from some very old stuff without any refactorring. Anyway, thanks for the advice, I’ll probably update the samples.
It is managed by BazisLib. You can see the stlsup.cpp file for new() and delete() implementation. However, note that if you need to allocate objects from non-paged pool, you should use the npagednew() function instead (or, more preferably, overload the new() operator for your specific class, that always needs to be allocated from non-paged pool; for example, see the irpqueue.h file). The standard C malloc()/free() implementations are provided as well for compatibility reasons.
You need a special “runtime” libraries to use exceptions. For other purposes (static/global constructors & etc.), the BazisLib startup file is enough.
Surely you can use the STLPort without BazisLib, however you will need the code that calls static C++ constructors/destructors, that can be easily separated from BazisLib.
As for the compiler flags & etc, I would recommend avoiding exceptions in kernel mode, as using them has quite an impact on performance and stack requirement. Check out the VisualDDK project wizard, it allows creating Visual Studio driver projects without a link to BazisLib.
Finally, regarding object creation & programming style, I could only suggest being sure, what will the optimizing compiler produce from your C++ code, and checking the disassembly in case of a smallest doubt. Anyway, it is possible to make C++ programs as efficient/small as C ones with much less coding effort, however it requires checking the disassembly, as the optimizer is not always perfect.
See WinCDEmu sources for a (relatively) simple example of a C++ kernel driver.😮 ??? If something about kernel-mode part of BazisLib is bad, a bugreport/wishlist would be much better than undirected sarcasm.
Oops. Saw the post too late. Already fixed, will be included in next version installer. As for the quotation marks & unicode symbols, maybe will do it later, however, I’m not that good in PHP, as in kernel development 😉
Could you please send me the faulty CUE file by mail, or post it here? The parser for CUE files is now quite simple and may miss something.
Windows Vista indicates testsigning mode by /TESTSIGNING boot option. Win7 – just by TESTSIGNING (without slash). The original installer did not consider it.
WinCDEmu does not explicitly report its drives as CD or DVD. Maybe, your programs expect the virtual drives to handle some specific request codes? Which exact programs are confusing CD and DVD with WinCDEmu?
No, it is not possible. Full-featured local kernel debugging is impossible by definition: imagine what would happen, if a breakpoint inside a video or keyboard driver (or any other kernel component that makes any critical driver or service wait) is hit: kernel is halted until a debugger resumes it, and a debugger is halted until kernel processes your mouse or keyboard input…
Some limited local kernel debugging (no stepping, breakpoints, etc; basically, no code execution) is supported by WinDbg, but it is not very useful to debug drivers and not supported by VisualDDK.
