I installed ghostscript on windows and added it to path variable but I'm still getting
gs is not recognizes as internal or external command
I tried to run the .exe file to check the installation and it says
This software us supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details.
Unrecoverable error: invalidfileaccess in .addcontrolpath
Close this window with the close button on the title bar or the system menu.
On Windows the Ghostscript executable is not called 'gs', it's called one of gswin32/gswin32c/gswin64/gswin64c, depending on whether you are using the 32 or 64-bit version and the command line or windowed executable.
So the error message doesn't make a lot of sense, unless it's coming from some other application. In which case you are presumably running something written for, or ported from, Linux. Or, of course, you are trying to run it from the shell by executing 'gs' when you should be using the actual executable name. If that's the case, try using the correct name.
More puzzling still is that the title of this question doesn't appear anywhere in your question body. You don't mention an invalidfileaccess, nor do you quote the back channel from Ghostscript which would give some clue what you are doing.
We really need to know more about what you are doing that doesn't work.
Related
I want to install ZeroMQ for Ratchet/PHP and I downloaded the installer from http://zeromq.org/distro:microsoft-windows. But I keep getting "NSIS error" whenever I try to install it.
It immediately shows after I run the installer. Different versions, x64 or x86 ones, none of them works. This problem only shows up with ZeroMQ installers.
Does anyone have any idea why does this happen?
P.S. I use Windows 8.1. (Up to date)
This question does not belong here on Stackoverflow but since you posted it here anyway I will give you the technical answer: NSIS needs to open a file handle to itself so it can read the compressed data, it does this by calling GetModuleFileName to get the path and CreateFile to open the file. If this step fails it displays the _LANG_CANTOPENSELF message ("Error launching installer", the text in your screenshot).
A) GetModuleFileName can return a "incorrect" path when filesystem redirection is involved, this is most commonly seen when psexec is used to execute the program from the Windows directory on a remote 64-bit computer and this is probably not the case here?
B) The call to CreateFile can fail, this is most often caused by Anti-Virus software holding a lock/denying access to the file. Try to disable/uninstall any 3rd-party Anti-Virus software...
I've copied Rebol3 to my computer under windows. I am running it from the download not a full install, and it and seemed ok.
I tried using some very simple sample code for the GUI in the console and it fails with various error messages.
If I put in view [ and type enter it tells me its a syntax error (this works in reb/view 2).
Its a win 7 machine.
Version of Rebol3 is 2014-03-04 04:54
When I used help and typed the command what, view wasn't listed as a command.
Note the runtime support for the Rebol3 GUI dialect is not available in the "core" builds available at http://rebolsource.net.
Currently the GUI dialect is available in Linux/Android and Windows builds from Atronix Engineering:
http://atronixengineering.com/downloads.html
Or from Saphirion AG:
http://development.saphirion.com/rebol/saphir/
Note that the GUI behaviors in Rebol3 are similar to Rebol2's VID but has some differences, and is called R3-GUI. For a tutorial you might try Cross Platform App Development with Rebol 3 Saphir
Also notice that before invoking VIEW you will have to LOAD-GUI.
If I put in view [ and type enter it tells me its a syntax error (this works in reb/view 2).
The Rebol3 console is more basic than the Rebol2 console, and unfortunately doesn't support multi-line input at this time. You can only enter complete expressions before hitting enter, not partial ones. So hitting enter while there is still an unclosed bracket will give you an error. However if the code you're putting in is coming from the clipboard you can use do clipboard:// (via #GrahamChiu)
While Rebol3 currently lacks the behavior, it's encouraging that the Red console handles multi-line input in the Rebol2 way.
I am running it from the download not a full install
And the good thing is that you can run it from the download with no install. Because there is no install. :-)
I'm making a program called Pwn16. It allows 16-bit applications to run on 64-bit systems by emulating an Intel 8086/Pentium processor and a DOS/Win3.x/Win98 system. Pwn16 uses a small loader program that detects when Windows gives the "not 16-bit compatible" messages (including the one from CMD) and when it notices said message(s) being summoned, it will close it and instead automatically launch Pwn16.
Are there any libraries that will let me "capture" these messages and do something else in place of the errors? I'm making most of this in VB6, so any code that can do this will also help. I have the emulation and GUI down, I just need to get this loader done to finish it.
Messages I need to capture:
"The version of this file is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need an x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher."
"Unsupported 16-Bit Application: The program or feature '(file)' cannot start or run due to incompatibility with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available."
"This is not a valid Win32 application."
"The (file) application cannot be run in Win32 mode."
Thanks.
As far as I know, neither Explorer nor cmd.exe check the validity of the executable file in advance. Instead, they call CreateProcess and, if it fails, look at the error code returned.
So, if you hook calls to CreateProcess (or perhaps the underlying native API) you should be able to capture the error code being returned to Explorer/cmd.exe/whatever and do your thing instead.
I don't think capturing the message being presented to the user is going to be helpful. Quite apart from the inefficiency involved in examining every dialog box, and every piece of text written to every console, to see whether it contains the message you're looking for, how would you then identify which file the user was trying to run?
I have set up shuffle_play.rb in Ruby by Example to work on Windows, with mpg123 instead of ogg123. The critical part is a method called play_file, which initially I wrote like this
def play_file(file)
system("mpg123 \"#{file}\"")
end
I have mpg123 in the same directory as my script ... it didn't work. But this does work:
def play_file(file)
system("mpg123.exe \"#{file}\"")
end
I reckon it's because I don't have working directory in %PATH% (and indeed the problem goes away when I add it) but even then I don't know enough about Windows to know the difference. Could someone explain the rationale for this?
Probably the examples assume that you're on a *nix variant such as Linux or Mac. In those Operating Systems, the program is called mpg123, because those OS, don't care about extensions, the just check that the file has an executable attribute
On windows things are very different. Windows decides if something is a program depending on the extension (.exe, .com, .bat, .cmd, etc.). So the program in windows has to be called mpg123.exe. If you open a command line on windows, you can run the program without specifying the extension, as windows automatically tries the different extensions. This behaviour of trying different extensions happens ONLY in the command line and not when you try to invoke a program from another one.
There a environment variable called PATHEXT that list in which order windows tries the different extensions. On my computer that list is:
C:\Windows\System32>echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.RB;.RBW
I hope it was clear. And a suggestion if you want to code in ruby, install Linux or get a Mac.
this is not yet another "I need a console in my GUI app" that has been discussed quite frequently. My situation differs from that.
I have a Windows GUI application, that is run from a command line. Now if you pass wrong parameters to this application, I do not want a popup to appear stating the possible switches, but I want that printed into the console that spawned my process.
I got that far that I can print into the console (call to AttachConsole(...) for parent process) but the problem is my application is not "blocking". As soon as I start it, the command prompt returns, and all output is written into this window (see attached image for illustration).
I played around a bit, created a console app, ran it, and see there, it "blocks", the prompt only re-appears after the app has terminated. Switching my GUI app to /SUBSYSTEM:Console causes strange errors (MSVCRTD.lib(crtexe.obj) : error LNK2019: nonresolved external Symbol "_main" in function "___tmainCRTStartup".)
I have seen the pipe approach with an ".exe" and a ".com" file approach from MSDEV but I find it horrible. Is there a way to solve this prettier?
This is not behaviour that you can change by modifying your application (aside from re-labelling it as already discussed). The command interpreter looks at the subsystem that an executable is labelled with, and decides whether to wait for the application to terminate accordingly. If the executable is labelled as having a GUI, then the command interpreter doesn't wait for it to terminate.
In some command interpreters this is configurable. In JP Software's TCC/LE, for example, one can configure the command interpreter to always wait for applications to terminate, even GUI ones. In Microsoft's CMD, this is not configurable behaviour, however. The Microsoft answer is to use the START command with the /WAIT option.
Once again: This is not the behaviour of your application. There is, apart from relabelling as a TUI program, no programmatic way involving your code to change this.
Maybe write a console-based wrapper app that checks the parameters, prints the error message on bad parameters, and calls/starts up the actual program when the parameters are correct?