I've written a program in Haskell that's going to be run on a Windows 7 machine. It's not my machine. I don't get to choose the OS.
It's been written using the ncurses package, and compiles just fine on my (Ubuntu) machine. Unfortunately, it won't compile on Windows, even under Cygwin. It gives me a very unhelpful error (Process exited with code: ExitFailure 1) when it tries to build the ncurses package.
I've tried specifying the exact locations of the header and dll files for ncurses to no avail.
Is there anything I can do, short of re-writing the software to use a different package?
In hindsight, I should've checked that it would compile under Windows some time ago, but since I've successfully used ncurses in C on Windows in the past, I had no reason to believe it wouldn't work.
My current code is available on GitHub.
Edit: If I were to re-write the IO parts using something else (as an absolute last resort) I would need to be able to do the following things:
determine the number of rows and columns in the terminal
be notified if the terminal is resized
be notified when a key is pressed (including arrow keys and function keys, without line buffering)
control the position and visibility of the cursor
disable echoing of standard input
change text/background colour
...and I would need to be able to do these things in both Windows and Linux.
Related
I use gopacket in my program. on linux, it runs perfectly.
But on windows the whole program crashes if i did not install WinPcap before.
My plan was to check if WinPcap is installed, and if not to inform the user that he needs this to use 100% of all features.
But i dont come to this point. i cant use gopacket if WinPcap is not available. I mean... not a single line of code of it (=> crash)
Has anyone an idea how i can solve this? im do not need gopacket actually. My plan was, if it is installed, fine, super! If not, dont care... do other things.
But now i have 2 choices... remove gopacket totally or find a way to start my program without the need of wpcap.dll. at least to tell the user that he needs it.
Please help me :(
You're wrong in that you are «not [using] a single line of code of it»: it's not hard to see that
its Windows-specific code calls into winpcap.dll.
What is more fun, is that
its Unix-specific code calls into libpcap.so, and this means you have it working on your local system simply due to the fact you have libpcap package installed (or whatever it's named in your code).
All this means that currently your program is not really portable
anyway (I mean, in the sense you supposedly think it is portable).
You can run something like
$ ldd ./yourbinary
and see it printing a reference to libpcap.so of some version.
There are several ways to solve this.
The easiest is to just try shipping winpcap.dll with your binary. Windows by default looks for DLLs in the current directory of the application trying to load them. Since gopacket uses cgo, it means the winpcap.dll is attempted to be linked it at the application startup, so the application has no chance of changing its working directory before that library is attempted to be found and linked in.
A more complicated approach is to make (or obtain) a static version of the winpcap library (remember that DLL is a library, just a special form of it) and then jump around building gopacket so that it picks that static library.
Install Npcap in "Wpcap API compatibility mode".
first off, I really need to make a 64bit version of glfwdll.a and glfw.dll (so I can hopefully finally succeed in getting the Go glfw bindings to work under Windows ... was a breeeeze under Linux!)
Seems like I now succeeded in compiling 64bit versions of glfwdll.a and glfw.dll using mingw64, MSYS and their make scripts, even though I did get a couple of error messages along the lines of "maincrt entry point not found, using default 0xsomehexnumber instead" or some such. Entry points of course refer to executables, in this case those in the examples directory.
And indeed, most of them don't work! All got built however. The following executables work:
listmodes.exe mtbench.exe mthello.exe and particles.exe -- the latter being the only graphical (3d gfx) example working for me (the former ones just outputting some test infos onto the console window).
Now what's the issue with the other ones? They don't crash, they don't report anything to the console... I run them, they return immediately, silently.
Is my GLFW build broken? How to fix? What's the big difference between the 4 examples that work and the others that don't?
This is a fairly new, vanilla Win7 64bit installation. No crapware, everything up to date, UAC and Themes are off, not a lot of software installed at all, Nvidia GPU driver updated (GPU Caps Viewer and the likes run fine, so OpenGL is there).
I'm not yet allowed to add comments, so I'll post this as an answer.
The issue you're having is due to three separate bug in GLFW. I fixed them today and the fixes will be included in GLFW 2.7.6. Until then, you can use trunk from the GLFW Subversion repository.
To be sure that you really have no DLL-hell issues with the opengl32.dll, glu32.dll, glut32.dll etc., check out the Event Viewer tool and see if there are some warnings or errors for you app.
This is my thought because you are only able to run the mtbench and mthello which have nothing in common with the "real" OpenGL API.
No clue about particles.exe though - maybe GLFW checks for errors internally and call the exit() routine ? Check the %errorlevel% also.
Also take a look here:
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/pong3d.c?revision=1110&view=markup
There is a GameMenu() function which may exit silently if "!glfwGetWindowParam( GLFW_OPENED )", which obviously means that OpenGL was not initialized.
The same function serves as an exit flag here
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/wave.c?revision=1110&view=markup
Once again, double-check the DLLs !
I believe that you are experienced not to make "advanced" mistakes in the build process, so there just might be some funny thing happening at the "user level".
And another suggestion:
http://sourceforge.net/projects/glfw/forums/forum/247562/topic/3868944
Some parameters might not work exactly for you.
To "fix" the samples try commenting out the glfwGetWindowParam call.
I have a Python program that is mostly complete, and there is one thing that I'd like to change, which may or may not be possible.
This program uses PyQT to display a GUI and I have it pretty much pinned up so I was wondering if I can make Python not open up a termianl when I open the program.
I am using Windows XP right now, but the machines it will run on will be Windows 7. I generally work with Linux, so I'm not terribly familiar with Windows.
If the terminal has to be there, it's no big deal, but I feel like it's extraneous at this point.
Thanks!
Use the python extension .pyw.
E.g program.pyw
This causes your program to be run with pythonw.exe instead of python.exe which suppresses the terminal.
Well, I'm using Visual C++ 2010 Express and ResEdit
for my midi sequencer's SETUP app.
Win32 API, no MFC, some custom window and control classes and such.
Now that I got Windows 7, my dang SETUP program is broke.
Windows gives me the ole "Did this app install correctly??" thingy.
Which implies that SOMEthing is wrong with my installer.
I'm tryin' to figure out what that might be...
I've seen these 2 SO threads:
"This program might not have installed correctly"
"This program might not have installed correctly" message in Windows 7 RC
Which have lead me to these places:
http://msdn.microsoft.com/en-us/library/dd371711(VS.85).aspx
http://msdn.microsoft.com/en-us/library/bb756937.aspx
http://msdn.microsoft.com/en-us/library/aa905330.aspx#wvduac_topic3
http://blogs.msdn.com/b/cjacks/archive/2009/06/18/pca-changes-for-windows-7-how-to-tell-us-you-are-not-an-installer-take-2-because-we-changed-the-rules-on-you.aspx
http://community.flexerasoftware.com/archive/index.php?t-189007.html
Only registry entries I use are the standard uninstall spot and
associations for filetypes.
SETUP writes a dat.cfg file in program files\pianocheater dir
that points to where all the app's data is. (just a text file with a path in it)
(And an etc.cfg for a temp dir within that data dir to use.)
So I'm only READING from programfiles\pianocheater post SETUP.
Can anybody think of why Windows wouldn't like the install?
Source code is at http://shazware.com/_etc/SETUP_PIANOCHEATER.cpp
It uses my library of window, control classes similar in spirit to mfc.
I could send useful parts of it, too.
It's not toooo bad for a setup app.
Should be pretty ledgible for a win32 guy/gal.
I could uuuuuse some he'p...:/
Oh yeah, I should point out that Go() is the entry point instead of main().
The DBG()s just do OutputDebugString() and seem to all run just fine.
TStr is just a big char[MAX_PATH] (and I don't do unicode)
And the trick PROBably is that I'm on win7 64 bit, but this is a 32 bit app.
I'm pretty sure I'm using the registry correctly for assoc's and uninstall spot, though.
So is THE thing I SHOULD do the manifest xml thing?
Or is there a more correct way to do things?
thanks much,
...Steve
First off, check whether that message is a false positive or not. The message you're seeing is designed to use heuristics (which can be wrong!) to determine if an installer failed due to Windows Vista/7 compatibility issues. If your installer is in fact compatible with Windows 7/Vista, then all you need to do is add a manifest declaring itself compatible. You'll also want to add a requestedExecutionLevel entry to your manifest as well to request elevation.
If your installer is in fact failing, of course, then you ought to fix that first.
Finally, if the error is showing up because a launcher executable exits early or something like that, consider suppressing installer detection by adding the appropriate manifest entries to the launcher as well (you may be able to use a requestedExecutionLevel of asInvoker if the launcher doesn't need administrative access; the presence of a requestedExecutionLevel manifest entry should suppress installer detection). Note that you should make sure you use ShellExecute to invoke your main installer process, not CreateProcess, or UAC may not elevate the child process.
I ssh into a linux VM which is setup remotely. I use Vim to write my code. For debugging however, I use netbeans through X11 which can sometimes be painfully slow. I tried using gdb buts its an efficiency killer. I love to hover over my variable and get to now their value rather that doing p variable_name , plus I like see and navigate through the code. Is there something light simple gui based debugging tool I can use. I have tried to use clewn http://clewn.sourceforge.net/ , but that doesnt work because it has a missing netbeans_intg feature. Is there any other similar vim gui based debugging tool ?
You can try ddd
which is a gui for gdb, I think it's lighter than netbeans.
cgdb is an interface to gdb but it is not a graphical one. It does not offer the possibility of hovering over a variable, but it shows you a window with the source code.
Well, I was in sort of your situation sometime ago, and you can have a look at my question about using gdb with remote sources.
First of all, your problem with netbeans_intg feature is related to vim which has been compiled with no support for it. If you can rebuild vim yourself, you can then enable it. Otherwise, as you can see in the answer that I gave myself to my question, you can leverage clewn's remote-vim capabilities.
In a nutshell, you can have a "local" vim (i.e. on a desktop/laptop machine presumably), which must still be built with netbeans_intg support, but now it is a vim under your complete control (i.e. it's on "your" machine), while clewn will run on the linux host where gdb and your debuggee will run.
You can then keep the source files on your desktop/laptop and have the remote clewn sort of "drive" your local vim to the proper source files while debugging.
IOW: clewn will get information out of gdb to know exactly which file/line you're into and connect to remote vim and tell it: "hey, go grab this file and show it around this line", highlighting current line, breakpoints etc.
This is a great solution for when you have far-away deployed systems and you need to debug them with minimum impact on the host where they are running, and presumably no option to transfer there all of your source files.
I don't know if this fits in any way with what you're trying to do, but it did really change things for me.
Hth,
Andrea.
Check out GDB server. Theoretcially, you should be able to start gdb on your linux machine in server mode and connect via GUI of your choice. As long as that GUI supports remote gdb connections, which Netbeans does.