I need to use CEF1 (not CEF3) and I need to do it in VS2017 (rest of the project is in VS2017). Which is a bit of problem, as VS2017 didn't exist at the time of CEF1. I don't even know how to begin. I tried to compile CEF1 in older Visual Studio, but then got linker error for mismatching _MSC_VER
Before I start my answer I need to say that it is highly recommended that you use CEF3 instead. The reasons include:
CEF3 is in active development, currently receiving support, improvements and bug fixes.
CEF3 uses modern versions of Chromium under the hood. E.g. 61 and 62 and the time of writing.
CEF1 is stuck at Chromium 27.
CEF3 can be started in a single process mode, similar to how CEF1 was functioning. This is the biggest reason in my opinion one might want to use it. (Actually I wonder why do you want to use CEF1?)
My answer:
If you can find the branch number you want in this archive (it has binaries for some older CEF1 branches) or if you already have some binaries then you should be able to link them against your VS 2017 project no problem.
If not, then you need to build CEF1 from source. The easiest way in my mind is to satisfy the system requirements for building the release branch 1453 (the last one to support CEF1):
Having VS2010
Windows 8 SDK
You could also try to build CEF1 in VS2017. In this way you are likely to encounter more build errors.
Once the 2nd or 3rd step is complete you can use the output in the VS2017 C++ project.
Related
I'd really appreciate some help getting HElib to work on Windows 10 x64 using the MSVC 2017 compiler. I successfully managed to compile its dependency, NTL, using the same compiler by following this tutorial and also ran its tests, so it seems to work well.
However, in the case of HElib I tried generating Visual Studio projects using cmake and then compiled it successfully (see NOTE below), but running it fails. For example, I ran the Test_binaryCompare.cpp_exe test (has its own vcproj generated by cmake), but it fails because it reaches a part of code I doubt it's supposed to (it attempts to do an operation called bootstrapping and it is disabled for that test). However, on Linux it works.
LINUX: The reason I'd really like to run this on Windows is because I find it a lot easier to debug using Visual Studio. I'm also more used to Windows overall..
NOTE: Compiling HElib successfully required some modifications like fixing broken tr1 includes (e.g it was trying to include <tr1/memory> instead of just memory although the latter was actually available), suppressing the 4146 error (I also had to do this for NTL) and fixing two instances of variable-length arrays which Microsoft's compiler sadly does not support.
Without any error messages I can't really help you figure out your exact issues but I ported HElib to Windows some time ago: https://github.com/AlexanderViand/HElib/tree/Windows
It's a bit out of date but if the tests works in that version you can check the changes I made against your changes.
There's also the option that you're simply running into this issue: https://github.com/shaih/HElib/issues/228
If your linux version of NTL is slightly older, it might just be that your windows version of NTL is the buggy one.
Finally, I'd very much recommend against running HElib on Windows because without GMP it seems painfully slow.
Instead I ended up setting up a docker virtual machine and SSH'd into that from visual studio: https://hub.docker.com/r/alexanderviand/visual-studio-linux-build-box-with-helib/
Currently I'm using WSL and CLion (which supports WSL quite well) when I'm working with HElib on Windows.
This is a very specific problem, - I apologize for that.
I've been building a graphical real-time application using Direct3D 11. I started it on the Win7 OS. I then upgraded to Win10 and when I tried compiling the solution again, the linker barfed like it had caught the plague for silicon microchips.
It spews out Unresolved symbols in objects that don't even use the given functions.
__imp__wassert
strlen
fabs
__imp__CrtDbgReportW
sprt
and more
I've concluded that the majority of the functions in question is mostly C functions. I'm aware that the c functions are no longer included in the C++ headers and libraries, so I made sure to include all the relevant C-libraries explicitly.
I've read and followed the solutions of some of most of the other folks having problems with Windows 10 screwing their code. one of them is this : Upgraded to Windows 10 and now WAMP won't work
I also tried actually telling the linker where to look for the -lib-files, in case the compiler or project missed the memo.
On my PC, the location for the Direct3D libs is here: C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10586.0\um\arm64
As you can see, I am trying to force it to use Win10 lib versions in case this was a requirement.
I started in one end to try and catch myself doing something stupid:
I looked for full include paths to see it this had started an avalanche: FAILED
I tried removing the /ZI compiler option: FAILED
Relinking the DirectX libs to all different version one at the time: FAILED
Explicitly include the vcrumtime.lib to the additional linker libs: SUCCESS (removed half the errors)
Create An entirely new project and include everything from scratch: FAILED
Add MSVCRTD.lib : FAILED
Change the target platform to 64bit: FAILED
Tried including stdio.h in certain independant tool classes: FAILED
Tried including Winmm.lib in the linker: FAILED
I've roamed the internet for what feels like a decade (only a month irl) to find some solution, but nothing.
I hope some of you have an idea of what noobiness I might have committed.
All suggestions will help.
Most likely you are linking with a static library that is not compatible with VS 2015 because it uses the Universal CRT. For example, the legacy DirectX SDK library DXERR.LIB fails to link when using VS 2015. Make sure you rebuild all your code with VS 2015 and avoid the use of static libraries build for other versions of Visual C++.
You also won't be able to get your project to link and run on an x86 or x64 PC linking with the 64-bit ARM libraries.
You do not need to use the Windows 10 SDK for Win32 desktop apps, although you certainly can.
I have successfully installed allegro 4.2.3 in accordance with the instructions at the following link and it all works great:
http://blog.hamidnazari.com/2010/07/21/installing-allegro-on-visual-cpp-express-2010/
The only thing I've ended up deviating from in respect to the tutorial linked above, is I've selected Windows Application instead of Console Application where illustrated within the 3rd graphical example (note selecting between Win32 Console Application or Win32 Project as illustrated in the 2nd graphical example, I've found to make no noticeable difference so far).
Selecting Windows Application where illustrated in the 3rd graphical example, has for me at least, simply resulted in NOT Needing to include the line: #define USE_CONSOLE in all my Allegro programs.
Please in respect of the tutorial linked above and the title of this post, can someone please help me by answering the following question:
Start of Question:
How can I get my Allegro games to work on other computers that use Windows, without the other computers requiring that Visual C++ 2010 Express be installed, And/Or the pre-built binary version of Allegro 4.2.3 (linked to in the above tutorial) also being required to be on the other computers and linked to/configured within Visual C++ 2010 Express, also described in the above tutorial.
End of Question
Incidentally: A great link for anyone interested in making standard C++ programs (i.e. that don't use Allegro or other various libraries) work by having a fully independent .exe file (compiled/built using Visual C++ 2010 Express) which can indeed run on other computers using windows, is below:
http://www.youtube.com/watch?v=AvrjQtFBJvk
Thank you for taking the time to read this post and I hope very much that someone is able to help.
Gary.
My Reply To Matthews 1st Answer Is Below:
Hi Matthew,
I’ve been looking on Google to try and find out how the various elements you mention, fit in with and compare to the linked tutorial in my post which explains step by step how to configure visual C++ 2010 Express with the Allegro 4.2.3 binary.
The first thing I want to check with you, is if all the binaries in the 4.4.2 section and 4.2.3 section on the Allegro.cc site, are essentially both pre-built binaries, and therefore ultimately configuring version 4.4.2 to work with VC++ 2010 should be in principle similar to configuring version 4.2.3 (or perhaps not?) I have downloaded version 4.4.2 and can see that there are indeed the same 3 folders, bin, include & lib.
Here is the link again to the online tutorial which explains how to successfully configure step by step, Allegro 4.2.3 with visual C++ 2010 Express:
http://blog.hamidnazari.com/2010/07/21/installing-allegro-on-visual-cpp-express-2010/
Working through the steps in the above tutorial, I have noticed additional elements in your initial answer which I have listed below. (Please note, although the tutorial does indeed work well for version 4.2.3, simply selecting the release option instead of debug when building does not result in the .exe files working on other windows computers (although the .exe file in the release folder does still run on my primary computer), and so I guess there are other things that need to be done in addition to selecting release.
1) allegro-4.4.2-monolith-static-mt.lib --- Does this need to be added to additional dependencies in the Input Section within the Linker dropdown for both debug and release. (Also how does this compare with the tutorial for this part of the configuration i.e. are there any other additional dependencies)
2) link to all the various Win32 libraries when you static link --- I don’t know how to link to these libraries. I’m a bit stumped on this.
3) #define ALLEGRO_STATICLINK --- Does this mean that “ALLEGRO_STATICLINK” needs adding to the Preprocessor Section within the C/C++ dropdown, as I read somebody else did in an attempt to get it all working for 4.4.2
To conclude: I suppose to ask my initial question once again considering all that has been said so far, I would ask it in the following 2 parts:
Part 1) How would the online tutorial need adding to/modifying for static builds to work successfully on other computers using windows for version 4.2.3, and would this then just mean selecting the release build option and of course keeping together any files linked with the .exe when distributing.
Part 2) If using the 4.4.2 version, again how would the online tutorial need adding to/modifying for static and dynamic builds to work successfully.
Tutorial type answers to Part 1 or 2 would be awesome for me and many other newbies
Thank you very much indeed for reading this post.
Allegro 4.2 is painfully old. You should use 4.4 at minimum. It is source compatible with 4.2 (same API) and still receives updates from time to time. Allegro 5 is where all the active development is now, but it has a completely new API. I still highly recommend that you take a look at it.
Anyway, to answer the question, yes, you need to static link. Grab a binary from here:
https://www.allegro.cc/files/?v=4.4
Link with the allegro-4.4.2-monolith-static-mt.lib file, and make sure you compile using the /MT switch (as opposed to /MD). The -static aspect means the Allegro DLL is not needed. the -mt flag means the C runtime is not needed.
You'll also need to link to all the various Win32 libraries when you static link. Also, be sure to #define ALLEGRO_STATICLINK in your project settings.
It's been a little while, but if I remember correctly there's an easy way to do this, though it's probably not the best way. It's good for just sending a little demo to a friend. Even if you just build in Debug mode, you can send the game over to other people. Copy/paste the allegro-4.2.2-monolith-md.lib file (Its name is something like that, but probably not that exactly) into the project's Debug folder (next to the .exe). You'll probably also need the MSVCR1000.lib file (or something like that. Can't remember the exact name), but you'll have to find that online somewhere.
DISCLAIMER: I've never used such a completely old version of Allegro, so this solution may not exactly be applicable. But I was using Allegro after version 5 and up to 5.6, so I know it works for newer versions. You should just use a newer version, really.
I'm using Visual Studio 2008 for C++. When compiling, Visual Studio compiles against the header files of the VC 9.0 libraries. However, there are different versions of this library available:
v9.0.21022.8 (= RTM)
v9.0.30729.17 (= SP1)
v9.0.30729.4148 (= SP1 with security update)
I'd like to know whether it is possible to tell Visual Studio which version it should compile against.
The reason I think this is important is because the application's installer needs to make sure that the correct version of the Microsoft Visual C++ 2008 Redistributable Package is installed. To me it feels like I don't have any control over this dependency, as apparently some Windows Update (not a Visual Studio update) can change this dependency. I'd like to keep using the same version to avoid the overhead of making the installer upgrading the Redistributable Package.
Note that this situation is different from my earlier question, as that one was about link time. Neither am I looking for a way to control the version that is put in the embedded manifest file, as that is explained here.
The manifest that's included with your binaries is automatically generated by the VS build system. Important headers that determine the version dependency that's emitted into the manifest are vc\include\crtassem.h and crtdefs.h. The former declares the CRT version. Note that it already has support for the RTM version vs the "latest" version with the _BIND_TO_CURRENT_CRT_VERSION macro. The latter contains #pragma comment directives to embed the /manifestdependency linker option into the .obj file, which in turn makes the linker auto-generate the manifest.
You don't have to do it this way, you can simply turn off the linker options that generate the manifest and write your own. That gives you complete control over the CRT version that your app binds to. Whether you are ahead with this is a bit questionable. You would probably still be shipping the old version of the CRT that got updated in July of last year, it contained a critical security bug. Customers tend to be a bit unhappy about getting software installed on their machine that has well documented and solved security flaws.
The next thing you'd have to do is take control of the deployment of the DLLs. You'll have to deploy the DLLs into the WinSxS side-by-side cache yourself.
That will work, if you figure out how, but it isn't likely to survive for very long. Windows Update, if enabled, may discover that the machine is using an unpatched version of the DLLs and will update it. And deploy a publisher policy to redirect load requests. It is likely that your machine has such a policy file in place if you see your manifested version request resulting in the load of another version. The somewhat unescapable conclusion is that this is MSFT's DLL and they'll do with it what they think is necessary. Look at applocal deployment to avoid this.
It's this just a question of which directory your configuration is set to build against. As long as you have all the versions of headers on your machine and the libraries they link against I don't see why this can't be a new configuration for each version.
If the issue is things like SP1, there's not much you can do. Microsoft considers the runtime, in effect, a component of the operating system. It therefore gets updates and patches the same as any OS component.
There shouldn't be a problem with this, normally - the patches are bugfixes and security updates after all. In principle, each change should make your apps more stable. Not quite always true, but in any case there isn't much you can do about it.
There are options to change the runtime, but they are related to thread-safety and similar issues. There's a few relevant places in the project properties. In particular, in the C/C++/Code Generation tab you can select which run-time library to use.
If you are seriously worried, you can choose a statically linked non-DLL runtime. Users can still update their runtime DLL, but it won't improve the stability of your app when they do so.
You can do this using manifest resource files, which are written in XML.
We had to do this at a previous place of employment, unfortunately (or perhaps, more fortunately), I was not exposed to the in depth details of how it was done. This article looks about the closest to what we did that I could find on the subject.
Update0
Here is MSDN documentation regarding manifest file generation, and their use in isolating applications and building side by side assemblies.
What are the pluses and minuses to using the vcredist.exe versus the msm files to install the Visual C++ 8.0 runtime libraries?
Merge Modules can not be updated (unless they solved that in Windows Installer) once they are installed, so my advice would be to stick with vcredist.exe.
Another issue with the merge modules I recently bumped into is that they set the MSI installer property ALLUSERS to 1 which means per-machine. That forces your whole install to be per-machine, which is a problem if you want it to be per-user. Whether there's a way to have a per-user installer that includes a CRT merge module I don't know, but I haven't found it yet.
One downside to the merge modules is that you can't deploy multiple versions of the VC80 or VC90 merge module in the same msi because the file identifiers overlap. You can deploy one of each though. So for example, if you wanted to deploy the RTM version of VC80 and the SP1 version, you will get errors if they are in the same msi (I use WiX).
Another issue, build behavior is different between VS 2005/2008 as it pertains to applying a service pack or update.
2005
If you install service pack 1 on your build machine, your program will automatically link against the updated files. The service pack will also update the merge modules, so provided you're pointing your installer to use the updated files, you're fine. However, this can be an issue if you're using third party compiled static libs that may require an older version of the runtime specifically.
2008
The behavior here is the exact opposite. If you install SP1, the merge modules are updated to the SP1 level, but your program will compile against the RTM versions unless you set a per-project preprocessor macro: _BIND_TO_VCLIBS_CURRENT_VERSION=1. This can be set either in stdafx.h or in the "Preprossor definitions" for your project, or if you're using an old nmake project, you will have to pass it wherever your command line options are, such as CFLAGS.
This means that if you're using the msm provided by visual studio, and you apply SP1, your project deployment is broken until you define the macro.
Another caveat to the macro: if you're using a 2005 project that links against a 2008 static lib, setting the macro will break the 2005 project, due to the symbol not existing in the 2005 version of the compiler. In this case I usually split the project I'm linking against into a 2005 and 2008 version of the solution.
To point out the obvious, Merge Modules are not really a good solution if you aren't going to use an MSI installer. Vcredist is absurdly simple to use regardless of the install process you are using.
MSM will give you a better streamline experience then vcredist, it will integrate with the progress bar and will rollback on error (or cancel).
From the developer side you will benefit by seeing the msm log in the main setup log file and it will execute its actions side by side with the setup action (with vcredist you will need to sequence it yourself).
Because of all of the above reasons I usually choose to use the msm (and its more or less one Wix liner to use it).
Have you considered statically linking instead? Then you don't have a redistribution problem.