I've been using GSView 5.0 and GhostScript 9.52 to do postscript printing on vellums. However, today GSView started throwing error codes on every .ps file I've attempted to print. I'm using Windows 10 Pro and the printer is an Epson Artisan 1430.
The error is as follows:
GPL Ghostscript 9.52: **** Could not open file 00000e60.
Unrecoverable error: invalidfileaccess in showpage
Operand stack:
--nostringval-- 1 true
gsapi_execute_cont returns -9
gsapi_exit returns 0
I've tried changing permissions for the files and different printer drivers to no avail. I'm sorry I can't be more descriptive on this issue as it's hard to articulate.
OK... You must have recently updated to a new version of Ghostscript. I can reproduce your problem, and it comes down to a recent (documented) change in behaviour for Ghostscript.
Due to the well-documented public disclosure of security exploits using Ghostscript a couple of years ago, the current version (and any version since 9.50) now defaults to running in SAFER mode.
When running in SAFER, Ghostscript prevents access by the PostScript interpreter to the file system. For those unaware of the problem; PostScript is a full-blown programming language and, by design, permits programs to access the underlying file system. SAFER mode prevents this so that malicious PostScript programs cannot, for example, run arbitrary code on your computer.
It seems that GSView is using Ghostscript in a way which requires it to read the PostScript program to be printed using the PostScript interpreter, instead of the more normal practice of specifying the input file as one of the arguments. For simplicity the input file is granted read availability by the Ghostscript executable. I suspect that GSview is using the DLL directly and not adding that extra information.
Now there are ways to permit access to specific files or folders, so that existing PostScript programs can continue to work, but obviously this requires some changes in the calling application. GSview has not changed in, literally, years so obviously it does not take any such action.
You can, however, get GSview to work as before. Under Options select Advanced Configure. In the resulting dialog look for the 'Ghostscript options' text box. In there add -dNOSAFER, that should get it to work again, though you may have to reboot the computer if the OS print subsystem has stalled.
Yes, this does open you up to the sorts of exploits I alluded to above, you should only do this with PostScript programs that you trust.
Related
I was working on a Ruby program and had issues that I finally found out were caused by the default encoding in Windows 10 terminal, which apparently is CP850, an encoding so old it doesn't even include the € symbol. I read that, of course, if I try to change this other programs around the computer will give issues.
Wikipedia indicates that CP850 has theorically been "largely replaced" by Windows-1252 and, later, Unicode, and yet it's here, right in the OS's terminal.
Picture attached as proof. It's in italian language but you'll see it under "Tabella codici corrente", aka "Current code table".
How's that possible?
This is historical.
DOS had cp437, and later cp850 (and e.g. also cp852) as standard code page.
Terminal in Windows was also known as "DOS prompt": so a way to run DOS programs in Windows, so they keep the code page of DOS. Microsoft dislikes non-backward compatible changes, so your DOS program should works also on Windows terminal without problem.
Windows-1252, as the name stress it out, was done for Windows, so no compatibility problem, and for Windows programs, but so, in order to gain graphical interface market, but keeping compatibility with many business applications, Microsoft maintained two different code page.
I am invoking the following from a windows service under Windows 10 or Windows Server 2012 (C# program that shells out to execute the command), but nothing is being printed. I can copy and paste the command being sent into a command prompt, but it pops up a print dialog and I have to click ok for the file to print (which it does). What switch do I need to add such that the dialog won't come up and the file will be printed directly without user intervention since the intention is for this to work unattended as a windows service? This is ghostscript 9.50, which is the latest as of today. In an earlier version of ghostscript this worked if the device was set to ljet4 but this was causing an error with 9.50. Also, the output file did not have the %printer% prefix on the outputfile and previously it was prefixed with \\spool\. I have tried all of these combinations. Is it the mswinpr2 that is causing the unwanted dialog? I'm guessing this is what is preventing the printing to occur.
gswin64c -dPrinted -dBATCH -dNOPAUSE -dNOSAFER -q -dNumCopies#1 -sDEVICE#mswinpr2 -sOutputFile#"%%printer%%HP LaserJet Professional P1109w" "\\2-DYQJKC2\c$\Webs\myfolder\Public\Reports\HIPAACert\189\H01519447A2191016103332.pdf"
The mswinpr2 device needs to be able to select the Windows printer, yes. If it cannot for any reason (mistyping the printer name is a classic reason for example) then it will pop up the printer selection dialog. It has to otherwise it doesn't know where to send the output. I'd have to guess this is your problem (nothing to do with adding extra switches)
You should be using %printer% from the command line, you only need to double the % in a batch file, because batch file processing tries to interpret the % so you have to escape it. So if you are doubling the % in the command line then yes, it will indeed pop up a dialog box, because %printer% is not the same as %%printer%% so Ghostscript won't recognise this as a printer.
I'd suggest that you keep on working from the command line until you get a result, so don't double up the %.
Other than that, its difficult to comment. Do you get anything on the back channel (you'll want to drop the -q while debugging too) ? Obviously I'm not sitting in front of your system, so I can't see what the printer is called.....
FWIW I tried it here with the "Adobe PDF" printer and it works, but using the "Microsoft XPS Document Writer" does not, and in fact even selecting that from the dialog fails "Unable to open the initial device".
[edit]
A little debugging later....
The function DocumentProperties() fails with the Microsoft XPS Document Writer. I suspect this is because the printing system on Windows was significantly reworked for Vista and above, and Windows 10 does away with much of the legacy code. I suspect this old Win32 API call simply doesn't work with newer devices.
If your printer works when you select it from the print dialog, however, this is not the same problem. For me this printer fails even when selected from the print dialog. Seems its just not compatible with the old Win32 API.
NB this also displays the error "Printer StartDoc failed (error 00000006)".
So I still suspect that you have some problem with the printer name. Maybe a quick test would be to set the name to something really simple like '"Printer1' and try that.
I can't think of anything which has changed in the ljet4 device which would cause a problem, you don;t say what the error is, or even where it occurs, on the printer or reported by Ghostscript, so there's really nothing I can offer on that front.
I recently ran into the same issue. I added a -dQueryUser=3 argument. The documentation on the use of -dQueryUser=N can be found at:
https://www.ghostscript.com/doc/9.25/Devices.htm#Win
in the
10.2 Supported options (device properties)
section.
The code that illustrates this, in a batch file on Windows 10, is:
SET MY_EXECUTABLE_PATH=C:\Program Files\gs\gs9.53.3\bin
for %%i in (*.pdf) do "%MY_EXECUTABLE_PATH%"\gswin64c.exe -sDEVICE=mswinpr2 -dBATCH -dNOPAUSE -dPDFFitPage -dQueryUser=3 -sOutputFile="%printer%Printer_Name" "%%i"
I am trying to use an application called CLUT.exe which is an old application for MS-DOS that can be used to reindex NTX files for DBF databases.
(This is not the main topic, but I am just writing this if someone wants to test the app and don't trust at all about the content).
The problem starts when trying to run the command line version through console (cmd.exe) and this error appears:
C:\>CLUT.exe [arg1] [arg2] [arg3]
run-time error R6009
- not enough space for environment
So, according to what I've searched, this could be a possible solution:
http://support.microsoft.com/default.aspx?scid=kb;en-us;230205
but it doesn't work and every alternative that I found to solve this over the internet is the same.
Another alternative could be to make right-click in the .exe file, go to Properties then Memory tab and increase the Initial environment memory from Auto to the max value but it doesn't work too.
Well, I am stuck and no "possible" solution is working for me. If someone is interested, knows more about this issue and want to test, you can download the application from here (click "Free Download" green button):
http://www.filebasket.com/free/Development-Clipper-programming-language/clut-exe/13996.html
or directly from my DropBox:
https://dl.dropbox.com/u/15208254/stackoverflow/clut_214.rar
Just to know, I am using Windows 7 and the CLUT.exe application is a Clipper based app (old programming language) that may run under windows console (cmd.exe).
Wikipedia does mention other dos emulators but, oddly, doesn't mention BOCHS.
Reindexing NTX files is not a difficult thing to do, and can be done with tools other than CLUT. For example, many of the utilities listed on this part of Download32 could be used. Otherwise, you could write your own using Harbour Project or xHarbour. Or contact me off list and I'll cook up something in Clipper 5.3.
LATER
If I read the README correctly for CLUT, it's a replacement for the DBU utility that comes with Clipper 5.x. I can supply you with a build of that if you're unsuccessful with other approaches.
I have made a simple installer application in Delphi, nothing fancy. Basically I include files into the Exe, and then extract them to a user specified path.
I stumbled across a problem however, and I have noticed this works with ANY Windows Executable, it does not matter if it is an installer or not.
If an Exe is named, or contains the following words in the filename, "Setup", "Build", "Install" and maybe others, then.. whenever the Application is run and closed, Windows pops up a Product Compatibility Assistant dialog, saying the Application may not have installed correctly.
This is a problem, as even though the Files from my installer have actually extracted, and in my eyes the installer has done its job, Windows is complaining about it.
The only idea I have regarding this, is that Windows must check the filename of the Applications when executed, and in this case has identified it as an Installer. Windows must of then set a flag or something on the System, my Installer must then update this flag to say that the installation was a success?
Windows does not complain about this when debugging from the IDE, so it cannot be code related, it must be the OS - this only happens when launching the Application from Windows, not Delphi.
You can try this easily, either create an Application or rename one as Setup.exe, Run it and then close it - wait a few seconds and the Product Compatibility Assistant Dialog will show.
I don't know where to start investigating how to stop this dialog, or where a setting may be to tell Windows the Installer was completed correctly.
Appreciate your thoughts and solutions thanks.
If I recall correctly, this happens when your install app does not include an application manifest. When UAC was introduced, MS introduced a heuristic detection for installers and shows the UAC elevation dialog. The heuristic checks for names like setup.exe, install.exe. The simple solution is to include an application manifest. If it is an installer you probably want to use the requireAdministrator setting.
The feature is known as Installer Detection and is discussed here.
For what it is worth, I would always build an installer with a dedicated install tool like InnoSetup for example.
As David pointed out, MS uses some fuzzy logic to try to guess if the program is an installer. I wouldn't rely on this, as this is only for supporting legacy installer applications.
All new applications should have a manifest file, specifying whether it requires elevated privileges.
If an application has a manifest file that includes the requestedExecutionLevel directive, then Windows does not attempt Installer Detection.
Any program that is detected as an installer program but does not add a registry entry to the Add Remove Programs section of the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) will get the message "This program might not have installed correctly".
We have a Delphi program whose task is like a service program. It watches a particular folder for a certain period, and it works great on Windows XP and 2003, but on Windows 2008r2 64bit, when it wants to create an automatic folder, it will show this message:
The ... folder does not exist. The file may have been moved or deleted.
This message causes the program to halt, which is not good; it should not be interrupted.
What can I do about this?
P.S.: I really don't have any idea whether to post my problem in Stack Overflow or Server Fault, so I've guessed it should be here.
It's likely the VirtualStore, if you're trying to store beneath Program Files (either one). See my writeup:
http://www.clipboardextender.com/off-topic/vista-program-files-hide-and-seek
You've left out the ... folder name. While that's understandable, it wouldn't happen to have anything to do with program files (which on x64 will be split in 2 directories) would it?
Windows Server 2008 is able to use 'virtual' file pathes. That means: 'what you see is not what you get'. The Windows Explorer just shows you the 'display' name. Check the file path with cmd.exe, if the path you are trying to use does realy exist.
The reason is of cause the File Virtualization (see for example http://msdn.microsoft.com/en-us/library/bb756960.aspx and http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx).
Because we on stackoverflow.com and not on serverfault.com I want add to all other answers that you can use Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection and Wow64EnableWow64FsRedirection functions (see http://msdn.microsoft.com/en-us/library/aa365743.aspx) to control the File Virtualization in your program. An example of the usage of this functions in C# you can find here http://www.pinvoke.net/default.aspx/kernel32.wow64disablewow64fsredirection.
You'll need to tell us the exact path and how do you go about constructing it. It can be as simple as the app not using env variable expansion but assuming that user's folders are where they were before.
Path virtualization (there are 2 kids actually) that people mentioned will hit you only if your app is trying to mess with system folders.
More puzzling problem will hit you if you are not expanding env vars like APPDATA, LOCALAPPDATA etc. and not expecting that there's more of them on Win7 and 2k8. Not only that default paths of user's files changed but some of them can also be on network shares - for the same user. So if you were running based on expectation that all user's stuff will be at definite paths under say %USERPROFILE% you can get hit by several surprises. Also notice %ProgramData% .
Fastest way to find out - open cmd.exe, run set and if you see some paths that you are constructing in alternative ways, take notice that you need to start expanding env vars for them. Then open cmd.exe as a 32-bit app and check set again. You can also pick them up via Process Explorer from some running 32-bit or 64-bit app.
Switching your app to 64-bit build will resolve most of virtualization issues but not the env var expansion. Also if your app is touching system folders you need to request elevated run from the code or even better make the manifest and declare it there. Then OS will yell at user up front if his UAC is on and your app will avoid that 2nd virtualization. BTW, virtualization is controllable via group policies so it might be present on some boxes and missing on others.