After some time coding in c in a simple console, I decided I wanted to try and code an actual Win32 application. However, upon selecting the option, the sheer amount of unknown code that surfaced on my IDE (Visual Studio 2013) just to open a blank window was overwhelming, as I don't understand half of it's meaning or even what to do, since, even simple printf commands yield no result... Can someone point me to a way to understand the differences between console and application? Or at least someway I can insert my current coding knowledge in an application environment?
答案 0 :(得分：3)
Working with the Windows API can be quite the experience for a newcomer. The act of opening a window does, certainly, involve a lot of boilerplate code. The good news is a lot of that boilerplate rarely changes, and when it does it'll be for very special circumstances that you can go research. That's why Visual Studio spits the whole mess out for you by default.
There are plenty of resources to learn with, including Microsoft itself: https://msdn.microsoft.com/en-us/library/bb384843.aspx
To help situate you, understand that a lot of what you're looking at that's probably confusing are typedefs used on primitive types. This helps maintain backwards compatibility with programs created for older versions of Windows, and adds semantic meanings to types. A lot of the preprocessor stuff you see in header files is actually conditional compilation - it's checking what environment you're compiling in, what version of Windows, etc. and then providing the correct typedefs so that what actually compiles works on the desired Windows platform. Stuff that's greyed out in VS2013 is stuff that Intellisense sees isn't going to be compiled based on the current #defines and a lot of it may be relatively ancient. A big part of the Windows API for a long time was a strong desire to not break backwards compatibility. This was a huge advantage for Windows, because it means my program you wrote for Windows 3.1 isn't going to be hosed by Windows 95 rolling out. Or XP, 2000, Vista, 7, 8, 10, etc. It does mean a lot of stuff makes it into the API and stays there.
They try to hide a lot of that in the headers, but you'll also see deprecated input variables to functions and the like (this parameter should always be NULL...etc), and you just have to read the documentation. Thank the internet.
For example, an LPCSTR is just a const char*, but the LPCSTR signifies that it's a null-terminated constant string. In fact, you may see that's it's not a const char*, but a CONST CHAR* where CONST and CHAR are #defines themselves to make sure the correct keywords and types are used. In your case it'll probably end up being just normal const char*.
My suggestion, rather than diving into about as complicated a C-API as possible, is to look at something like SDL. SDL is a much simpler C API designed to provide an interface to the operating system's windowing, graphics, and input, while hiding the dirty details of the API, be it Windows, Mac, or Linux. https://www.libsdl.org/
It uses openGL for its graphics. If you're making any kind of game you'll be using some kind of graphics API to talk to the video card. The native Windows graphics API is DirectX, but openGL is the very commonly used cross-platform API. Both APIs allow you to make use of a computer's video hardware to render graphics.
Edit: I'll add, since I went off and voiced an opinion on libraries, which is why these types of questions are probably frowned upon, that I think it's fair to say that SDL is the de facto standard for C third-party multimedia libraries. Also commonly mentioned is SFML, which provides much the same functionality but is more object-oriented and written in C++.
答案 1 :(得分：0)
在Visual Studio中，创建win32应用程序项目时，单击“下一步”，然后单击空项目。这将消除Visual Studio为win32应用程序创建的所有内容，但之后您将从没有文件开始。您可能希望从书籍或网站上的一些简单的C程序开始。