Is there a version of the CUPS server available for Windows? Looking at the CUPS source code it seems it is ready for Visual Studio compilation, but I did not find any trace of an actual supported package. I'd like to set up a CUPS server on Windows so that I can print form Linux/MacOSX/Win clients to printers I set up on this server.
I've got a new answer for you:
Since some time there is a project called ippsample on GitHub. It's slowly approaching a mature version 1.0 release.
Here are the first two sentences of given as self-description in the mandatory README file:
"This code provides sample implementations of IPP Clients, Printers, and Proxies. It is largely based upon the CUPS software, with substantial changes to the ippproxy and ippserver implementations to make them more general-purpose and configurable." (my emphasis)
This project is hosted by the ISTO Printer Working Group (PWG), the same industry organization which develops and promotes the IPP as a general standard.
The ippserver, ipptool, ippfind, ippproxy and ipptransform components of the IPP Sample project together make up for a standard-conforming IPP Everywhere implementation, covering the client as well as the server side of printing.
The GitHub code for IPP Sample project is maintained by the very same Mike Sweet who also develops CUPS -- so it's the real thing.
Yes, it compiles and works nicely on Windows, and there are a bunch of .vclxproj and .sln files available to make the build process with MS Visual Studio as smooth as possible.
Yes, the IPP Sample code is working and can print to a CUPS server (or receive print jobs from there) running on macOS or any blend of Linux.
No, this is not yet a fully-blown CUPS server for Windows which can serve as a drop-in replacement for a Windows print server. It does not have with ALL the features which would be required.
But if you want to create such a beast:
this is the place were you would have to poke around first;
this is were you possibly could fork the code and start adding functionality to get where you want to go.
Oh, and did you know that Apple recently changed the license conditions for CUPS and made it more permissive, moving away from GPL2 to Apache 2.0 licensing?
You have never heard of "IPP Everywhere" before? It is the future of "driverless" printing.
Never heard of "driverless printing"? A slightly modified (and stripped down) version of it already implemented as "Apple AirPrint" for iPhone and iPad devices.
The current implementation of the CUPS-based printing stack includes new pieces of code in the cups-drivers project which recently moved to GitHub. This new code implements IPP Everywhere functionality.
This cups-filters project is under the stewardship by The Linux Foundation's OpenPrinting department ever since Apple handed over these parts of the original CUPS source code to them when they became no longer useful for macOS but were still important to Linux.
What are the basic ideas of driverless printing then?
Have the devices automatically announce their presence and their type of service in the local network. Use the IETF standard protocols mDNS and DNS-SD (which are implemented in macOS under the name of "Bonjour" and in Linux as "Avahi") to take note of the offered services.
Tell the print clients that they can use the IPP protocol in order to get a query response when they make a get-printer-attributes request. This request will tell them which set of print options the devices support. The print clients can then show an exactly tailored print dialog to show to the printing user a selection of choices. The print client will also be told what job submission formats each devices supports. This MUST be either PDF or a simple raster format called "PWG-Raster".
So... where would you need a specific "printer driver" in such an environment? Everything and everyone can create PDF documents nowadays. Check! No need for a device-specific conversion to any other print language.
Are there printers which support IPP Everywhere already? Oh yes, look here -- they are all said to be fully compliant with the standard:
List of IPP Everywhere printer models
The .sln and .vcproj files you've been seeing in the CUPS sources are not meant to compile all of CUPS for Windows.
They serve to compile only a few of its utilities (such as ipptool.exe)...
Making the complete CUPS server+filtering code work on Windows would be a daunting task, since Windows spooling and printing is so much different from the Unix world.
CUPS uses Internet Printing Protocol for client-server communications. According to Technet article, Windows can be used as IPP host:
To enable a computer running Windows
Server 2008 to act as a server
supporting Internet printing, you must
install the Web Server (IIS) role, the
Print Services role, and the Internet
Printing role service in the Print
Services role.
Moreover, it seems that Windows, Linux and Mac OS X clients can use printers shared via SMB.
"Making the complete CUPS server+filtering code work on Windows would be a daunting task, since Windows spooling and printing is so much different from the Unix world."
Back in the dial up internet days, I ran into a problem where some IPS' had a replacement dll for modem functionality. The problem with it was that the dll prevented legit programs from accessing the modem until you uninstalled the IPS program.
This same technique can be used to create a Windows CUPS server by writing a Windows spooling and printing replacement program that, rather than printing directly to the printer, hands off the printing tasks to the CUPS server.
It would of course, take someone with in depth knowledge of the windows spooling and printing protocols.
cygwin ports has patch files for implementing a cups in (some versions of) cygwin. I can't speak to how well it might work.
https://github.com/cygwinports-extras/cups
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I downloaded Microsoft SDK and Visual Studio 2015 on Windows 10 and a shortcut to file WPCups.exe showed up on my desktop. It's located in C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules\TShell\TShell.
Some searching has turned up that it might be related to IP phones:
This is a CMD line utility to test and send ip over usb connectivity. Its included with the the WDK. It will connect to IPoverUSB.exe and will use RPC to talk to a Windows phone. It will drop a log file in your my documents folder that you may see also btw.
But it still seems odd to me, partially that it would install a shortcut onto my desktop. VirusTotal says it's clean, and IDA's disassembly looks like it's doing what the responder I quoted above says it should do, but I can't find any windows documentation, let alone a hash value.
In another forum someone mentioned that WPCups.exe is normally installed with Microsoft SDK, but I can't find any documentation confirming that.
It calls:
ADVAPI32.dll, KERNEL32.dll, WSOCK32.dll, WS2_32.dll, msvcrt.dll, IPHLPAPI.DLL, RPCRT4.dll.
Which seems reasonable.
I ran it on malwr.com but the analysis failed, that package "modules.packages.exe" start function raised an error...I suppose because of unmet dependancies? But the program looks like it should still end gracefully even without IPoverUSB.exe present.
Is anybody familiar with this file?
Update:
Because finding Windows documentation is apparently the most immediate path to madness:
From How Linux Works by Brian Ward
The standard printing system in Linux is CUPS (Linux CUPS), which is the same system used on Mac OS X. The CUPS server daemon is
called cupsd, and you can use the lpr command as a simple client to
send files to the daemon. One significant feature of CUPS is that it
implements Internet Print Protocol (IPP), a system that allows for
HTTP-like transactions amont clients and servers on TCP port 631. In
fact, if you have CUPS running on your system, you can probablt
connect to http://localhost:631/ to see you current configuration
and check on any printer jobs. Most network printers and print servers
support IPP, as does Windows, which can make setting up remote
printers a relatively simple task.
You probably won't be able to administer the system from the web
interface, because the default setup isn't very secure. Instead, your
distribution likely has a graphical settings interface to add and
modify printers. These tools manipulate the configuration files,
normally found in /etc/cups. It's usually best to let these tools do
the work for you, because configuration can be complicated. And even
if you do run into a problem and need to configure manually, it's
usually best to create a printer using the graphical tools so that you
have somewhere to start.
Many printers, including nearly all low-end models, do not understand
PostScript or PDF. In order for Linux to support one of these
printers, it must convert documents to a format specific to the
printer. CUPS sends the document to a Raster Image Processor (RIP) to
produce a bitmap. The RIP almost always uses the Ghostscript (gs)
program to do most of the real work, but it's somewhat complicated
because the bitmap must fit the format of the printer. Therefore, the
printer drivers that CUPS uses consult the PostScript Printer
Definition (PPD) file for the specific printer to figure out settings
such as resolution and paper sizes.
So, point Linux?
No, that has nothing to do with the Printing Deamon for Linux.
WPCups belongs to the TShell Powershell Module with is Part of the Development Toolskit for Apps which will be installed with the WDK.
I have a completely random error popping up on a particular piece of software out in the field. The application is a game written in VB6 and is running on Windows 7 64-bit. Every once in a while, the app crashes, with a generic "program.exe has stopped responding" message box. This game can run fine for days on end until this message appears, or within a matter of hours. No exception is being thrown.
We run this app in Windows 2000 compatibility mode (this was its original OS), with visual themes disabled, and as an administrator. The app itself is purposely simple in terms of using external components and API calls.
References:
Visual Basic for Applications
Visual Basic runtime objects and procedures
Visual Basic objects and procedures
OLE Automation
Microsoft DAO 3.51 Object Library
Microsoft Data Formatting Object Library
Components:
Microsoft Comm Control 6.0
Microsoft Windows Common Controls 6.0 (SP6)
Resizer XT
As you can see, these are pretty straightforward, Microsoft-standard tools, for the most part. The database components exist to interact with an Access database used for bookkeeping, and the Resizer XT was inserted to move this game more easily from its original 800x600 resolution to 1920x1080.
There is no networking enabled on the kiosks; no network drivers, and hence no connections to remote databases. Everything is encapsulated in a single box.
In the Windows Application event log, when this happens, there is an Event ID 1000 faulting a seemingly random module -- so far, either ntdll.dll or lpk.dll. In terms of API calls, I don't see any from ntdll.dll. We are using kernel32, user32, and winmm, for various file system and sound functions. I can't reproduce as it is completely random, so I don't even know where to start troubleshooting. Any ideas?
EDIT: A little more info. I've tried several different versions of Dependency Walker, at the suggestion of some other developers, and the latest version shows that I am missing IESHIMS.dll and GRPSVC.dll (these two seems to be well-known bugs in Depends.exe), and that I have missing symbols in COMCTRL32.dll and IEFRAME.dll. Any clues there?
The message from the application event log isn't that useful - what you need is a post mortem process dump from your process - so you can see where in your code things started going wrong.
Every time I've seen one of these problems it generally comes down to a bad API parameter rather than something more exotic, this may be caused by bad data coming in, but usually it's a good ol fashioned bug that causes the problem.
As you've probably figured already this isn't going to be easy to debug; ideally you'd have a repeatable failure case to debug, instead of relying on capturing dump files from a remote machine, but until you can make it repeatable remote dumps are the only way forwards.
Dr Watson used to do this, but is no longer shipped, so the alternatives are:
How to use the Userdump.exe tool to create a dump file
Sysinternals ProcDump
Collecting User-Mode dumps
What you need to get is a minidump, these contain the important parts of the process space, excluding standard modules (e.g. Kernel32.dll) - and replacing the dump with a version number.
There are instructions for Automatically Capturing a Dump When a Process Crashes - which uses cdb.exe shipped with the debugging tools, however the crucial item is the registry key \\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
You can change your code to add better error handling - especially useful if you can narrow down the cause to a few procedures and use the techniques described in Using symbolic debug information to locate a program crash. to directly process the map files.
Once you've got a minidump and the symbol files WinDbg is the tool of choice for digging into these dumps - however it can be a bit of a voyage to discover what the cause is.
The only other thing I'd consider, and this depends on your application structure, is to attempt to capture all input events for replay.
Another option is to find a copy of VMWare 7.1 which has replay debugging and use that as the first step in capturing a reproducible set of steps.
Right click your executable object and let it be WINXP compatible pending
when you discover source of the problem to finally solve it
I've been searching around and can't find a solution for this. The official NVIDIA Tegra 2 Linux SDK (L4T) doesn't include both XRandR or the VideoMode X11 extension for querying available video modes. My next thought was to parse the log file for video modes. Of course most of the time it's at /var/log/Xorg.0.log but I'd rather not always make that assumption. The XF86misc extension provides a way to get the log path but that extension is also not installed by default.
So I'm wondering if anyone knows of any other way to figure out what video modes are available and also what the current video mode of the display is.
The core X protocol does not mention modes. You have to use extensions. There's nothing wrong with that, that's what extensions are for.
Also, remember that there's no guarantee that the machine you're displaying on is the same machine as you're running on, so parsing the X log file is destined to fail if your app ever runs across the network.
I have been looking into the possibility of creating a soft copy(image/EMF file) of everything printed from Windows - for archival purposes. Does anyone know if it is possible to create a hooking DLL that can grab the printed data in such a general way?
A low tech way of solving it might be to install pdf printer driver as the default printer and remove all others and set it up to automatically write all the files to certain directory on the network and then write a tiny app on another computer to monitor that folder for changes and if any new pdfs appear just print them out to a real printer.
Edit: Otherwise there's apparently something called the Print Monitor API. Here's an article that describes using that from VC++ 6 and seems to be pretty much what you want (assuming it's still supported by the OS you use).
Having looked at this problem in more detail the best solution seems to handle it through Spooler notifications in the Win32.
Windows XP Embedded is missing the NULL or "NUL" device. For one thing, Visual Studio seems to require it and trying to build a project aborts with a PRJ0015 error.
Anyone know how to configure an XPe image to include support for the NUL device?
"Null Device Driver" is available in the XPe Target Designer, but it's normally hidden. Apparently each component has a visibility level, and if it's lower than that set in the Target Designer options (Tools->Options), it's hidden. Null Device Driver is at level 200, so I set the level to 100 and could see it and install it.
There's another important situation where you're going to want the NUL device: if you're installing some or all of the Cygwin UNIX solutions for Windows. In particular, if you're doing something like, oh, I don't know, to pick a completely random example, trying to put an SSH server on the damned thing so you can, just on a lark, say, log in and maintain it.
That's right-- Cygwin actually maps its UNIX /dev/null device to the Windows NUL device. You know, for maximum compatibility. Just in case the platform-specific implementation of IMMEDIATELY THROWING DATA INTO THE TOILET AND OBLITERATING IT, NEVER TO BE SEEN AGAIN, UNTIL THE HEAT DEATH OF THE UNIVERSE, happened to be novel and innovative.
While cygwin will INSTALL without NUL available, it will not, in fact, actually enjoy a typical work day. This is most evident the first time you try to launch a bash shell, and notice a slew of error messages about /dev/null resulting in no such file or directory errors. One presumes the device is perhaps actually just an NTFS link, but who knows.
In any case, the fix is to add the "Null Device Driver" component, helpfully located under Software -> System -> Other, a surprisingly small category which also contains such useful components as Internet Checkers, the Schedule Service Command Line Utility, the 1394 Kernel Debugger Support Library, EBCDIC support for Microsoft Bob, some cheat codes for Zork, and the code pages to say "(A)bort, (R)etry, (I)gnore, (F)ail?" in Muppet Swedish ("(B)ork, b(o)rk, bo(r)k, bor(k)?")
Hope this helps,
Matt "Breakpoint" Heck
Running Visual Studio itself on XP Embedded doesn't seem like it'd be supported. You should build on a full OS and then just deploy your application to XP embedded.