The problem
I have a Windows XP pc connected to a printer. This pc runs a piece of software from where i create and send print jobs to the printer. Recently, the printer died and there is no way i can get a new one. The program is configured to print to this specific printer, which is now a problem.
The question
Is there a way to catch the data send to windows print spooler? From what i've found, i have to develop a print monitor (.dll file which will be read by spooler.exe, correct me if i'm wrong), however this seems pretty overcomplicated for such a matter. I've been searching the Print Spooler API, but the GetJob method returns, from what i can see, only informations about the print job, and not the actual data of the print.
I would like to catch this data and then process it in a another program that I will make myself. This is not really the issue, I am more concerned to know if it is possible to catch the data from the print spooler, and if possible some hints to how i could do it.
Thank you.
Your problem is more serious than you might realise. The task of transmitting spooled printer data to a specific printer is calls a Print Processor, which sits in the printer chain preceding the Print Monitor. Documentation here: http://msdn.microsoft.com/en-us/library/windows/hardware/ff551771%28v=vs.85%29.aspx
The spooled data can be in one of several different formats, and for some of them it may not be possible to redirect to a printer of a different type. You didn't mention what types of printers you are dealing with.
This is fairly serious stuff: writing and debugging one of these babies takes significant low level skills and understanding of Windows tech.
Edit: There's a good chance the data is in Enhanced Metafile format, and you need to take advantage of the built-in converters to turn that into commands for your new printer.
Related
I feel like this should be rather easy, but it continues to vex me, so here it is. I've been trying to find a simple solution to iterate through the available UART serial ports on linux (I'm running the most recent version of Manjaro Linux) and then printing these to the console. Yet, all of the solutions I've found thus far have been incredibly convoluted or they end up throwing a bunch of errors that I can'at figure out when I test them.
So, I've resorted to coming back here to see if anybody else has any ideas. On Windows, there is a GetPortNames() of Windows' System::IO::Ports, maybe a similar API call would be the most ideal.
Update:
So after receiving an answer and using that information to learn a bit more about interacting with serial ports on linux, I eventually ran across a good way to accomplish this effect of iterating through the available ports. It's not quite as simple as a one-line command, but it works so it's fine with me. I found this method of iteration/sorting through the /sys/class/tty directory as an answer to another question (the author of the code that I used is named Søren Holm), and you can look at that here.
Two simple possibilities:
Serial ports on linux are character device files, you can see them on /dev/ttyS*. Serial ports created by an usb device are in /dev/ttyUSB*. This reduces your problem to a dirent iteration.
There is also a thing named sysfs, it is essentially a runtime, non-persistant, kernel-internal registry which is exported to the user space via a virtual filesystem. Normally it is mounted below /sys. Below /sys/bus/serio/devices you can find the devices.
I am thinking of implementing a sort of daemon/service in C/C++ for linux, that would communicate with a specific gpib device through shell (using linux-gpib library).
The idea is that the daemon would scan for all existing devices and would create a file/pipe /dev/gpib#-* (where * would be their address on specified gpib bus) for each device. The use would be such as of /dev/com#. I could then type into command-line:
echo "*IDN?" > /dev/gpib1-12
which would send the "*IDN?" string to device 12 on board 1. So far it is a peace of cake...
The problem starts, when I want to retrieve data from the device. I want it to work analogically, so that
cat /dev/gpib1-12
would write out what has the device to say... But I can not know which command, I have sent to the device, would make the device to return a string (value) and which wouldn't. So my options are:
Repeatedly check (while-loop) if the device has anything to reply and send it to the corresponding pipe afterwards.
-or-
Query the device only when the client program attempts to read from the /dev/gpib#-* pipe. This would have to be served through 'signals' and 'waits'.
For obvious reasons (performance and/or latency handicap) I do not want to implement solution 1. I do not know how to do the the other thing though... I feel, that it must be possible to implement on the ol'mighty linux, but how? I did read this and I think that some spin of the function select() is the right way forward, but I can not figure out how to use it for my problem. I also stumbled upon this, where the guy explains how to do something similar, yet sooo different (code mosfet.c).
The question is: how can I immediately detect and react upon an attempt to read from the other side of pipe/FIFO/file via signaling, waiting or interrupts?
Thanx for answers.
PS: It is half past seven in the morning here (yep another sleepless night), so please excuse my broken English...
PPS: Oh yes, and if anyone would already know of such gpib daemon for linux, or if the think I am asking (accessing individual devices through file I/O) would be possible via the linux-gpib library, please let me know. I did read the doc's and src's for linux-gpib, but found nothing helpful. All the linux-gpib library provides are bindings to C, Python, etc.
PPS: Are there maybe other alternatives to using pipes?
If you just need a nice terminal for your gpib device, you can use python (or even better ipython).
linux-gpib comes with python wrappers (for the code look here). so in your shell open python by typing python
In the python interpreter you can easily communicate with the device like this
>>>import Gpib
>>>device = Gpib.Gpib(pad=2)
This opens a connection to the gpib device with the primary address 2. To communicate with it simply do
>>>device.write('*IDN?')
>>>device.read()
'HEWLETT-PACKARD,33120A,0,8.0-5.0-1.0'
To simplify it even further, use ipython instead of plain python. This gives you tab-completion and much more.
I have a feature request on a project I work on, it is to integrate with a Paylife CC handheld, which has a USB connector to connect with the computer. I have the docs, and am reading up on it.
When I searched on google how to read/write to a usb device on linux, it said, use libusb.
I was wondering, is there another possibility? Can't I just open it like a file and write a stream to it, and read a stream from it?
I don't actually need to do anything fancy. I just need to write a string of control codes to the device, and it would be mildly nice to read back the ACK and Error codes. But since those are already displayed on the device screen, I don't have to do much with it, just deliver the total required for payment.
So my question is, what are my options?
The connected computer is a regular ol ubuntu linux box.
It is definitely possible when the device complies with one of the USB device classes -- drivers for them are universal.
If that's not the case, then you may stick with a manufacturer-provided or a third-party driver, given there is one and you possess enough of it's documentation.
If that's also not the case, libusb-1.0 is your resort, unless you want to write a kernel driver youself :)
How does one begin writing drivers for Windows? Is there some sort of official DDK "Hello World" example out there?
While I'm sure it will be way above my head at first, eventually I would like to create a simple MIDI driver, much like the Maple Virtual MIDI Cable where the MIDI messages come from a user application rather than a physical device.
(The trouble with using the off-the-shelf MIDI loopback drivers is that the existence of an input and output end is often confusing for the user. My application generates MIDI output that gets sent to the MIDI input of other programs, so if I could create a fake driver that connects to my program rather than hardware, it would eliminate this confusion.)
Thank you for your time.
The WDK docs are reference material, they won't teach you how to get started. Essential are the sample code included with the WDK, there's lots of it and you can often find something that resembles the kind of driver you want to create. A generic filter driver is available in the src\kmdf\toaster\filter directory, I think that's what you'd need if I understand your goal properly.
Walter Oney's books are essential to learn important concepts, strongly recommended. I keep running into osronline.com as a web site that strongly focuses on driver development, with forums. You typically won't find much help here, it is a rather specialized kind of coding.
You could take a look at my virtualMIDI-driver:
www.tobias-erichsen.de/virtualMIDI.html
This one does exactly what your are looking for.
Tobias
I am creating a basic signal generator and decided to use my audio card as the analogue output. I chose to use DirectSound because... it seemed like a good option.
I have it up and running quite nicely, but I now realize that my code using secondary buffers and as such any other sounds on the computer get mixed in with my generated signal. This is something of an issue, as when I'm running a motor I don't want it to get sent an MSN poke noise as a command.
In order to gain total control I've attempted to take over the system by setting my cooperative level to DSSCL_WRITEPRIMARY. All in all this strategy is really giving me a headache as I am running into error after error trying to get this set up. The documentation on using the primary buffer isn't great and I can't find any really good examples.
So my question is:
Does anyone have a good, working example of taking over and writing to the primarybuffer.
Is there a simpler way of outputing a waveform to the audio card, and ensuring that my application has full and sole control?
Thank you
only thing I've seen related is:
http://blogs.msdn.com/b/matthew_van_eerde/archive/2009/04/03/sample-wasapi-exclusive-mode-event-driven-playback-app-including-the-hd-audio-alignment-dance.aspx