|
|
| Page 1 of 1 |
|
|
 Posted: Sun, 22nd Sep 2013 21:04 Post subject: Need some information based on a software process. |
|
 |
I'm doing software development in college, as a sub-subject we are assigned to doing troubleshooting and repair, basically getting to know the hardware and software on a whole.
My task is to explain the process from when you press the print icon, how the software communicates with the hardware, memory manager, I/O manager and the kernel, plus anything else, I'm not looking for a hand out, I'm looking for anyone that can point me in the right direction in regards to information to help me put this process in my own words.
Thank you so much in advance.
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 22nd Sep 2013 22:03 Post subject: |
|
|
If it's Windows in question, then it goes like this:
When you hit the Print button, it probably goes via Print Spooler API
http://msdn.microsoft.com/en-us/library/windows/desktop/ff686807%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/dd162861%28v=vs.85%29.aspx
And those API functions are implemented in three main Windows DLLs (system32, gdi32, user32), relying on the NT kernel (ntoskrnl.exe) which does stuff directly to the hardware. But since it's a closed source system, not much public details about the internals, try with the book "Windows 7 Device Driver" to see if there's anything usable there.
Process Explorer will be of a great help for tracing the behaviour of a Windows program. Also, "Dependency Walker", you can see which libraries is your EXE linked against and the list of functions it may use from it.
In Linux, there's this thing called CUPS which is a set of libraries for printing, callable by processes, but essentialy you communicate with a device by opening the appropriate device file (/dev/something), then you do some reads and writes (like you do with regular files) or send special signals using "I/O control" (by function named ioctl); because e.g. if a device supports full duplex communication, you can't do regular read and write because those are two distinct operations and not one with simultaneous read/write etc.
The appropriate driver for the device implements the handlers for read/write/ioctl signals, fetches your buffers and does stuff with them usually via memory-mapped I/O (it does reading and writing to memory addresses, but those addresses don't target real RAM memory but a device which is connected to the address lines of a common system bus, and intercepts those reads/writes. This is just a rough description, but it gets a lot dirtier when PCI or PCI Express is involved.
For memory and I/O manager in the kernel, you will unfortunatelly have to consult some heavy literature, I recommend "Linux Kernel in a Nutshell" and "Essential Linux Device Drivers".
You can also trace system calls issued by a process to the kernel during run-time, just launch a program using 'strace'.
In any case, this task is much more serious than it looks at first glance.
|
|
| Back to top |
|
|
Werelds
Special Little Man
Posts: 15098
Location: 0100111001001100
|
| Posted: Sun, 22nd Sep 2013 22:22 Post subject: |
|
|
You make CUPS sound much more complex than it is Guy_Incognito, that's way more in-depth than he needs to describe. You don't need to do any of the communication bullshit at all unless you've got some shoddy printer that doesn't even have a PPD available.
Regardless of what OS or the printer and its location, from a birdseye view it's all the same:
- Hit print
- Send stuff to spooler
- From spooler to handler which translates to driver format
- From handler to driver
On both Windows and UNIX (pretty much everything UNIX uses CUPS, not just Linux) the "tricky" part is that whatever you send to the spooler has to be supported; i.e. you can't just send some foreign format to it. Both have pretty wide range of supported formats by now though; CUPS can take PDFs directly for example. That's less common in PCL drivers. In either case though, PostScript is supported 99% of the time, that's become the industry standard.
For the exact details, just look CUPS up. There's tons of literature on it and even though it doesn't translate straight to Windows, if you read up on the differences between the two (as in how drivers work and where they live), you'll see that it's not that different. The path a job will follow is slightly different, but the principles are very much alike.
And the same applies when using a network printer. You're still sending things to a spooler; either locally (in which case the spooler will use a driver to do the network communication) or remotely (in which case the printer's software is the spooler and handles it all internally). An industrial printer for example you can just send any print-viable file to via LPR (which is PS or PDF for example); look up LPD / LPR to get this.
Guy_Incognito is right though, to really fully explain it you'll need a few hours to sift through it all. Bit of a weird "sub" task if you ask me 
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 22nd Sep 2013 22:35 Post subject: |
|
|
That does cover a lot of the information I'm seeking, the order relating to how the document reaches the printer and how i need to explain it is within a table, so explaining it where each of these pieces of the system are involved and what they do(their role);
Application.
File Manager.
I/O Manager.
Memory Manager.
Kernel.
Firmware.
Hardware.
using that table to explain in order essentially. top to bottom order.
Thank you.
|
|
| Back to top |
|
|
|
|
| Posted: Wed, 25th Sep 2013 20:00 Post subject: |
|
|
Turns out, i just need the information based on what the process does inside individual layers, from the table, nothing huge, just like, the sequence and how its passed from one to the other.
Thanks.
|
|
| Back to top |
|
|
| Page 1 of 1 |
All times are GMT + 1 Hour |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB 2.0.8 © 2001, 2002 phpBB Group
|
|
 |
|
