I need to support Windows 98. The Qt documentation claims this is possible, but there are no instructions. The distributed binaries of Qt 4.6 don't run on Win98 and the majority of Qt applications I have sampled also don't. For several apps that do run on 98, I have asked authors how they did it, but the common answer is that it was accidental and they don't know what factors caused it.
In searching the forums for help, I found only guesses that turned out to be wrong. For example, one belief is that to compile for Win9x, you must build the tools and the apps on that platform. Yet, things I found to run were built on newer versions of Windows.
What is required to build the Qt dev tools and then applications for Win98?
How about cross-compiling from WinXP or Linux?
Are there specific components that can't be made to run on Win98?
Are there particular difficulties with dynamic or static linking for Win98 support?
Here is as far as I'm going to get on this:
You can target Windows 98 using MinGW or VC++ 6 SP5 from any Windows version. Cross-compiling from Linux is doable but not easy to set up.
Qt 4.4.3 was the last version officially tested on Win98. To run the distributed binaries on Win98, you need to install older versions of glu32.dll and opengl32.dll that are available from Microsoft. Due to an unresolved bug, Assistant will launch but can't load the help files. The alternate version in the bin directory, assistant_adp.exe, works fine. It seems the only other potential problem is that QtOpenGL may use features not available on older boxes.
Qt 4.5.3 appears to be still compatible except for WebKit, OpenGL, and Phonon. QtOpenGL expects OpenGL 1.5, which I don't know is even possible on older boxes. I didn't look into Phonon deeply enough to see exactly what the problems are. QtWebKit now requires Win2K or better. The distributed binaries work mostly OK. Assistant depends on QtWebKit, so will not launch, but assistant_adp.exe still works.
Qt 4.6.3 distributed binaries are now completely incompatible with Win98. It may be possible to get some things working with MinGW 4.4 and a lot of hacking.
Building Qt Creator requires Qt 4.6.0 and either MinGW 4.4 or VS 2008.
Wow...interesting mission.
So, basically - yes, there is windows 98 support for Qt. The problem is that there is one big IF. For example if you even try to set some different QTextCodec::codecForName, you'll have to provide 3rd party ttf for this purpose, because in most cases Win98 will not recognize it as valid. If you provide the exact error, while compiling it on win98 machine, I could help you.
"How about cross-compiling from WinXP or Linux?" - If you use ONLY Qt libraries everything goes fine. Otherwise in .pro file, you have to link these libs under win32 and unix conditions. So you could even forbid your code, to be compiled and executed in other systems...
"Are there specific components that can't be made to run on Win98?" - Of course. In .pro file you could include different libraries, for different operating systems.
"Are there particular difficulties with dynamic or static linking for Win98 support?" - As far as I know - there isn't.
//off - But it still strange, that someone want to write application for win98, today...
Related
Similar to this question about GTK+ 3 for Windows, is there any place that offers compiled GTK# bindings for Windows? I searched for a while and can't find any official releases (which makes sense since there are no official GTK3 releases for Windows either), but also neither Banshee nor Xamarin come with GTK(#)-3.
I'm also unsure if these instructions for compiling GTK# 2 on Windows are still valid, but the page doesn't provide an awful lot of detail, so I guess it'll take half a day to figure out of it works that way.
Any other place where I might find the GTK# 3 binaries for Windows?
You can get the c# binding for GTK3 from:
https://github.com/mono/gtk-sharp/releases
This includes a windows installer.
These bindings are pre release and are versioned as Gtk# 2.99.3
My understanding is that the version will change to 3.0 when it is released as stable.
I've been using Qt for several months now with no problems. I originally downloaded the Qt 4.8 library with the most recent Qt Creator as of summer 2012, and I was able to start constructing my application. My application has demanding graphics needs, so I've been using the great windowing context Qt provides for OpenGL.
I've been slowly building my skills. I have explored programable shaders with success, and I wanted to leverage the power of Geometry Shaders. I am running OS X 10.7.5 on a MacBookPro6,2 with a GeForce GT 330M GPU. According to what I've read from others here, the upgrade to OS X Lion included a driver to run this GPU under the OpenGL 3.2 Core Specification, including support for programable Geometry Shaders. I also read here that while Qt 4.8 did not support OpenGL 3.2 on OS X, this support was included in their recent release of Qt 5.
I saw that Digia had also released an update to Qt Creator, so (being a little too excited for this potential breakthrough in my work) I uninstalled Qt and downloaded the Qt 5.0.0 library + Qt Creator 2.6.1. I went through the steps in the wizard, started up the new Qt Creator and now nothing works, haha. I have developed a love-hate relationship with my compiler and the cryptic messages it gives me, but this is different. The errors that are being thrown make it sound like it doesn't know how to read the code any more (just to pick one example out of several hundred errors "#include "). The wizard installed Qt fine, and all the guts are there, but I think the link to my gcc compiler has somehow been broken. Not even the examples that came with Qt 5 compile.
Qt has introduced a new "kit" paradigm to make developing on multiple platforms easier, and I have made efforts to change the setup of the kit. Qt detects several gcc compiler options, which I have tried, and I have manually pointed it to the path I get from the terminal command:
which gcc
/usr/bin/gcc
It appears to be gcc 4.2. I see that the most current version is gcc 4.7, but I have the most up-to-date version XCode provides. I also downloaded "Command Line Tools" from XCode and restarted, but it did not remedy my problems as magically as I had hoped. I am trying to update gcc manually, but I'm running into issues because it is asking me to update gmp and mpfr as well, and they are not fully cooperating.
Since the kit paradigm allows multiple libraries to co-exist in Qt, I re-downloaded the Qt 4.8 library, but it suffers from the same problem. I have pointed Qt Creator to qmake for both the 4.8 and 5.0 libraries, but that doesn't seem to be the problem either.
I haven't been able to see evidence of anyone else running into such a crippling problem, so that suggests that I am missing something simple. But even for being a newbie last summer, I felt I had gotten pretty comfortable with Qt, C++, and OpenGL from what I have managed to piece together from the Internet.
If anyone can nudge me in the right direction, I would greatly appreciate it. I am willing to rebuild my application from scratch in Qt 5.0, but I can't use Qt at all at the moment.
I finally got it to work! In the directory /usr/bin/ there was more than one g++ executable. They were labeled with different version numbers (g++-4.0, g++-4.2), but they showed up in Qt's automatic detection. All I needed to do was delete the extras. Leave only the g++ executable that is not labeled with a version number. By limiting the options available to Qt, it automatically selected a compiler and now it works.
It is embarrassing that it took so long for me to find such a fast solution, but it is still a relief. I hope others save time from my experience.
Ok so I am an engineer / applied-math guy and someone only mildly technical was impressed by a linux version of some software but wants it for Mac (Doctors...)
Can someone point me at how to redistribute an executable for Mac? Before I ditched Windows the atomic solution was to copy a bunch of DLL's into their System32 folder. Some sub-questions:
1) Ok I see "sudo macports install XYZ". Will this allow me to statically build QT apps? Or, suppose they have QT installed, how do I get my app to find it on their comp?
2) Maybe there's an example out there, using VTK + QT + Boost, for building application for Mac?
My apologies with the vague question, if I knew what to methodically search for I would have done so.
Is there any specific reason why you want to statically link Qt+VTK+Boost with the app? On the Mac, for libraries like these I can't think of any reason (except licensing) why static linking would be preferable to dynamic.
Take a look at the "Deploying an Application on Mac OS X" link that Bavarious posted. It explains how Mac apps are stored in bundles, allowing an app made up of many files to appear to the user as a single file. Libraries can also be stored in a bundle (along with their header files), in which case it's called a framework. Any needed frameworks can be stored inside the app bundle, making the app self-contained.
Qt comes with a utility called macdeployqt which automatically copies the Qt frameworks (plus plugins) into the bundle, then fixes up the app binary (using install_name_tool) so the dynamic linker knows to look in the app bundle. You'll probably need to do this manually for VTK and Boost, which could be more complicated if they aren't built automatically as frameworks. They are popular libraries though, there should be guides on the Internet about deploying Mac apps with VTK/Boost.
Also, I would not use MacPorts to install Qt for this purpose. The Qt binaries available from Nokia work just fine, and they are universal (built for both 32-bit and 64-bit, in case you need to target both).
By the way, I'm not particularly a Windows guy, but I don't think throwing DLLs into System32 is a good way to deploy libraries on Windows. For a Qt app I made, we put the Qt DLLs (and mingw/gcc DLLs) into the same folder as the .exe, and it worked fine.
I was wondering is there a free Windows version of GCC.
I know there is minigw and something else but I don't know how to use them.
Sorry if this should be on SU.
The main choices are either MinGW or CygWin.
CygWin is a more complete UNIX-like environment than MinGW as it offers quite a lot of tools over and above development stuff. Even to the point of a full X-Windows server so you can develop software that'll run on both UNIX-like systems and Windows.
The installer is good but I would suggest installing everything even if you think you don't need it. Disk space is cheap and I've had problems in the past trying to get stuff going on partial installs (whether 1.7, or even earlier, fixes this, I don't know - I always do full installs).
However, it relies on the CygWin UNIX emulation DLL which, if I remember rightly, has restrictions for non-free software.
MinGW is more concentrated on the development tools. It generates native Windows applications rather than running under a emulation DLL like CygWin.
It used to be difficult to install with having to do MinGW, MSYS and others separately but it's come a long since then and has an easy graphical installer.
I believe it can do graphical applications using native Windows calls rather than via X-Windows, since it just links to the normal Windows runtimes.
If you want to know how to use either of them, you really have to look through the docs found at those links I provided - check the Documentation link on the left for MinGW (particularly Getting started) or the CygWin FAQ.
As for GUIs for development, I've never used one for CygWin - I'm old enough that I remember mark sense cards so I'm not scared of the command line interface :-).
I used Eclipse with CDT running over MinGW and wasn't that impressed although admittedly that was an early version. Don't get me wrong Eclipse is a brilliant tool and we use it for both Java and Linux/C development, I just had a lot of troubles with Eclipse/CDT under Windows.
Code::Blocks, on the other hand, was absolutely brilliant but you should check them all out to see which one suits you best. As I said, the last time I looked was about five years ago, an eternity in the IT world.
I am a bit late, but since the question may still arise...
gcc for Windows (including Ada, C, C++ and Fortran compilers) can be obtained from MinGW-builds on SourceForge: http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/
As of august 2013, there are 32 and 64 bits versions of gcc-4.8.1.
wxWdgets is a cross-platform library that includes support for all the major windows versions, but I can't find anywhere in the wxWidgets documentation that says anything about the portability of a single MSW (windows) build of the wxWidgets library across different windows versions. Assuming my core app just uses vanilla C++ (and perhaps the least common denominator of win32 apis available on all platforms) except for wx functions, would linking statically against a single version of the wxWidgets library produce a binary that would run across Win2K, XP, Vista, and windows 7? Would that library need to be built on win2K (the "least featureful" platform?), or would building it on XP also work? Any hints or pointers would be appreciated!
You can build the application on any OS version you want, this doesn't affect the application compatibility with different Windows versions. You can even cross-compile Windows applications on another OS.
The important thing is the selection of API calls that the application references. Any functions linked at loadtime need to be present in the OS, while libraries or API functions that are delay loaded don't affect the compatibility, as long as the application handles the errors gracefully.
The stable wxWidgets version 2.8 is compatible with at least Windows 2000 and all later versions (you could even target Windows 9X if you use the non-Unicode build of the library), it delay loads all functions that are not available in Windows 2000 (for example theme support, introduced with XP). You can be sure that the application runs, but there may be things that don't work on Windows 2000 (for example transparent PNGs).
There may be additional minimum OS version requirements imposed by the development environment. Newer Visual C++ versions for example may require the C runtime to be installed on older OS versions, and there may be a minimum supported version. This however is independent of wxWidgets being used in the program or not.
Yes, wx binaries are portable across XP--7 range (and the same binary should also write on systems as ancient as 95 if you don't use Unicode or use MSLU but so few people use those nowadays (thankfully) that this might have actually got broken without anybody noticing). wxWidgets loads any functions not present in the system DLLs on all Windows versions dynamically, i.e. via GetProcAddress(), and uses reasonable fallbacks for the older systems.