Two things come to my mind whenever I revisit the subject of using Visual Studio's compiler and linker to build Windows drivers:
It is not officially supported. Indeed, the consensus all over the Internet is that the right way to build Windows drivers is to use the compiler, linker and BUILD tool included in the Windows Driver Kit. However, Visual Studio 2008 includes the /DRIVER linker option, which is described as follows: Use the /DRIVER linker option to build a Windows NT kernel mode driver. What does it do? Why was it included in Visual Studio if using it for building drivers is not recommended?
It works. I'm almost afraid to say this out loud lest I incur the wrath of the righteous kernel developers, but the truth of the matter is that drivers built with Visual Studio do work. We've been building them this way for years at my workplace, the produced binaries have been deployed on hundreds of machines, and there haven't been any problems. However, I am aware that the absense of evidence is not evidence of absense, and that the lack of any problems so far doesn't necessary mean that building drivers with VS is safe.
What really bothers me here is the lack of information. There are a few posts over the Internet from people who use VS to build their drivers, which invariably draw the same response - it is not supported, do not do it, integrate WDK with VS by means of a makefile project if you really want to use VS's IDE. However, I haven't found a single reply which points out a concrete reason why you shouldn't build drivers with VS.
So, does anyone know what would happen if you use VS to build your drivers? What could go wrong? Under what circumstances? I know that you have to set all compiler and linker options yourself, and it's allright, but what happens if I set them wrong? Will the driver fail to compile, or will it fail to link, or If it builds fine will it crash outright or only when the stars align right? Why would it do that, what causes it? Is there any reason to stop building our drivers with VS which has worked like a charm for years, apart from the fact that it is not officially supported? If it is not officially supported, why put the /DRIVER switch in VS?
The reason this is common-sense is because the resulting flaws can be subtle. Most of this has been cargo cult, though ... ever since there was an actual problem. And if I remember correctly that would have been before 2005 (i.e. the first DDKs at all containing a compiler). Correct me if I'm wrong.
Generally, I don't see a lot that speaks against using the VS compiler though. For the the linker you also have to set the proper subsystem value (i.e. none) and so on ... it's just tedious.
However, keep in mind that the WDK compilers and tools are usually ahead of those in the latest VS at any given time. Consider this: what the WDK contains is a close as you can get to what is used to build Windows itself. Hence the preference for the tools from the WDK.
Technically it can be done. But if you post to a newsgroup and mention the fact, don't be surprised if you first get to hear a lesson on that topic rather than your actual question ;)
If it is not officially supported, why put the /DRIVER switch in VS?
It's not a matter of putting the switch in to VS, it is a matter of taking it out.
The C++ compiler/linker that ship with WDK and VS are built from the same source base (perhaps from different branches and at different points in time, but the same source base), by the same team inside Microsoft. Could they configure their builds so that the /DRIVER switch doesn't appear in the linker delivered with VS? Sure. Is it worth the cost of maintaining a separate build configuration and checking that the right build variants are delivered with the WDK and VS, respectively? Probably not.
As to why it isn't officially supported in the first place... The expertise of validating a toolset for driver development lies within the Windows team, not the VS team. The last thing the Windows team wants to do is to be on the hook to qualify a release of VS for driver development (which Windows would ultimately have to help support, as well), when that release is on a schedule that doesn't line up with Windows.
Combine that with the fact that driver development is targeted at a relatively small audience, and building drivers through IDE opens up additional features and test scenarios, and it is very unsurprising to me that it is not officially supported.
Related
To what extent is it possible and legal to developer WinRT applications with VS2010 Pro?
On the one side, I think it should be perfectly possible and legal to create an HTML5/CSS/JavaScript WinRT App with VS2010 Pro since you can probably do so using Win 8 Notepad. On the other side, I think it might be difficult and possibly illegal to create an C# WinRT App via VS2010 Pro since doing so might require the user to circumvent intentional limitations of the VS2010 Pro software.
In the old days, the user just bought a stand alone compiler and she/he was free to link it against whatever libraries she/he choose. In this way, she/he didn't have to upgrade her/his compiler anytime she wanted a newer version of MFC or *.NET. These days, the IDE seems to be married to the compiler so I'm not sure if the user is allowed to use older IDEs (such as VS2010) to link against newer libraries like those offered in WinRT
See here.
You can use the Windows SDK, along with your chosen development
environment, to write Windows Store apps (only on Windows 8)...
So it's clearly legal. I haven't tested it, but I'm going to guess that you can probably do the code side of things in VS 2010, but VS 2010 isn't setup to do Windows Store UI so xaml, html5 etc probably won't work.
It's probably much easier to simply use Visual Studio 2012 express.
To what extent is it possible and legal to developer WinRT applications with VS2010 Pro?
It is not (directly). The APIs and the packaging tools will not be available in VS 2010.
While you could potentially do this yourself, it seems far simpler to just install Visual Studio 2012 Express for Windows 8 and use it.
These days, the IDE seems to be married to the compiler so I'm not sure if the user is allowed to use older IDEs (such as VS2010) to link against newer libraries like those offered in WinRT
It's more than just newer libraries - there's an entire new runtime, and the language needed changing in order to work with it.
The question is at the end - let me start by posing the context:
One of the problem we are facing at work when using Visual Studio is to make sure that everybody on the team is using the same version of the SDKs.
A typical problem would be to have somebody use a different Direct X SDK version resulting in a different behavior of the code, or somebody upgrading to a more recent Platform/Windows SDK in order to use some new API and having the code fail on other's programmers machines if they still use the previous version.
A way we used to solve the issue for other middleware has been to put the whole set of libraries, include files, tool chains, etc... in our source control system, and have our projects to use these so nobody has to install anything.
We also managed to do that with earlier version of the Direct X SDK, but we always ran into issues with the Windows/Platform SDK due to the close links between the SDK and the toolchain.
Since we now have to support both VS2010 and VS2012, and have to support from Windows XP to Windows 8 targets, we have to support v100, v110 and v110_xp toolsets.
This means that we need all the associated compilers and the corresponding SDKs, both on our developer machines and build systems: This is getting ridiculously costly to maintain, specially considering that random windows updates and .net framework releases routinely tend to break msbuild.
So the question is:
Is it possible to have Visual Studio to use non installed toolsets and SDK and instead having it use whatever is available in some folder out of the normal VS installation locations?
Bonus question: If it is doable, is it possible to do that without having to change any locally installed configuration file on the machine - ie: Have all that in the solution/project or property sheets - so if we change the structure on the source control system we don't have to update every single machine?
Thanks :)
This sounds too complicated, given how complex some of these tool installations are. I would solve this problem by investing in some PowerShell scripts that look at the installed tools and tool paths and "police" the installations. It would be relatively easy to check for installed versions of everything, including patches and updates. You can run those nightly, or as part of a build. Also, you can compare aspects of different installations, such as the tool versions installed on a developer box with your build server.
This would give you 90% of the value for 10% of the pain.
The problems you describe are not solved with your approach. What you actually need is a build server and a definition of done including using binaries built with the build server. You also need a test suite as part of the build definition with some invariants related to the build environment used.
I am trying to compile qt, and am faced with two choices whether use MinGw or Visual Studio compiler? What is the difference between them, and are there any advantages/disadvantages of using one or the other?
They are both fine tools. The important thing to know is that they don't necessarily play well together. That is, as you link libraries together, they must all use the same tool chain. For this reason, in my opinion, it is better to use the Visual Studio compiler (MSVC), as it is the "first class citizen" on Windows; the others are treated somewhat as second class.
What I mean is that you can pretty much count on third party libraries being available in binary form using MSVC, or at least build instructions being available using MSVC. We had lots of problems with third-party libraries not being able to build in MinGW or having nonexistent build instructions and having to do a lot of manual Makefile editing, etc. You are much more likely to have things "just work" if using MSVC.
That is just our experience (we started with MinGW); your mileage may vary.
MinGW uses GCC, and GCC has one significant advantage to MSVC - it is portable. MSVC is limited to Microsoft platforms, GCC supports pretty much everything, including 8bit embedded CPUs. Meaning that you can use the same directives and compile extensions across different platforms.
Also, MinGW is compact, quick to install, and a version is even bundled with Qt. Unlike MSVC, which is not even available standalone, you have to install visual studio, which itself installs a bunch of garbage you don't need but can't opt out of.
UPDATE
It is now possible to get the MS compiler without VS, a.k.a MS Build Tools. Also, If you want to build chromium (a.k.a the QtWebEngine) for windows you have to use MSVC, that's a limitation imposed by google, as they only support building with the platform-native compiler.
Last but not least, you can get MSYS2, which has a repository with MinGW and a ton of ready to use static and dynamic libraries build for it, so you can avoid the arduous and often failure prone build process.
UPDATE
Just for the sake of reference, for VS build tools 2019, the C++ compiler alone takes up about 4.5 gigabytes of space, or about 8 if you just click "C++ build tools" and leave it at the default. For comparison, GCC 9.x is about 150 mb. In fact, the MSVC compiler alone is larger than the entire extensive collection of packages that I adopted for use throughout the years, plus their dependencies, for a total of over 200 packages. Additionally, I'd say MSYS had packages for about 98% of the libraries and tools I've found myself in need of, and those remaining 2% include libraries it had but were not configured in a way, suitable for my use case. And it goes without saying, the packet manager makes it trivial to keep versions up to date.
I would like to use C/C++ for coding my apps, but I need my apps running on all versions of Windows from XP to Win8, independently by any platforms, run time libraries and so on.
Briefly: What kind/type of C/C++ I suppose to use, be able to run my apps on every type of Windows without any additional installation, just default one. e.g Windows XP SP1
C++ can run on just about any OS, as long as you avoid (or, via conditional compilation, provide alternatives for) anything specific to one OS or version. Win32 code is almost all the same between versions; the main difference is added functionality in newer versions. Between Windows and, say Linux, though? Not so much. You kinda need to pick a platform, unless you want to either stick to text mode (which is pretty close between OSes, thanks to standards) or learn some whole other platform-neutral API like OpenGL, wxWidgets, GTK, etc.
As for which compiler to use, if you're sticking with Windows, I'd recommend Visual Studio. Microsoft has a free (Express) edition that will let you compile Win32 code or .net. (You'll need the paid version, or some playing around with the Platform SDK, to play with 64-bit though.) And the IDE isn't too bad either. If you just want a compiler, the Platform SDK has the same compilers VS has, and includes 64-bit support (and even a bunch of code samples and tools) as well.
As for being independent of any runtime libs: Every C++ compiler that's worth using has a runtime library. If you link statically against it, though, the parts you need will be embedded in your EXE. Alternatively, you have permission to distribute the runtime libs with your app (though you may need to install it via a package they provide, that you bundle together with your app...i forget how all that works).
All popular C++ compilers support XP up. You can statically link the runtime, or, for mingw, you can link against the runtime supplied with Windows.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
I started trying to play with Mono, mostly for fun at the moment. I first tried to use the Visual Studio plugin that will convert a csproj into a makefile, but there seemed to be no version available for Visual Studio 2005. I also read about the MonoDevelop IDE, which sounded nice. Unfortunately, there's no pre-fab Windows package for it. I tried to follow some instructions to build it by combining dependencies from other semi-related installs. It didn't work, but that's probably because I'm a Windows-oriented guy and can barely spell "makefile".
So, my question is this: What's the lowest-energy way to get up and running to try some Mono-based development on Windows?
I'd recommend getting VMWare Player and using the free Mono development platform image that is provided on the website.
Download Mono
Setup time for this will be minimal, and it will also allow you to get your code working in .NET and then focus on porting issues without a massive hassle of switching machines and the like. the VMWare Player tools will allow you to simply drag and drop the files over to copy them.
I'm looking to take a couple of my .NET apps and make them Mono compliant, and this is the path I'm going to take here shortly.
A year later and the answer to this has change greatly. You can now use MonoDevelop on Windows, or if you are more comfortable in Visual Studio you can use the Visual Studio Tools to write everything and then debug on in VM to make sure it is working on Linux.
#Chris I have found that Visual Studio is the best IDE for developing against .NET -- I think the best way to target Mono is really just to develop and build in Visual Studio under Windows then just run those binaries directly on Linux (or whatever other Mono platform you are using). There are free versions of Visual Studio if licensing is a concern. If you are developing under Linux, the best software is probably Eclipse with a Mono plugin (see The Mono Handbook - Eclipse for installation instructions) but keep in mind it doesn't have near the amount of features or language integration Visual Studio has.
#modesty Mono is a 3rd party open source implementation of the .NET framework which allows you to run .NET applications on platforms other than Windows.
One of the best things you can do if developing with Visual Studio for Mono is to get MoMA http://www.mono-project.com/MoMA. This will inspect any number of assemblies that you build and generate a report showing potential Mono problems (e.g., methods not implemented in the mono library). It can be run from a GUI or the command line for use in automated builds.
Miguel had a post about debugging Mono running on linux with remote debugging on Visual Studio. This may be something you want to look into... Using Visual Studio to debug Mono. There is also a new project called CloverLeaf whose goal is enabling debugging Mono on Windows in Visual Studio.
There's just no reason to build your app using Mono; the whole point of the .Net CLR is that the compiled output is cross-platform.
So you can simply build it using your favourite IDE (and if you like IDEs, Microsoft's is the best one to use) and then test it on Mono. Even if you get Mono working on Windows, it wouldn't be a very good test of your app's portability: what if your app does silly things like assuming filenames have backslashes in them, or that there's something special about a folder called Program Files? The best way to do portability testing is to actually test your app on the target platform.
And that's pretty easy to do with a Linux VMware player like the one at http://www.go-mono.com/mono-downloads/download.html.
Personally, I'm just compiling in Visual Studio 2008 as if it were for .Net 2.0 and then running in Mono (VS2008 on Windows in a VirtualBox, Mono on OSX). All the problems come up at runtime, anyway, so the system works perfectly.
I just found this very new link, which is amazing and shows you how to set up Visual Studio 2008 for Mono.
At the same time, setting up Mono on OpenSuse or Ubuntu inside a VirtualBox (Sun's product) is easy, painless, and doesn't force you to abandon whatever platform you normally live in.
This is not relevant to your question, but I might note that I just got into Mono and I'm amazed at how much of .Net is implemented, including much of the Winforms stuff.
My first instinct would be the rather unhelpful "Install Linux". You are somewhat swimming against the current to try and develop in mono under windows. Installing GTK and everything is a bit of a bother in my experience.
If you do feel like using linux, then you could Try Ubuntu
Otherwise:
There's some information here: http://www.mono-project.com/Mono:Windows and it seems the cygwin toolchain might be your best bet. I don't think you're going to be able to avoid makefiles, sadly. I found a slightly more explicit tutorial from O'Reilly.
#modesty: Mono provides the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix. Sponsored by Novell (http://www.novell.com), the Mono open source project has an active and enthusiastic contributing community and is positioned to become the leading choice for development of Linux applications. -- From the Mono site.
Eclipse plugin for Mono is dead. On Linux use MonoDevelop or X-Develop if you like good commercial support (although MonoDevelop is closing on them fast feature-wise). On Windows SharpDevelop has custom MSBuild targets for compiling the code against Mono.
As Mono and MonoDevelop are changing fast, be sure to use the latest released versions, even if they are not marked as stable yet (e.g. versions shipped with stock Ubuntu are terribly outdated).
The VMWare image is a great way to start testing Windows-developed code on Linux. Don't touch cygwin unless you are already very conformable with it.
I liked the idea of trying to use MonoDevelop mostly just to make sure my stuff would work against the Mono runtimes. I guess it would also be possible to get crazy with msbuild and write some custom targets that tried to build against Mono, but that's basically emulating the now-defunct plug-in's functionality which I assume was non-trivial to build. I do have minor experience with cygwin, and I am happy typing "configure" and "make" all day long, but when a problem occurs in that process, I'm virtually screwed. I'll probably try to play with all this again, but if it takes me more than a couple hours to come up with a way to build comfortably against the Mono runtimes, I'll probably just bail.
I will try the Eclipse idea. I use that for Java, so I might be able to get the c# stuff to work. We shall see...