There was a smbmrx sample code using RDBSS in WDK Vista.
But since WDK 7600 has been released, the sample was removed. -Do you know why?
I'm finding a nice sample code to learn RDBSS.
Is there a good open source better than smbmrx sample?
It was probably removed because it was getting long in the tooth. It was never the full SMB redirector implementation shipped with Windows, it was some subset of the original version. It also uses TDI which is being deprecated in newer Windows in favor of WSK.
I don't know of any good open source examples. A network redirector is a complicated piece of software to write and there's value there for anyone brave enough to go for it. Why do you need this?
-scott
Related
I am working on a compiler for a small (toy) language that produces 16-bit com-files, which are executable in Windows XP. However, in more modern releases of Windows com-files are executable only with the help of tools such as DosBox. I would like my compiler to produce exe-files that can be executed directly in Windows 10.
As I understand it, the exe-file needs a header that instructs the system of how to execute it. My idea is to simply add the header at the beginning of the com-file to extend it into an exe-file. I wonder if anyone can recommend an appropriate tutorial that describes how exe-files works. More specifically, I am looking for a tutorial of how to build the smallest possible working exe-file.
I also wonder if there is a difference between exe-files for 32-bit or 64-bit Windows?
Best Regards,
Stefan
You can download description exe format here. You need pecoff.docx file.
Also you may look on this old but detailed doc here.
What is the fastest way to capture a screenshot in Windows? A driver? Using DirectX?
The fastest way would be to read mapped region of video card memory I think... Just an idea, never tried that.
A while back I timed the win32 api and the .net wrapper. Here is the complete blog post:
http://blog.bobcravens.com/2009/04/fastest-screen-capture-using-c-vista-vs-win7/
The upshot is that the .net wrapper in the latest version of Win7 is as fast as the native win32 api. I have never tried DirectX or the other options. The .net wrapper was fast enough for my purpose. I have heard that accessing the video drivers (like VNC does) is the fastest. I have nothing to back that up, but it seems reasonable.
Bob
In a nutshell, I want to write my own device driver for windows, so that I can emulate a piece of hardware. I know very little about writing device drivers for windows, but I have a very firm understanding of the C and C++ languages, and I know enough x86(_64) assembly to get around.
I'm not really sure how one would go about even compiling a device driver, or what is required to create one. I'm certainly not against coding the entire thing in assembly if that needs to be done, but does it?
I'd like to do this using Windows tools obviously, I'm planning on trying to put it together using a windows GCC compiler, but I've got access to Visual Studio if that's needed. Can someone point me at resources that would be helpful, like reference manuals, tutorials, specs?
Oh: My target OS here is Windows 7, 64bit, which if I understand should be the same as Windows Vista 64bit, but correct my wrongness if it exists.
Thanks.
Everything you need to build your driver (including the compiler) comes from the WDK. Everything you need to know what to write comes from Walter Oney's books. Be prepared for a rough ride.
I am trying to learn a little about driver development and my question is, which OS has an easier API to develop drivers with? Windows or Linux?
Remember that I am new to this.
Thanks
If you are doing this for learning (I guess its your case), then go for Linux, you will have a more general ideal on how an OS works, you will interact with low level implementation straight to the core.
If you are just writing a driver for a device, I recommend using Visual Studio under Windows, it has a lot of features that will really help on your devel.
I am pretty sure you'll get lots of Windows vs Linux war here, unfortunately.
On Windows, you'll get pretty good development tools, with some awkward stuff, but that you can get along with easily. API is documented provided you have access to a Windows Developer account. Remote debugging is supported and it helps a lot for these kernel stuff that are triggering BSOD so quickly.
On Linux, you'll need to get your hands more dirty. Rubini's "Linux Device Drivers" is a very good starting point. Openness will bring you more flexibility, and more understanding of what is happening.
This tutorial might be helpful.
It is about writing a simple device driver for linux.
My personal idea is Linux. You can see the entire code other than an API.
I think Windows is good.
Because it has a rich set of API's which is easier to use
I need to develop a print driver to print from any application into a TIFF file. Does someone know of resources or a good SDK vendor that would enable me to do that? Environment is Windows, any language.
The Microsoft Windows Driver Kit (freely available from the linked Microsoft site) has extensive documentation and examples on writing printer drivers. You can check the online printer driver page of the DDK docs before downloading it.
Edit: One commercial alternative that would probably be much quicker to deploy is VeryPDF's DocumentPrinter. It's rather pricy (currently $1500 for a developer license, $399 for a server license), but from what I've heard their support is rather good so if the price is tenable for you this may be a good option.
There's also a SDK from DirectConvert, but I couldn't find any pricing info and don't know anything about them.
Depending on your usage patterns, another option would be something like TechSmith SnagIt, which has printer capture facilities available. This is not a SDK, though.
Create a raster print driver using the Windows DDK. The sample they provide will do just fine. This will generate bitmaps, which can then be converted to TIFF using LibTiff. Your OEMSendPage function is where you'll want to convert the bitmap to TIFF and save it. If you're unfamiliar with the DDK and Windows print drivers, expect to spend quite a bit of time on this.
I have source for a driver I used to sell that does exactly what you want, but I stopped maintaining it after NT 4 so it's seriously out of date and would require some significant work to make it useful on modern Windows platforms.