I'd like to build a keyboard layout that runs on Win7 and later without using MSKLC.
I downloaded the Keyboard Layout Samples, and although it says it requires VS2013 Preview and WDK8.1 Preview, it builds using VS2012 and WDK8 after changing the "Platform Toolset" property from "WindowsApplicationForDrivers8.1" to "WindowsApplicationForDrivers8.0".
But: Checking the kbdus.dll built with Dependency Viewer reveals that it imports quite a lot of stuff from kernel32.dlland from msvcr110.dll. This is in contrast to kbdus.dll from the Windows\system32 directory, which, as one might expect, does not import anything and exports one single function.
My first question: Is it an issues that the dll built imports from msvcr110.dll?
I guess it is, as Win7 does not include this dll. (Honestly, I'm wondering how this can be, because these are official Microsoft samples.)
Tweaking around with compiler and linker settings, I managed to get rid of imports from msvcr110.dll, but the dll built still imports a lot of stuff and is quite large (> 70kB), compared to the original kbdus.dll (7kB). It's the same with x86 and x64, Debug and Release builds. I'm looking for the /compileandlinkanddonothingfancy switch.
My second question: How can these dlls be built correctly?
(Note: I found this question, but it is about WDK7. That will be what I try next, if I don't get it with WDK8.0)
I think one should pass /noentry to the linker.
Related
This seems to be a tricky question, also because it is difficult to present here all settings involved. So let me state the total picture:
I use Visual Studio 2022 to build a solution (all in x64 mode) comprising of two projects
CapopConsole
and
CapopWrap
CapopConsole is a C# Console-Project generating an exe and CapopWrap is a C++/CLI project wrapping a C++ native library called Capop. It generates a dll called CapopWrap.dll. CapopConsole has CapopWrap as dependency.
CapopWrap has three extra .lib dependencies, namely
capoplib.lib, libpredicates.lib, jsoncpp.lib
in Release mode and
capoplib.lib, libpredicates_d.lib, jsoncppd.lib
in Debug mode.
The first two of each row are from a certain project, special for me, the last one is from the well known jsoncpp project. All three libs are built with Visual Studio 2022 with the new CMake mode (no 'solutions').
Now the point is: Compiling and linking CapopWrap produces both for release and debug mode respectively a result dll, in both cases called CapopWrap.dll.
But: CapopWrap.dll from debug mode has a dependency on jsoncppd.dll whereas CapopWrap.dll from release mode has no explicit jsoncpp related dependency whatsoever (as shown with dumpbin, for example).
By symmetry one might expect that CapopWrap.dll (Release) would incur a dependency on jsoncpp.dll but this is not the case.
I would really be happy, if someone could help me find an explanation for this - my own attempts so far where fruitless.
Addendum: I do not give concrete excerpts from my .csproj and cmake files at first, because they are a bit lengthy and maybe an answer is possible without them. If not, please tell me, what you want to see concretely from my configuration files (or filesystem contents), I will edit it in then.
I'm a windows developer and I need to use Code::Blocks
to develope multiplataform C++ GUI applications.
After installing Code::Blocks and wxWidgets in my first try to do a simple "Hello World" application, the IDE show me a box with $(#wx)
What is the $(#wx) ?
Googling for tutorials I see this
What is the -g ?
Finally the following error message appear:
For 3 days I'm trying over and over again without success !
I even try wxPack. Nothing works !
With VC++, C++Builder and even wxDev-C++ this is straightforward
Only Code::Blocks is so difficult !
Googling, I find many people with the same error, but the advices they get didn't work for me !
Can someone tell me step by step what I must do?
Thank you.
Your frustration comes, as usually does, from your ignorance. If your are required to learn about C::B, well, that's life. Don't waste time on getting so angry, life is short.
CodeBlocks are not tied to a compiler. You can use VC++, MinGW, TDM-GCC, GCC, etc. Thus, you must tell C::B the compiler to use. You may use different compilers for different "targets" (see below).
C::B is not tied to any library either. If you want to use wxWidgets you must tell C::B about the needed files and where to find them.
It's very common that people who use C::B use MinGW as the compiler. That's why when you first install C::B it searches for MinGW and, if found, set it as the default compiler. You can set your own preference in Settings->Compiler. Same goes for the debugger, usually GDB.
As a side note, be aware that MinGW is ONLY 32 bits. There's a different compiler (MinGW 64). TDM-GCC offers both compilers (and their GDB versions) at once, I recommend installing 32/64 versions in different folders and setting them in C::B as different compilers. For Linux, the "mother" GCC is the de-facto standard.
When you build your app you must define a target. This is nothing else but a way of telling things like "I want a 32 bit library" or "I want a 64 executable". In your required project you may set several targets. Select the desired one before compiling (combobox in the main tool bar).
While developing it's very advisable to set a target as a "debug". This means you want to use the debugger. This requires to use "debug symbols". With GCC (or one of its "children", MinGW...) you acomplish it but adding -g as a flag to the compiler.
Now you understand that probably you set not only one, but several targets like "release 64 exe", "debug 32 exe" etc. Right?
wxWidgets joins in scene
Despite C::B is made with wxWidgets, it doesn't ship with it. Download the version you like from wxWidgets site. While some binaries are offered, if you use some other compiler or some other parameters then you need to compile wxWidgets on your own. See the docs/msw/install.txt and learn about the different configurations (release, debug, static/dynamic lib, etc). Your "target" must match the wxWidgets configuration, so better build several versions, same as your targets. And don't forget to use the same parameters for your app target as you used to each wxWidgets target. You can do this at Project->Build options.
As with any compiler you must tell where to find the libraries and the headers. And the libraries you want to use. The Windows libraries (kernel32, user32, etc, they are a lot, ask in another thread) and the wxWidgets libraries.
When you update your app perhaps you use a newer wxWidgets version, but also want to support an older version with other wxWidgets version. You have several folders. For your project you should update all directories. Can this be done shortly? Yes. in C::B you can define variables(e.g. $wx31dir) and use them like $(wx31dir)/include. Redefining the var saves you a lot of typing.
You can use a global var $(#wx31dir) or several, project fitted vars. Your decision.
Finally, C::B offers a project template for a wxWidgets app. It will ask you some locations (wx dirs) and vars. If you don't understand well what it does, better don't use it and set everything on your own. First time is hard, I know. Go ahead and you'll get it if you pay attention to needed steps.
Have you read the CodeBlocks manual?
Since you having hard time using C::B, I suggest you switch to CodeLite which I find simpler to start with than C::B (My experience). Everything you need is documented on CodeLite Wiki. Creating project is well documented with screenshots but before you compile, open environment variables (Settings->Environment Variables) and add line WXWIN=/path/to/your/wxwidgets/installation and compile as it is explained there.
Ouch....
You do not need to interact with code::blocks at all to use wxwidgets.
You can simple download wx header and binary package (depends of your compiler), place it on directory and import (with #include) it in your source code.
I do not see what is relevant to C::B? You can use any library without compiling and setting any variable in your editor (IDE) - but then you lack of lot of feuters.
I hope that
Using wxWidgets Pre Built Binary in CodeBlocks at wxWidgets wiki
and
Using wxWidgets (MSW) 3.0 Binary with Code::Blocks Scripted Wizard
would be best and useful answer for your question.
Even I want to use wheel for my convenience every day, but I don't want to invent the wheel every day again and again.
Even that your question is about wxWidgets and Code::Blocks for MS Windows, and that the answer links are of the wxWidgets and Code::Blocks own,
For recommended stability, I include the full screenshot of this document of wxWidgets own wiki
and
this of Code::Blocks own wiki
The definition of mbstate_t has changed from:
typedef int mbstate_t;
to
typedef struct _Mbstatet
{ // state of a multibyte translation
unsigned long _Wchar;
unsigned short _Byte, _State;
} _Mbstatet;
typedef _Mbstatet mbstate_t;
This is not backwards compatible and seems to imply all components of a Windows desktop application will need recompiling with VS 2015 if I am to use VS 2015. Obviously "all" is too strong here, only components using mbstate_t are affected. However, that's still not a good situation.
Are we expected to recompile if we migrate to VS 2015? Am I missing something here which means this isn't an issue?
Given that this struct has changed I have bigger concerns that there may be other breaking changes between VS 2013 and 2015. Is there a list of these anywhere?
Note:
I've already asked this question on MSDN but my gut tells me more eyes will be on it on Stack Overflow: https://social.msdn.microsoft.com/Forums/vstudio/en-US/8e50f348-0b6d-442c-8a1e-b1b8a4288fbc/mbstatet-is-not-backwards-compatible-between-vs-2015-and-vs-2013?forum=vcgeneral#8e50f348-0b6d-442c-8a1e-b1b8a4288fbc
To answer the question. Yes, you are expected to recompile everything if you wish to update to newer versions of Visual Studio. MS reserve the right to change any part of toolchain and libraries. There are clear examples of C headers and C++ headers changing. Plenty of other things could change as well which would make binary compatibility between versions difficult or impossible.
Some discussion / opinion
In my mind it is not 100% obvious that you'd need to recompile everything when updating to a newer version of the toolchain. Forcing a user to recompile everything to update to a new toolchain can be quite burdensome. In large projects you may be dependent on a lot of 3rd party code which you have no way of recompiling. Many SDK expend a lot of energy in ensuring backwards compatibilty so that users don't have to do this.
Interestingly the linker makes no effort to disallow linking against libraries built with older versions of the toolchain. It doesn't even warn! This behaviour might imply that it's acceptable to link old libraries with new code.
Anyway, I could waffle about this all day. One thing I wanted to point out is that if you know what you're doing then it is possible to link binaries built with older versions of VS against newer versions. You have to be very clear about what declarations (effectively your header files) your code was built against and know that these declarations either haven't changed or they have changed in a way that doesn't cause runtime errors. You also have to be sure that the compiler hasn't changed the way it handles builtins/intrinsics etc. in a sufficient way to hurt you. For example, the use of a try/catch block with MSVC will cause code to be automatically generated to handle exceptions. This will lead to implicit calls to functions provided by the runtime libs. That could easily change version to version and you could be left with undefined symbols or unexpected behaviour.
Proceed with caution :)
It used to be that Visual C++ actually did try to maintain C runtime library backwards compatibility at the object file (and thus static library) level. Opaque types like mbstate_t might change their internal representation, but they wouldn't change their size. This allowed an object file compiled with older versions of the CRT headers to work when linked with a newer version of the CRT.
(Note that this doesn't apply when CRT objects are passed across DLL boundaries. Multiple CRTs in the same program, whether statically or dynamically linked, are not compatible.)
This mostly only applied to C code however. The Standard C++ Library was not backwards compatible at all, and there are actually linker checks to enforce this. (Though not if the out of date object files were compiled with Visual Studio 2008 or earlier.) Also the C++ ABI is subject to change between major releases, so potentially the layout of C++ objects can change.
However as you've noticed with Visual Studio 2015, the C runtime library is no longer backwards compatible. The CRT went through a major refactoring and many things changed. Most of it is no even longer part of Visual Studio, and instead is now a part of the Windows operating system. As you've also noticed, there's no error or warning when you to try to link older binaries with the new CRT. As the old CRT didn't include any version symbols in the compiled object files, so there's way it can know if they were compiled using the old CRT headers.
I'm using the latest github version from https://github.com/bulletphysics/bullet3
To generate the visual studio solution, I've used the 'vs2010.bat' located in bullet3/build3. This sets it up as static libraries however. If I change the configuration type to dynamic, the .dlls are generated properly, but no .lib-files.
I've also tried using CMake with "BUILD_SHARED_LIBS" enabled, but again, no .lib-files are generated.
What's the proper way of building bullet as shared libraries?
At the moment it is not possible using Visual Studio on Windows to generate import libs (.lib) when using shared libraries for Bullet. The reasons is that no symbols are explicitly exported. Shared libraries work fine using gcc or clang on Linux and Mac OSX. It would require quite a bit of work to instrument the code to fix this issue.
See also https://cmake.org/Wiki/BuildingWinDLL
I built a VB Windows Forms application a while back using VS05 (or VS08? Not exactly sure) that I've recently converted to use VS10. I reference a .dll called ExcelPackage (another article, usage) so that I can create/manipulate Excel docs serverside. This app has worked fine on my old computer (PC/Vista) for a number of years. However, I have tried to move it to my new computer (PC/Win7 64-bit), and I can't get it to recognize the ExcelPackage .dll.
I have tried recompiling the .dll in VS10 and dropping the new .dll in my bin folder and re-referencing it. When I do this, before I try building, all my errors go away and I am actually able to navigate the class using VS10's built in ability (mouse over Imports OfficeOpenXml and you get a dropdown arrow that allows you to go through the classes). After I build, I get a green squiggly under my Imports OfficeOpenXml statement (can't find the reference).
I did some research and discovered that the .dll containing System.IO.Packaging has been moved around in .NET 3.0 and even re-referenced the new .dll, rebuilt, re-added, re-referenced, still no dice.
Am I missing something, or how do I get my application to recognize this assembly so that I can compile and continue working?
Thanks.
I don't see anything special about that project. Do note that the solution and project need to be converted. When that happens, you'll end up targeting the .NET 2.0 framework. That won't work out well, it has an assembly reference to WindowsBase, a 3.0 assembly. Make sure you update the target.