Currently I'm working on a simple game engine project. I would like it to be independent from the platform, so for started I've taken only classical Windows Desktop application and Metro Style app.
From this picture:
Windows APIs
We can see that the C/C++ blocks are common for both parts. In other words, I would like to easily switch between platform configurations. I've created simple WinAPI static library that you can easily include in the project, as well as DirectX game-engine and it works perfectly. However, I'm having issues to do the same with WinRT (used in Metro Style apps).
Is it possible to have one Visual Studio project that can use WinAPI or WinRT? It would be perfect if I could have like one single entry point for a game and just switch underlying APIs.
No. A single VS project that either generates a classic win32 exe and a WinRT (nowadays Universal) applications is not possible.
In theory they could have made it possible, like you can have a single project that generates a console application or gui application. The difference between the two boils down to one (or two) flags.
The difference between a classic exe and a WinRT app is quite big: There are manifests and packaging and special sauce signing not to mention the resources (icons, etc) are specified differently.
In the Visual studio UI this is manifested by a different set of property pages, besides the common core of compiler + linker ones of course.
The other reason is one of strategy. Microsoft wants you to move forward and embrace the WinRT API. That is the API set that works across all Windows devices (if you ignore the Win7 elephant in the room). Supporting a dual mode will send the wrong signal to developers.
As a side note that the very windows headers (windows.h) are annotated by API family. CreateNamedPipe is #ifdef out in a WinRT application, or for example there is CreateFile for classic apps and CreateFile2 for modern apps.
Related
I want to know what is the difference between windows form application, win32application ana console, i know that both the windows form application and win32 application is gui tool, but i want to know when to use one over the other one, and could I convert console application to windows form application ?
Windows Form refers to a .NET application. It's not based directly on the native Windows API, but instead on the .NET infrastructure. Which includes a virtual machine.
Win32 generally refers to the 32-bit Windows API. However, the _WIN32 macro is defined for both 32-bit and 64-bit programming. As a Visual Studio project type it includes both GUI and console subsystem API-level programs.
A Windows subsystem is a small integer value in the executable's header that tells Windows what kind of services this program needs. This value can be inspected via e.g. Microsoft's dumpbin program, e.g. dumpbin c:\windows\notepad.exe /headers | find "ubs". In Windows 9x the dumpbin output was available via the file preview functionality, but that feature was discontinued.
Each process in Windows can be associated with one, and at most one, console window.
GUI subsystem means that Windows will NOT attempt to outfit each instance with an associated console window. The process can however create a console window itself. Usually this subsystem is used for ordinary programs with a graphical user interface (hence, "GUI"), and with most linkers it's specified as "windows".
Console subsystem means that Windows will attempt to outfit each instance with an associated console window, creating a new one if necessary.
Note that
The same source code can be built as console or GUI subsystem. And that's extremely easy to do. Just change the subsystem specification.
A GUI subsystem executable has standard streams, just as a console subsystem executable has.
A console subsystem executable can present a graphical user interface, just as a GUI one can.
Also note that
Microsoft's tools will by default not accept a standard C++ main for a GUI subsystem build. However, this non-conforming behavior is easy to fix. Just specify /entry:mainCRTStartup in the linker options.
There is no such problem with the GNU tools, that is, g++.
windows form applications are applications that use the graphical programming interface frameworks such as .NET, DELPHI, or MFC instead of directly calling the win32 API.
On the other hand, win32 application usually deals directly with windows api to create applications from bottom up.
And console applications don't have any graphical interface. Only command line window is used for data input and result output.
A "windows form application" is a GUI .NET app.
A "win32 application" is a native Windows GUI app.
A "console application" is a native app without GUI.
I don't really understand what you exactly mean by "convert" one kind of app to another kind. But. If you are talking about using some IDE and convert a project to another one : YES it is possible. What makes the main difference is the .DLLs you linked your app with. You can configure a project opened as "console" to behave as a "win32" for example. It is not really easy, but it remains possible. Nos if you want to know if a given existing application that you installed can be converted : NO.
I have an executable I made using a CLI console application with Visual Basic 2010. I can run the program completely fine from my developer machine.
However, when I copy the executable over to another machine, re-boot to a pre-installation environment and run the executable again, nothing happens at all. There are no errors shown or anything.
My guess is the executable can't run without certain dependencies that aren't loaded at this environment, but I need it to work in a PE.
Any ideas on whats going on?
First of all, since the question is tagged "c++" and you mention C++/CLI several times, I assume that "Visual Basic 2010" is a typo for "Visual Studio 2010". But either way, whether you've written the application in Visual Basic (VB.NET) or C++/CLI, the problem is exactly the same.
My guess is the executable can't run without certain dependencies that aren't loaded at this environment, but I need it to work in a PE.
That's exactly correct. You've written an application that targets the .NET Framework. Somewhat like Java applications requiring a JVM, .NET applications require that the .NET Framework be installed in order to run (or a compatible alternative implementation, like Mono). Unfortunately, Windows PE does not support the .NET Framework.
Note that it is irrelevant whether you've written a WinForms, WPF, or Console application. Although they present their UI in very different ways, they all depend on the .NET Framework being installed.
You will need to (re-)write the application in a different programming language, one that generates native code without any dependencies on the .NET Framework. C and C++ are popular choices. If you choose to use C++, make sure that you create what Visual Studio calls a "Win32" project. This is one that targets the underlying operating system APIs directly (i.e. a native application) and does not have a dependency on the .NET Framework. Stay away from anything that has ".NET" or "CLR" in its description.
I don't really have a full comprehension of when an application is using .NET or not... I am just used to Linux C/C++ development. I hate Microsoft shit
It uses .NET whenever you use the .NET Framework libraries/classes in your code. I'm not really sure why this is so difficult to understand. The same problem could easily exist on Linux if you were using a third-party library that was not available in certain environments for whatever reason. This is not Microsoft's problem, it's an issue of using the wrong tools for the job. The .NET Framework is an object-oriented wrapper around the native APIs that makes it much easier for people to get up and running writing programs for Windows. But if you're "used to Linux C/C++ development", you should have little trouble writing a simple console application that targets the native APIs directly without using .NET.
If your hatred for "Microsoft shit" has turned into an allergy, you can avoid Visual Studio entirely and download MinGW, which is a Windows port of the GCC compiler you're probably used to. Combined with your favorite Windows port of Vi, you're working in an environment very similar to the one you're used to. And since GCC doesn't support C++/CLI or the .NET Framework, you won't have to worry about getting stuck picking the wrong option.
The .Net framework has been supported as an optional package install during your PE build process for the past couple versions of WinPE. I write code in C# that I run in WinPE everyday. I have yet to find a good way to debug in a manner where I can walk through break points, etc... though. My best option has just been a lot of logging and a global Exception catch around my main entry point that will write out a full stack dump. You can attach to your app as a remote process in a VM running WinPE, but if you need to catch something early in the execution you'll have a difficult time.
I have a project that requires writing a code for small executable file. I used visual C++ express 2010 IDE to create this file. After I finished writing the code, I tried to copy it to a couple of different PCs. It gives me an error message every time I clicking on this file to execute it. The message states that I have to install (.NET framework). I watched a couple videos on YouTube explaining how overcome this problem by changing the runtime library from multi-threaded Debug DLL (/MDd) to multi-threaded Debug (/Mtd). However; the IDE can’t debug the C++ code because when I create my project by using CLR template!
Is there any way to solve this problem? Can I create a similar program that not requires any further downloading once I using on different PC?
Is learning a different language like JAVA or C# will help creating small programs (like my program) that run on most Window platform machine?
Just use Qt - it runs on Windows, Linux, MacOS, support for Android and iOS is scheduled for this year, plus it supports embedded platforms and some of the more obscure mobile platforms. Also, support for Windows RT was just kickstarted. A complete library with tons of functionality, good documentation and lots of educational resources. It provides tons of tools, from implicitly shared containers through threading, signals and slots, 2D and 3D graphics, widgets, multimedia, sensors... and whatnot...
You can even develop commercial applications under the LGPL license.
Also comes with a pretty good IDE - Qt Creator.
You can develop standard C++ applications or use QML, which is a JavaScript like language for markup and scripting, which is used to build applications from C++ implemented components. You can also extend QML. It is much faster to develop with QML and you still get the advantages of platform native binary under the hood.
Note that you will still need to either ship a few DLLs with your application. Unless of course you use a static build, which requires you to either have your application open source, or purchase a commercial license... which doesn't come cheap...
But still, a few MB of DLLs are far better than the entire .NET framework. A static build will produce executables about 8-9 MB with no external dependencies.
Stick with the C++ standard, avoid Microsoft extensions (managed code), and call only POSIX functions of your OS, then you should be able to write portable programs.
You seem to have created a Managed C++ Project. Instead create an empty Win32 C++ project and then add in your .cpp/.h files. This will limit you to the default libraries available on all PCs with the C++ runtime. If you want to remove that dependency too then statically compile in the runtime using the /MT option. Details # http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.71).aspx
As you move ahead you would need to be conscious of what libraries you take dependencies on and what versions of the OS are those libraries available on or if you need to package them with your bits.
Both Java and C# will help making portable programs. Usually, people will have to install runtime environments for executables written in these two languages, however. These days, C++ is more portable than ever. You can easily run C++ executables in your browser:
https://github.com/kripken/emscripten
http://code.google.com/p/nativeclient/
This makes many of the reasons why Java and C# came about irrelevant.
Open standards like OpenGL also make portable GUI programming easier than ever. Try Qt, if you want to write a simple GUI in C++.
Note: It is possible to run C++ program in any computer without installing anything if you haven't use .NET framework. In your case, there can be two reasons to trigger error in target computer.
New computer doesn't have required run-time assembles.
New computer doesn't have required .NET framework installed.
..........................................
So what to do:
Before start your program you have to design weather are you going to use .NET framework support or not. If you use .NET framework when you develop your program, then you much install same or higher .NET framework in target computer.
If you no need to use .NET component then your target computer should only containing run-time assemblies.
How to get rid of .net framework
right click on the project in solution -> properties -> General -> Common language run time support -> select "No common language run time support".
..........................................
Then what you need is only relevant run-time assemblies be in target computer.
How can run-time assemblies be in new computer:
There are two ways:
Install suitable C++ disputable environment in target computer(if you use VS2008 SP1, C++ RD package should be this. Please consider the solution build architecture also (32 bit/64 bit) before download ).
Deploy run-time assemblies with your solution package. (I like this because user no need to install any third party components)
..........................................
How Deploy assemblies with my project:
for this your all DLL, LIB, EXE should use same run time version.(if not, you face troubling to redirect assemblies by 'manifest' files ).
How to check the run-time version.
open DLL,EXE by visual studio (open->file) -> expand RT_MANIFEST-> double click the file under it ->then assembly dependency details will open. -> copy the data in right column and paste to note pad.
You will see this kind of line there. and ther is the version run-time assemblies your specific DLL or EXE use.
assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86".....
After identifying the version of run-time assemblies follow this tutorial and try to run in fresh installed computer.
At last: If you think this bla.. bla.. is so complex and your program is very simple, then you can consider about "run time assemblies statically linking" (try Google). But personally I don't like this method.
good luck!
I have to create an application for testing that is relatively simple. If a user plugs in a device into a USB (hid library), the form will say "Pass". If no device is detected, it will say "Fail".
I want to create the app to run on WinXP+. It must be a forms application as it needs to be visual and have colors. The biggest requirement for me is that it must be stand-alone (a user just double clicks, the file and it opens, no installation). I need to avoid installing any extra .dll files and want to avoid the .net framework all together. It has to be written in C++.
So my question is, what are my options? I am new to Forms applications and the only forms application I have written required the .net framework.
From my research, Visual C++ seems out of the question as it requires .net for Forms apps. What about Turbo C++ by Borland? It seems outdated, but can it do the job?
I would suggest Borland C++ Builder 5 or 6. Visual C++ lacks the functionality to create C++ form apps, if we dismiss MFC
I'd say Visual C++ would probably still be your best option. A standard simple Win32 C/C++ program using only the native API will should suite your needs just fine. If you're targeting XP+, then the only dependency would be "msvcrt.dll" which is included with Windows by default.
Edit: This article on MSDN should get you started in the right direction.
What you're talking about is C++/CLI, it's microsoft's dialect of C++ that requires a .Net framework. Please distinguish it from real (native) C++, which can be used to create what you want to. Visual C++ is perfectly fine, just make sure you don't create a .Net project.
Forms are a .NET library. It's not Windows or anything like that, you can use the native GUI libraries in Win32 with no problem or any native wrapping of them. You can implement this in native C++ easily in Visual Studio.
If you're looking to create the application in a rapid fashion (i.e. stock UI components that you can drag and drop onto forms), my experience is that Embarcardero C++ Builder effectively solves that problem space.
I like Visual C++ but it's not a great environment for rapidly creating forms based applications. I want to emphasize that I'm referring to Rapid Application Development (RAD) tools. There are plenty of great C++ IDEs and libraries for creating forms based applications and all of them should be able to create standalone exes.
Here is a list of related questions that might help in your decision:
https://stackoverflow.com/q/1754020/4916
https://stackoverflow.com/q/93326/4916
Best C++ IDE or Editor for Windows
I have built a windows C++ application that I'd like to port to linux. The main reasons to do this is ease of system maintenance for our IT staff. Apart from the one windows machine that runs this application we're a linux only operation.
The reason this application was built in-, and runs on- windows is that it uses a windows API (dll and header) to connect to a server belonging to an external party. This connection uses some proprietary protocol that I don't really want to mess with, (and I think I'm contractually not allowed to) so I'm stuck with the .dll.
This dll is windows only because of (I suspect) windows sockets specific code in the dll. Apart from that it doesn't do a whole lot of advanced stuff. Is there a way somewhere between just running the app on linux in WINE and sniffing out the protocol and reimplementing the DLL myself that will allow me to get this application to run on a linux machine?
This idea got inspired by this item about QT creator so any solution that allows me to play with that would be extra cool.
The most obvious middle ground would be to use Winelib. I do not know if it can link directly to a native DLL, but if not you probably could load it with LoadLibrary().
You could then split your application in two parts: a wrapper which only calls the DLL, and the rest of the code talking to your wrapper. You could have both in separate processes, and thus only the wrapper would have to be compiled with Winelib. The rest of the application could then use whatever framework you want.