I have been using the gcc compiler with code::blocks ide, and have noticed there are some things missing in the commctrl.h which are:
PBS_MARQUEE and PBM_SETMARQUEE to set a progress bar to marquee animation style.
LVS_EX_DOUBLEBUFFER for a double buffer on a list view...
there are probably a lot more missing, but these are the ones i've noticed, and i need them!
i have downloaded the latest mingw libraries and they are still not in, the only place i can find them is in visual studios headers, but i don't want to use that
is there any way i can get them in gcc?
GCC does not do a good job of supporting Windows. This is a prime example of why. It's an excellent compiler. and on Unix boxes there's nothing else I'd ever use, because it's an excellent compiler, but...
MinGW simply does not include a few of the Windows headers, and for those that they do, they aren't always as up to date as the ones in the Windows SDK.
Finally, in order to support some bits of COM, GCC would need to be able to parse IDL, is not typically used on non-Windows systems is not currently supported by GCC.
Visual C++ Express (as well as it's compiler included in the Windows SDK) is free. What is your aversion to it?
The best way would be to contact either mingw.org or mingw-w64, which is a fork also supporting x64 targets. The latter are known to respond quickly and friendly to "missing features" requests. you can contact them on either the mailing list or forums or IRC (see link).
.... Scratch that. It seems my copy of the mingw-w64 commctrl.h header include these macros. I don't know if they work as expected, but give it a try. Downloads are linked on the page I linked to above. I would recommend personal builds by Sezero for completeness and ease of use. You should be able to replace your mingw folder with the one from the archive (make sure the gcc.exe et al match up).
Do you have the correct _WIN32_WINNT macro defined? It looks like they all need _WIN32_WINNT >= 0x0501.
Related
I'm new to Windows programming and found that lots of prebuilt libraries for Windows offer libraries like lib-mingw, lib-vc2019, lib-vc2017...
Could anyone help to point out
what is the difference? Which library should I use in what case?
If I want to use Clang on Windows, which one should I use?
Why these different libraries rarely seen on Linux (let's say
Ubuntu), does package managers like apt hide this detail? In other word, why there's no such thing like lib-gcc.a, lib-clang.a on Linux platform?
Mingw (GCC), VC2019 and VC2017 are different compilers. Use the library corresponding to your compiler.
I'm not sure but I think none of them will work with Clang. At least on Linux GCC and Clang are very similar. I mean they are mostly binary compatible, many same compiler flags, many same compiler extensions. Clang tried to make it possible to easily replace GCC in your build pipeline. But all these information is for Linux.
These libraries are not seen on Linux because all these compilers are Windows compilers
You can always build a library with your compiler to use it in your project with your compiler (if you have the sources).
If it's a third party closed source library and you are a paying customer you can ask if they build it for you. It's usually better the add a new compiler to the build pipeline than to lose a customer.
Background
I am trying to compile some code on windows that has previously been compiled on QNX. According to this SO Question and this SO Question, I can resolve this issue by simply removing the include statements for sys/times.h. When I remove the includes, I get a bunch of errors saying that variables have not been defined within the scope. I assume this is because I have removed the include call.
Question
What is an alternative to using sys/times.h in the code so I can use it on windows?
Attempted Solutions
Download & install cygwin to compile code - I cannot download cygwin due to network restrictions. I would prefer not to have to download cygwin on my home network
Here's how one project solved the problem:
https://code.google.com/p/madp-win/source/browse/src/include/sys/times.h?r=4ef496e2071896b295262c89eb36a8b3d7656bae
They use various includes available on Windows to fill in most of it, and define the rest themselves. You may have to dig in the codebase a bit if you want to see the implementations for the other two functions - note that the library is LGPL.
According to the questions you linked sys/times.h is only supported in cygwin and not in MinGW. They also indicate that if you can't use cygwin your only recourse is to rewrite the calls to use a standard Windows API instead, and remove the include of sys/times.h.
Not sure if this is the right place to ask but here goes
From a page on the Intel website, it states:
The Intel C++ Compiler for Windows uses the Microsoft Visual C++ header files, libraries and linker. Microsoft controls the header files that define the namespace. Contact Microsoft's technical support in reference to Microsoft's conformance to the C++ standard on this issue... link
Is there a guide by Intel (or otherwise) to change the libraries from the ones governed by visual studio to ones provided by gcc (Also on my windows machine). the reason I want to do this is to make use of some of the new C++11 features that are not supported in versions of visual studio (as is generally the case)
If this is not possible because my current knowledge of the above is not correct, can somebody explain to me why not.
Thanks.
This is not a practical possibility.
The intel compiler (icl) will do nothing but moan if it cannot find VC++ binaries on the PATH, so you know it needs the VC++ toolchain at least.
Then to see what you are up against, as far as using the gcc headers is concerned, you would do the following:
Make icl suppress its own predefined macros.
Make it use gcc's predefined macros.
Make it suppress its standard include search.
Make it use gcc's standard include search.
None of this is hard, and when you have done it all and attempted to build your HelloWorld.cpp, the errors
will show you that the gcc headers are replete with builtin keywords of the gcc compiler that are
unknown to icl: __builtin_va_list, __attribute__, __cdecl__, __nothrow__ and so on.
You might attempt to successfully delete or redefine all of these by way of preprocessor macros.
Or you might give up, and I would urge the latter.
Let's say I have a simple project in MSVC++ 2010.
All there is in it is main.cpp, its code being something simple like this:
// include macros
#define WIN32
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/fl_ask.H>
// main function
int main()
{
// init window
Fl_Window *window = new Fl_Window(250, 250, "Derp Window");
// show window, run window
window->show();
int result = Fl::run();
fl_message("Goodbye...");
// release pointers
delete window;
// return
return result;
}
It's easy to make a Windows compatible version, all I have to do is set the mode to release and the build it. But, as I have recently found out, the generated .exe file would not work on a Mac or Linux OS. This surprised me because all I am using is plain old c++ and FLTK, which is cross platform.
So, my question is, how would I take this code and compile it in a way that it would work on a Linux OS, and the a Mac OS? Or, is it even possible to keep the same code and compile it in a different way so it works on another OS? If it is not possible, what would I have to change?
PS. The code is pretty straight forward but if you're wondering the #define WIN32 is there because without it, the compiler freaks out about a missing header file, something like "X/X11.h"
The code is compatible, but that doesn't mean the generated binary will be. By and large, this is never the case.
Compilers take your code and translate it into lower-level code that your specific architecture and platform can understand, and Windows is not the same as Mac. This lower-level code has basically nothing to do with C++, FLTK or the compatibility promises of either of them.
The analogy here is that driving a car on the left hand side of the road is, mechanically, the same as driving a car on the right hand side of the road (so let's ignore things like navigation differences and the fact that you're probably steering in different directions), so your knowledge of how to drive a car fits both scenarios identically … but that doesn't mean you can simply plonk your car on the left hand side of the road in France or the United States. You'd cause a pretty gnarly accident. When you apply your knowledge of driving a car to a specific environment you have to fit that around the local rules of the road.
You can re-compile the same code under the target environment, or use a cross-compiler.
If you don't have access to a Linux or Mac OSX computer, you have to cross-compile it. To do this you have to either find a existing cross-compiler, you download the source to e.g. GCC and build it your self. Do some searching from "cross compiler" (or similar) and you will find some easy to follow tutorials.
If you do have access to a Linux or Mac, then just copy the code and build it in that environment. Be careful with Linux through, as different distributions have different versions of some libraries.
And finally, there are environments such as Wine which will allow Windows programs to run on other platforms.
If you use FLTK, you need to include its headers on every platform you compile your program, not just WIN32.
The error message you get about not finding X11/X.h is either caused by missing compiler flags (see 1), prerequisites that need to be included first (see 2), or missing headers (see 3).
Use fltk-config --cflags to get the required compiler flags, fltk-config --libs for the flags you need to pass to the linker.
Doesn't seem to apply here, but you might encounter libraries that require it.
If you use Ubuntu or Debian, install the X headers by executing apt-get install x11proto-core-dev, but that shouldn't be required if you already installed libfltk1.3-dev (or some other version), as it should pull in all the required dependencies. If you use a different distribution, make sure you have the X headers package installed.
The problem is probably the #define WIN32. From what you describe, I would guess that the FLTK library is using this to conditionally compile its headers either for Windows or for Unix (X). So you'd need it defined when compiling for Windows, and undefined when compiling for Unix. The usual way of handling such issues is to add a /DWIN32 option to the compiler invocation when compiling for Windows. You'll probably also have to do something to get the right libraries.
And FWIW: it's perfectly possible to design the library so that the header files work for both systems, without any conditional compilation. And if you want conditional compilation, you should probably use the system's predefined symbols (_WIN32, for example).
I made a small program with Boost in Linux 2 yrs ago. Now I want to make it work in Windows. I found there are few .a files in my libs folder. I am wondering how to make it works in Windows? do I need to build Boost in Windows to get library or I can download somewhere? I am using Visual Studio 6.
Yes, you'll need to recompile for different platforms. Coincidentally, I posted instructions on this not long ago.
I hugely recommend you do not use Visual Studio 6. It's very dated, and terribly non-conforming. You can get the newer versions for free, as Express. You won't be missing anything.
Many boost libraries are header-only, you don't need to link against anything to use them. Libraries such as boost::filesystem require you to build libs appropriate for your platform and link against them.
Precompiled boost for MSVC7,8,9 can be found here (in the hope that you follow GMan's advice and get rid of VS6 …)
.a files from Unix are like .lib files in Windows. They will not work, and there is no way of "converting" them, short of using a compiler on the original source code.
However, Boost does build on Windows. Just download it (or more likely, the closest version you can find to the one your code was using).
Older versions of Boost did work under VS6, but with a whole lot of stuff disabled (VS6 really just barely qualified as a C++ compiler). If you can, I highly suggest you use a newer version of Visual Studio.
You have a few options. Building Boost will give you the greatest flexibility in working with your application and boost libraries. However, you can download pre-built Boost libraries wrapped up in a nice windows installer here, Boost Packages
But one thing to keep in mind, depending on what you used in Boost, a lot of it is template based so no libraries are required. If you're only using some templatized portions, you don't need to worry about any of this. Just make sure you have boost in your include path when building.
As a side note, you can get free but limited versions of newer MS compilers here: http ://www.microsoft.com/exPress/