I am currently testing the GTK Application that I built on windows using the MSYS2 64bit shell.
For the program to be able to run outside of the shell, I packed all the required DLLs with it as well as the following:
FOLDER\lib\gdk-pixbuf-2.0\2.10.0\loaders\\*
FOLDER\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache
FOLDER\share\glib-2.0\schemas\gschemas.compiled
FOLDER\share\icons\Adwaita\\*
FOLDER\share\icons\hicolor\\*
The good news is: It works :) And it also works flawlessly on another PC that doesnt have GTK/Msys2/whatever installed.
The bad news is: On yet another PC (I have tested it on 2 other Systems other than my developing System so far, one one of them it works flawlessly), the program itself works, but the GUI is not rendered sharply (texts are blurry).
Do you guys have any idea on what could be the reason for that? I'm guessing it could be one of the following:
The affected system could have some general display problems that have nothing to do with my app.
The gschemas.compiled file does not suit the affected system. In that case I would probably have to create that file dynamically, but I have no idea how to do this.
I am missing some file from GTK or Glib that would solve the problem.
I am thankful for any help :) Compiling/Deploying a GTK App for Windows has proven to be a pain in the ***, but since (almost) everything works now, I feel like its not much that I am missing unless I have overseen something critical.
Regards,
tagelicht
Given the way you created your package, my bet is that you are missing some components, making the drawing code use some fallback routines, hence the "sharp" drawing.
Try to run the application in command line on the machine where your have the problem, to see if there are some unusual warnings you don't have when running it on your machine.
See also my answer on how to distribute a GTK+ application on Windows.
Related
I have a small project I work on in my free time that runs 32- and 64-bit assembler code from managed .NET assemblies based on the operating system I am on. You can see the techniques I use to get the shell code to run in the template, pretty basic stuff.
https://github.com/brandonprry/metafang2/blob/master/MetasploitPayloadUtility/GeneralTemplate.txt
The methods work on Windows and Linux just fine, but I expected the Unix way of executing the code would work on Mac and doesn't. With SELinux enabled (and I am sure other like pax and grsec), it does not achieve execution. This is totally expected though.
My question is, what does a Mac do to protect its memory? Does it have similar mechanisms like SELinux?
On an slight tangent, if it does, I was looking to implement something similar to the code at the bottom of this page to circumvent SELinux and to see if it worked on my Mac as well.
http://www.akkadia.org/drepper/selinux-mem.html
I'm using node-webkit to build a self-contained web app demo, and for some reason, the -webkit-backface-visibility CSS3 property doesn't work – but only when I run the app on Windows, not on Mac.
When I say it doesn't work, I mean it's exactly as if the property isn't supported: when I flip an element over on its back, I see it reversed, rather than hidden.
The issue isn't only with my particular code, either, as online demos of -webkit-backface-visibility (like this one) don't work when I run them in the app on Windows:
Is this a bug in node-webkit? Is there any way I can get this to work?
Well, it sounds like a bug. It might be the same issue that causes WebGL not to be available with specific hardware/driver combinations on Windows:
https://github.com/rogerwang/node-webkit/wiki/Webgl-support-on-windows
On Windows with some hardware and driver, WebGL won't work until you copy D3DCompiler_43.dll and d3dx9_43.dll to node-webkit's directory, or install DirectX 9 redistributable.
For license reasons we cannot ship those DLLs.
This seems to have fixed a similar problem with backface-visibility reported here:
CSS: backface-visibility and perspective doesn't work
It WORKS! Thanks a lot! I've added two dll files two node-webkit package and it works!
For a university course I have to write a http server which is supposed to run on both Linux and Windows.
I have got a humble Linux machine which I don't think can handle any kind of heavy virtual environment, neither I'm willing to go through the hassle of installing it.
This is the first project of mine complex enough (I estimate ~1.5 months to develop) to require an environment sufficiently comfortable to alternate rapidly between short coding and testing sessions (the latter on both platforms, of course).
So, I was wondering what could be the best set up for this situation. I think testing it on Wine would be ok (it is not a real-world thing, after all), and I installed MinGW for the Windows-targeting part.
Basically, a simple well-written makefile could solve my problem... It should build both the Linux and Windows binaries and place them in the respective folders (the Windows one in the Wine sub-tree) and I'm all done! But I feel very inexperienced in this thing and I really don't know where to start. Maybe the make manual, ahah!:)
Thoughts, suggestions, anything I didn't think/know!
Thank you!
(PS. I'm planning to use emacs as editor, or maybe learn vim. Unless eclipse provide some kind of skynet-like plugin that entirely solve this problem...:)
You're on the right track. It's not that complicated, really, thanks to MinGW. You basically need two things:
The code has to be portable across the OSes. MinGW has some POSIX support, but you'll probably need to either use Cygwin in order to be able to use the POSIX interface or have your own compatibility layer for interfacing with the OS. I'd probably go for Cygwin as then you can code only against POSIX and won't have to test and debug your compatibility layer. Also, make sure you won't use any external libraries that are OS specific. Non-portable code often results in a compile error, but make sure you test the application thoroughly anyway.
The toolchains for targeting Linux and Windows. You already have them, you just need to use them correctly. Normally you'd use a variable like $(CROSS_COMPILE) as a prefix when calling the toolchain during cross compilation. So when compiling for Linux, you call gcc, ld, etc. (having the CROSS_COMPILE variable empty), and when compiling for Windows you call e.g. i486-mingw32-gcc, i486-mingw32-ld etc., i.e. CROSS_COMPILE=i486-mingw32-. Or just just define CC, LD etc. depending on the target.
I wrote a small game on Linux and made it run on Windows as well. If you browse the code, you can see the code has next to no #ifdef jungle (basically just some extra debugging features enabled for Linux), and the Makefile is simple as well, with no complicated handling for cross-compilation, just the possibility to override CC etc. like it should be. As lots of important open source software is written this way (especially software that's used by the desktop and embedded devices), you should also be able to find lots of other examples on how to set up the build environment correctly.
As for testing the application on Windows, I think the best option is if you can find a real Windows machine somehow. If you do everything correctly, it should run the same as on Linux and you won't need to continuously test your application on both OSes. If testing on a Windows machine is not possible, a VM would be the next best choice, though it would probably be more difficult to set it up. Wine is a good backup plan, but I don't think you can be sure your application works well on Windows if you only tested it on Wine.
Another developer at work told me it wouldn't work for some reason specific to Visual Basic 6 applications.
But I think it should work as long as you include the correct DLLs and runtime files, isn't VB6 compiled to machine code?
EDIT: I just mean in general should it be possible. I'm going to actually test this out in a few days as long as nobody gives me a theoretical reason it won't work.
EDIT 2: I think the developer was referring to P-code, which vb6 can optionally compile to instead of binary which runs under a virtual machine similar to (or the precursor of) the .Net framework.
I've tested a large VB6 app in Wine under Ubuntu. Event the msi installer worked fine. Had some troubles with low-level implementation details (e.g. in NM_CUSTOMDRAW on CDRF_NOTIFYITEMDRAW phase the hDC text is not transparent by default as in Windows common controls). So yes, even heavily subclassed stuff works. I just had to iron those minor glitches.
Here is a function that checks if app is running under wine
Property Get IsWine() As Boolean
IsWine = (GetProcAddress(GetModuleHandle("kernel32"), "wine_get_unix_file_name") <> 0)
End Property
Take a look at this http://appdb.winehq.org/objectManager.php?sClass=application&iId=7361
It looks like you can get most VB6 programs to work.
I would like to build a GUI for an OCaml application I'm writing. My first idea was to use GTK+. I would like my application to run on Macs, Linux, Windows with a natural look and feel. I know that, while GTK+ uses X11 on the Mac by default (which looks awful), there is gtk-osx-application which uses quartz and looks natural and which I've just installed using macports.
I have three questions:
(1) Is it actually possible to use gtk-osx-application +quartz+no_x11 with OCaml? (My GODI installation which previously (with x11-based gtk2 in place) installed lablgtk2 with no problems, now (with gtk-osx-application +quartz+no_x11 and the previous x11-based gtk2 removed) is complaining about not finding /opt/local/lib/libgtk-x11-2.0.0.dylib, which is x11 related. But, as far as I know, there's no way to choose quartz over x11 when installing lablgtk2 through GODI.)
(2) If I develop my code on my Mac using the gtk-osx-application, can I use the code as is for compilation in other platforms which use different GTKs or can this bring problems?
(3) If it does bring problems, do you know of any other environment for developing GUIs in OCaml that may potentially be good regarding both look and feel and still be readily cross-used? (I am aware of labltk but I'd prefer something with more capabilities, for example, the ability to use notebooks, a.k.a tabbed panels, and being able to use Glade for rapid GUI design.)
Thanks for any help!
Cheers,
Surikator
Assuming you can get lablgtk to work, it is probably your best bet at present.
To get it working: have you tried rebuilding lablgtk after removing X11 GTK and installing Quartz GTK? A LablGTK built against X11 GTK naturally won't work on a Quartz GTK, as it will be linked against the wrong library, but a rebuild might be successful. It could also be that LablGTK won't correctly detect that X11 integration calls don't work and therefore fail to build, but I would expect that to be not-too-difficult to fix as LablGTK does support Windows.
If you develop code for GTK on Mac, it should work on other platforms just fine. You'll want to test it, of course, but it should work. Do be careful to use the GTK facilities to make things like dialog button order work properly.
I think there was at one time a set of OCaml bindings to wxWidgets, but they do not seem to be widely used and wx is painful to work with in my experience. There has also been some work on making Qt bindings, which would be awesome, but I don't think there are any projects with good headway on that front yet.
If the UI is a small-ish piece of your project, you could look at decoupling it from the backend and writing the UI in C++ with Qt, or writing platform-native UIs, and having the UI call out to OCaml code in an embedded runtime to get the real work done. But that is likely more work and may not give you much benefit, depending on your application.
So: GTK is your best option in the current landscape.