DriverStore is a new and a central location in Windows
where all the driver files will be stored., before they are copied to
their final destination during the device driver installation. The
location of the driver store is – C:\Windows\System32\DriverStore
Driver files are stored in folders, which are located inside the FileRepository folder as shown in the image below.
Here is a screenshot from the latest version of Windows 10.
For eg: the driver package developed by Microsoft that contains the core mouse support files is present in the following folder. C:\Windows\System32\DriverStore\FileRepository\msmouse.inf_amd64_neutral_6f653f6716c1448c
Within this folder are the driver files (.sys), driver setup files
(.inf), pre-compiled INF files(.pnf), and an XML manifest file that
contains the manifest of all the files within the driver package.
Together, all of these different files add up to the driver package,
which contains all the files needed to install the device. To protect
these files, the NTFS permissions on the driver store and its
sub-folders and files is full control for the local system account and
Read& Execute for the Everyone built in identity. Earlier in Windows XP and 2000, the driver source files neeeded for
installing the devices were typically found in several locations.
%SystemRoot%\Driver Cache\i386\drivers.cab
%SystemRoot%\Driver Cache\i386\service_pack.cab
.inf files under %windir%inf
.sys files under %SystemRoot%\System32\Drivers
Support DLLs under %SystemRoot%\System32
Third Party co-installers in various locations.
Advantages of maintaining a central store:
Allows for potentially faster device installation and more realiable
driver rollback and is a single standard for un-installing drivers.
Allows you to protect drivers by using the Windows Resource Protection(WRP).
Uses index files to minimize the performance impact on installing
devices when the driver store grows in size as a result of new package
additions.
To learn, How to get an Inventory of all the Installed Device Drivers in a Machine – Read this article
I think We can Store all the Drivers in the “Driversstore”
folder and it may help in Desktop Image management on one Image
supporting multiple hardware models. Am I correct Vijay?
I think We can Store all the Drivers in the “Driversstore”
folder and it may help in Desktop Image management on one Image
supporting multiple hardware models. Am I correct Vijay?
Yes Vivek. This is one very good statergy from Microsoft to have
a central location for driver files., so that the IT Pro’s job gets
easy. They had implemented this in Vista, and it is also present in
Windows 7. Subsequently, it would be present in all OS’s of MS.
I will post out an aricle on how exactly the OS takes this folder and
installs the drivers in a day or two. I think, that will make things
more clear for all, who have been working with Driver packages.
Yes Vivek. This is one very good statergy from Microsoft to have
a central location for driver files., so that the IT Pro’s job gets
easy. They had implemented this in Vista, and it is also present in
Windows 7. Subsequently, it would be present in all OS’s of MS.I will
post out an aricle on how exactly the OS takes this folder and installs
the drivers in a day or two. I think, that will make things more clear
for all, who have been working with Driver packages.
That would be great VJ. Looking forward that information. Please
try to give info on how intelligently the OS will pick up drivers which
is stored, If there any driver confilicts how we can manage it
automatically or so. I hope, you will be doing it.
That would be great VJ. Looking forward that information. Please
try to give info on how intelligently the OS will pick up drivers which
is stored, If there any driver confilicts how we can manage it
automatically or so. I hope, you will be doing it.
now how i should detect my device drivers
I didn’t know that there is even a palce to store drivers in Win7…
win 7 is quite powerful
Thank you so much. Great tip for those that forgot the system32 folder.
Don't forget install the certificates and
use --noweb option, which the questioner mistook.
".... the due to not using --noweb, with it there were no errors."
-
download message in ko_KR
-
-
궁금했다. 하지만 찾는 것이 어려웠고, 내 힘으로는 실패했다. 결국 인터넷 검색엔진에 물었다. _( 검색: location of MSBUILD.EXE )_
답이 나왔고, W7에서 찾아보니, 이 답대로 있었다. 놀라웠다. dotNetFrameWork 버전마다 따로따로 다 하나씩 있었다.
아래와 같다. 2 번째 답은 W8.1에서는(답변자의 개인적(?)인 경험) 좀 다른 위치에 있더라는 것이었다. 8.1에서는 확인하지 못했다. 하지만, 이대로 있을 것 같다. MSBuild 라는 시스템이 무엇인지 설명하는 곳은 아래의 질문/답변 의 아래에 적어 놓았다. 그 내용에는 Windows와 같이 MSBuild 시스템이 배포된다고 되어 있지만, 구체적인 실행 파일 위치는 밝히지 않았다. 대신 MSBuild 의 스크립트(script)에 대해 설명하는 것에 많은 내용을 할당하고 있었다.
I can build and run apps
(specifically Windows Phone 8 apps in C#) in VS 2012 Professional just
fine. But when I attempt to run MSBUILD.EXE from the command line it
fails. A search of my hard drive doesn't reveal the location. Where
is MSBUILD.EXE? If somehow my VS2012 Professional install did not
install it, how can I get it?
I believe that MSBuild is actually installed with the .NET Framework, not Visual Studio. My computer has these versions:
C:\Windows\Microsoft.Net\Framework\v2.0.50727\MSBuild.exe
C:\Windows\Microsoft.Net\Framework\v3.5\MSBuild.exe
C:\Windows\Microsoft.Net\Framework\v4.0.30319\MSBuild.exe
C:\Windows\Microsoft.Net\Framework64\v2.0.50727\MSBuild.exe
C:\Windows\Microsoft.Net\Framework64\v3.5\MSBuild.exe
C:\Windows\Microsoft.Net\Framework64\v4.0.30319\MSBuild.exe
Microsoft's recommended way to launch it is with the Developer
Command Prompt. Type "Developer Command Prompt" in the Windows 8 Start
screen (or Windows 7 Start Menu), and you should see it listed. It opens
a command prompt window with paths set
up for various developer command line tools.
Proposed as answer byDarius VilcinskisFriday, August 30, 2013 11:01 AM
I believe that MSBuild is actually installed with the .NET Framework, not Visual Studio. My computer has these versions:
C:\Windows\Microsoft.Net\Framework\v2.0.50727\MSBuild.exe
C:\Windows\Microsoft.Net\Framework\v3.5\MSBuild.exe
C:\Windows\Microsoft.Net\Framework\v4.0.30319\MSBuild.exe
C:\Windows\Microsoft.Net\Framework64\v2.0.50727\MSBuild.exe
C:\Windows\Microsoft.Net\Framework64\v3.5\MSBuild.exe
C:\Windows\Microsoft.Net\Framework64\v4.0.30319\MSBuild.exe
Microsoft's recommended way to launch it is with the Developer
Command Prompt. Type "Developer Command Prompt" in the Windows 8 Start
screen (or Windows 7 Start Menu), and you should see it listed. It opens
a command prompt window with paths set
up for various developer command line tools.
Proposed as answer byDarius VilcinskisFriday, August 30, 2013 11:01 AM
Just to add more information to the answer, in Windows 8.1, mine show up under
C:\Program Files (x86)\MSBuild\12.0\Bin
and
C:\Program Files (x86)\MSBuild\12.0\Bin\amd64
Thursday, June 11, 2015 6:06 PM
---------
MSBuild 시스템 자체에 대한 소개
출처: https://thomasardal.com/msbuild-tutorial/#MSBuild_Basics
-
.NET 2.0 이후에 도입되었는데, W_Vista 이후부터는 아예 운영체제와 함께 배포된다고 한다. 하지만, 그 이후의 내용에는 스크립트(script) 문법에만 중점을 둬서, 실행파일이 운영체제의 어디에 들어 있는지는 이 tutorial(자습서)에는 나오지 않는다.
책(book)을 만들고 있다고 적혀 있다.
-
MSBuild Basics
.NET 2.0 introduced a new tool called MSBuild. MSBuild is primarily
used to build .NET applications, but can be used for other types of
applications as well. From Windows Vista, MSBuild is distributed with
Windows itself, making it a strong platform for implementing scripted
application on non-developer PCs as well.
Windows SDK Fails to Install with Return Code 5100
Symptoms
When
installing the Microsoft Windows SDK for Windows 7 and .NET Framework 4
(Windows 7 SDK), you may see the "Installation Failed" dialog which may
contain the following information:
Installation
of the “Microsoft Windows SDKfor Windows 7” product has reported the
following error: Please refer to Samples\Setup\HTML\ConfigDetails.htm
document for further information.
The setup log file contains the following error message:
C:\Program Files\Microsoft SDKs\Windows\v7.1\Setup\SFX\vcredist_x86.exe installation failed with return code 5100
OR
C:\Program Files\Microsoft SDKs\Windows\v7.1\Setup\SFX\vcredist_x64.exe installation failed with return code 5100
Cause
This
issue occurs when you install the Windows 7 SDK on a computer that has a
newer version of the Visual C++ 2010 Redistributable installed. The
Windows 7 SDK installs version 10.0.30319 of the Visual C++ 2010
Redistributable.
Resolution
To
resolve this issue, you must uninstall all versions of the Visual C++
2010 Redistributable before installing the Windows 7 SDK. You may have
one or more of the following products installed:
Microsoft Visual C++ 2010 x86 Redistributable
Microsoft Visual C++ 2010 x64 Redistributable
After
uninstalling the Microsoft Visual C++ 2010 Redistributable products,
you may install the Windows 7 SDK. After installing the Windows 7 SDK,
you may then reinstall the newer version of the Visual C++ 2010
Redistributable products, in order to restore the Visual C++ 2010
Redistributable products to their original state.
This document describes how to use either the Windows SDK Command
Prompt window or Visual Studio to configure application build settings
for use with native code projects and managed code projects. It also
describes how to upgrade Visual C++ projects that use the .vcproj file
format so that they can use MSBuild.
The Windows SDK for Windows 7 and the .NET Framework 4 (later
referred to as the Windows SDK) includes compilers that let you build
Visual C++, Visual C#, and Visual Basic applications. You can use these
compilers directly or use the nmake tool to use these compilers from a
makefile. You can also use MSBuild to build Visual C++ (.vcxproj),
Visual C# (.csproj) and Visual Basic (.vbproj) projects or Visual Studio
solutions (.sln).
The following table provides links to more information about how to
use the compilers and build tools to create Visual C++, Visual C#, and
Visual Basic applications.
If you do not have Visual Studio 2010, you can use the Windows SDK
Command Prompt window and the SetEnv utility to configure your
application build settings. The SetEnv utility lets you build
applications for a specific operating system and computer architecture.
The default settings target the operating system on which the Windows
SDK is installed.
To open the Windows SDK Command Prompt window, click Start, then All Programs, then Microsoft Windows SDK v7.1, and then Windows SDK 7.1 Command Prompt.
At the command prompt, run the SetEnv utility to configure the build
environment for a specific operating system, computing architecture, or
build configuration. The SetEnv utility uses the following syntax:
SetEnv.cmd [/Debug | /Release] [/x86 | /x64 | /ia64] [/vista | /xp | /2003 | /2008 | /win7] [-h | /?]
The following command configures the build environment to create
64-bit Windows 7 applications that use the Debug build configuration: SetEnv.cmd /Debug /x64 /win7
SetEnv configures the build environment to create Windows 7 applications by default if you do not specify the operating system.
The following table describes the SetEnv options. Options that create
applications for a specific operating system apply only to the nmake
utility.
Option
Description
/Debug
Create a Debug configuration build environment.
/Release
Create a Release configuration build environment.
/x86
Create 32-bit x86 applications.
/x64
Create 64-bit x64 applications.
/ia64
Create 64-bit Itanium applications.
/vista (nmake specific)
Create Windows Vista applications.
/xp (nmake specific)
Create Windows XP SP2 applications.
/2003 (nmake specific)
Create Windows Server 2003 applications.
/2008 (nmake specific)
Create Windows Server 2008 or Windows Vista SP1 applications.
/win7 (nmake specific)
Create Windows 7 applications.
-h, /?
Display command usage.
Configuring Visual Studio for Visual C++ Development with the Windows SDK
The Windows SDK provides headers and libraries for creating Windows
applications that use native code. These are the same as those that come
with Visual Studio 2010, except that the Windows SDK provides newer
versions of some tools.
The following sections describe how to configure Visual Studio 2010
and Visual Studio 2008 to use the headers, libraries, and tools that are
included in the Windows SDK.
Using the Windows SDK Tools with Visual Studio 2010
To use the Windows SDK tools in Visual Studio 2010
In Visual Studio 2010, open a solution (.sln) file or create a solution.
In Solution Explorer, right-click the project node and then click Properties.
In the Configuration list, select All Configurations.
Under Configuration Properties, select General.
As the Platform Toolset option, select Windows7.1SDK.
Click OK.
Using the Windows SDK Tools with Visual Studio 2008
You can use the Windows SDK Configuration Tool to configure the
Windows SDK for use with Visual Studio 2008. The following steps
describe how to use the Windows SDK Configuration Tool in the Visual
Studio 2008 user interface and in the Windows SDK Command Prompt window.
To use the Windows SDK Configuration Tool in Visual Studio 2008
Start the Windows SDK Configuration Tool by clicking Start, then All Programs, then Microsoft Windows SDK v7.1, and then Visual Studio Registration.
Right-click Windows SDK Configuration Tool and then click Run as administrator.
In the Windows SDK Configuration Tool, in the list, select v7.1.
Click Make Current.
To use the Windows SDK Configuration Tool in the Windows SDK Command Prompt window
Open the Windows SDK Command Prompt window by clicking Start, then All Programs, then Microsoft Windows SDK v7.1, and then Windows SDK 7.1 Command Prompt.
Navigate to the ..\ Windows SDK installation folder\Setup\
folder, for example, C:\Program Files\Microsoft
SDKs\Windows\v7.1\Setup\.
Type WindowsSdkVer.exe -version:v7.1.
Upgrading Projects to Visual C++ 2010
For Visual C++ projects, MSBuild 4.0 works with the Visual C++ 2010
project file format, .vcxproj. This section describes how to upgrade
Visual C++ projects that use the earlier .vcproj format so that they use
the .vcxproj format.
If you have Visual Studio 2010, you can use devenv.exe and the /upgrade option to upgrade earlier projects to the current format. For more information about the /upgrade option, see /Upgrade (devenv.exe).
Otherwise, you can use the vcupgrade tool to upgrade earlier projects.
The vcupgrade tool works on project files from Visual Studio 2005 and
Visual Studio 2008.
You can use the vcupgrade tool in the Windows SDK Command Prompt window, which you can open by clicking Start, then All Programs, then Microsoft Windows SDK v7.1, and then Windows SDK 7.1 Command Prompt. The following command uses vcupgrade to upgrade a project named Hello.vcproj to use the .vcxproj format: vcupgrade.exe Hello.vcproj
This command produces Hello.vcxproj as its output. You can then use
MSBuild to build the project, as shown in the following example: MSBuild.exe Hello.vcxproj /t:Rebuild /p:Configuration=Debug
Important
If your solution contains multiple Visual C++ projects, you must run
vcupgrade on each Visual C++ project to upgrade it to the .vcxproj file
format. In addition, when you use vcupgrade to upgrade a project to the
.vcxproj file format, vcupgrade does not update the corresponding
solution (.sln) file. Therefore, you must specify the upgraded projects
and not the solution file when you use MSBuild.
Working with 64-bit Visual C++ Projects
You can use the Visual C++ 64-bit compiler to target 64-bit computing
architectures. Many of the Windows SDK sample projects also support
64-bit. For information about how to configure Visual C++ projects to
target 64-bit operating systems and how to troubleshoot common Visual
C++ 64-bit migration issues, see 64-Bit Programming with Visual C++.
See Also
-
-
내가 몇년 전에 찾아 헤맸지만 찾지 못했던, Vista 이후의 바뀐 thumbnail 작성 방법에 대한 내용도 찾았다.. 너무 늦었나?
-
Top Ten Things You Can Do to Create Vista-Style Applications
Rich Preview is provided by a lightweight tool which is
integrated into Windows Explorer, the Common File Dialog, and Outlook
12. It enables end users to browse content by providing a read-only
preview of data without having to launch the associated application.
If you install the "Windows XP Support" option in
Visual Studio 2012 or later, then you already *have* the Windows 7.1A
headers & libraries. They are used by the ``v1??_xp`` Platform
Toolset option. See this blog post. Known issue: The Windows 7.1 SDK installer has the same conflict issue with the updated Visual Studio 2010 REDIST files as the DirectX SDK (June 2010) release. See KB 2717426 for details. Known issue: If you try to install the Windows
7.1 SDK on a system with VS 2012 Update 1 or later, VS 2013, or VS 2015
it will likely fail. This I because these versions of Visual Studio
already included a trimmed down Windows 7.1A SDK to support the "v1x0_xp"
Platform Toolset. The Windows 7.1A SDK does not include samples, so if
you are trying to get those legacy samples you should set up a fresh
machine or VM to install the original standalone Windows 7.1 SDK, then
copy out the desired files. Windows SDK for Windows 7 and .NET Framework 4.0 (v7.1) is now available. It includes a free command-line version of the Visual C++ 2010 compiler including support for /analyze
static code analysis. This release of the Windows SDK supports Windows
7, Windows Server 2008 R2, Windows Server 2008, Windows XP SP3, Windows
Vista, and Windows Server 2003 R2 using Visual Studio 2005, 2008, or
2010. Web installer or ISO download.
Note that the DirectX SDK (June 2010)
relies on the Windows SDK platform headers and libraries that shipped
with the Visual Studio 2008 (Windows SDK 6.0A) or later. The WindowsTouch sample requires Windows SDK 7.0 or later to compile.
This version is slightly newer than the Windows SDK that ships with VS 2010 itself (Windows SDK 7.0A).
For VS 2005 and VS 2008, integrating Windows SDK 7.1 works the same
way as it had previously updating the global settings. Be sure to
reference the DirectX SDK include and lib paths before the Windows SDK
to ensure proper search order.
For Visual Studio 2010, the Windows SDK 7.1 creates new platform
targets for its headers which have to be selected on a project basis
under the setting Platform Toolset.
"
This value defaults to v100 which is the VS 2010 compiler toolset and the Windows SDK 7.0A. With the Windows SDK 7.1, you get a new option Windows7.1SDK which uses the VS 2010 compiler toolset that ships in the Windows SDK along with the updated headers and libraries.
If you have Visual Studio 2008 installed, you will also be able to select v90 which is the VS 2008 compiler toolset and the Windows SDK 6.0A. The v90
is required for Managed C++ .NET 2.0 development since the VS 2010
toolset only supports .NET 4.0 development. We also use this technique
with the DirectX SDK Content Exporter sample in the June 2010 release because the version of the Autodesk FBX library
we use for that sample does not include VS 2010 libraries, and
therefore we have to use the VS 2008 toolset to ensure we are using the
VS 2008 C Runtime.
The DirectX SDK (June 2010) does not create its own Platform Toolset because it does not include a C++ compiler like the Windows SDK
does. Instead, we explictly add VC++ Directory settings to each VS 2010
project that include the DX SDK path references using the $(DXSDK_DIR) variable.
The Windows 7.1 SDK includes the headers for Direct3D 9,
Direct3D 10, Direct3D 11, DirectSound, DirectInput, DirectMusic 'core'
APIs, and XInput 9.1.0. The d3dcommon.h is slightly outdated compared to the version in the Windows 8.0 SDK and the DirectX SDK (June 2010), so the newer defines like D3D_PRIMITIVE_TOPOLOGY, D3D_PRIMITIVE, D3D_SRV_DIMENSION, etc. are not defined for the Windows 7.1 SDK version. You'll need to use D3D10_ or D3D11_ versions instead. Update: The Windows 7.1 SDK provides the VS 2010 RTM
compiler, and can overwrite VS 2010 Service Pack 1 files if installed
on the system. See this for a fix. Related: A Brief History of Windows SDKs, DirectX SDKs of a certain age
-
referrence: https://stackoverflow.com/questions/2797366/win32-thread-exits-unexpectedly
-
이런 기능이 있었다....
....
The easiest way to find the problem would be to run your application under a debugger and enable breaking on Win32 Exceptions. Whenever a Win32 Exception is encountered, the application would break into the debugger and you can find out whats going wrong.
If ....
-
이런 것이 처음 나타났다. 하지만, debugger 에도 이것을 처리하는 break체크박스 옵션이 있었다.
네이티브' 프로그램이 -1073741511 (0xc0000139) 코드에서 끝났습니다.
Software.exe': 'C:\WINDOWS\system32\rpcrt4.dll' 로드, 기호가 로드되지 않았습니다.
'Software.exe': 'C:\WINDOWS\system32\version.dll' 로드, 기호가 로드되지 않았습니다.
'Software.exe': 'C:\WINDOWS\WinSxS\x86_Microsoft.VC**.DebugMFC_1fc8b3b9a1e18e3b_*.*.50727.762_x-ww_257740a4\mfc**d.dll' 로드, 기호가 로드되었습니다.
'Software.exe': 'C:\WINDOWS\WinSxS\x86_Microsoft.VC**.DebugCRT_1fc8b3b9a1e18e3b_*.*.50727.762_x-ww_5490cd9f\msvcr**d.dll' 로드, 기호가 로드되었습니다.
'Software.exe': 'C:\WINDOWS\system32\shlwapi.dll' 로드, 기호가 로드되지 않았습니다.
디버거:: 프로세스 로드 중에 처리되지 않은 비연속적 예외가 Throw되었습니다.
'[1720] Software.exe: 네이티브' 프로그램이 -1073741511 (0xc0000139) 코드에서 끝났습니다.
GetThreadId 라는 함수는 WindowsServer 2003에서만(?), 지원된다고 한다. ....
그래서 안되었던 것이다. 지원되는 OS가 아니라서.. ....
다른 함수를 골라서 사용하기로. .....
거의 찾은 듯하다. .....
AFX_ISOLATIONAWARE_FUNC(BOOL, ImageList_Destroy, (HIMAGELIST himl), (himl), FALSE)
--------
거의 찾은 듯했으나.... 아니었다. Thread ID 등을 표시하는 것은 이 오류(예외)를 찾는 데에는 전혀 상관없는 삽질이었다. 이것을 고치는 방법은 전혀 다른 곳에 있었다. 기본적으로, 이것은 Multi-Thread _와는 본질적으로 무관한 오류였다.
일단 방법은, 위에서 찾은 Exception (한국어로 예외....) 메뉴를 Visual Studio (Visual C++) IDE에서 찾아서 (디버그(Debug) 메뉴(Menu) >>> 예외...(Exception...) 항목 클릭(click) 하면, 나오는 목록 상자에서 Win32 Exception(예외) 를 찾아서 C0000005 (C로 시작해서 000...이 이어지다가 5로 끝나는 것)을 체크하는 것이었다. 찾아보니, 통신이라든가 .. 와는 전혀 다른 것이었음이 밝혀졌다. Multithread 와는 전혀 관계가 없었다는 (좌절)이었다. 언제나 그렇지만, 어쨌든 찾은 것이 잘 된 것이다. 도움을 받지 않으면 이렇게 헤맨다.
하지만, 아직은 고치지 못한다. 찾아낸 그 부분을 보니, 여전히 어렵다. 다만, 엉뚱한 곳은 아니다. 위치는 찾았지만, 아직도 고치기는 확신이 서지 않을 정도로 어렵다.
이것이 가진 효과는 ? 아래의 프로그램을 참고하자. x 는 R 이 붙은 것이고, y 는 R 이 없는 것이다.
그리고, R이 붙은 것에는 따옴표 안에 괄호들이 하나씩 있어야 한다는 것이다. 따옴표 내부의 따옴표에 붙은 괄호는 문자열에서는 없어진다.
R이 붙지 않은 것에는 따옴표 내부의 괄호들이 출력된다.
#include <iostream>
int main()
{
auto x = R"(Hello world!\n \r my world\nhello. my work!)";
auto y = "(Hello world!\n \r my world\nhello. my work!)";
std::cout << x; std::cout << x;
std::cout << x;
std::cout << y;
std::cout << y;
std::cout << y;
// 한글일 때에는 ....ㅇㅇㅇㅇㅇ... 알수가 없다.
// 어떤 것이 있는가
// std::c
}
실행 결과는 다음과 같다.
.... 라고 하려다가, 호기롭게 했지만, 역시나, 내가 linux에 적응하지 못하는 부류인 관계로, linux/unix 터미널 창 제어를 못해서... 결과를 복사하지 못했다... Code::Block 환경 내에서는 실행이 잘 되는데, 왜 나는 할 수 없지? sudo 등등을 써 봐도, ./(실행파일_이름) 등등 내가 예전에 알고 있던 별 수를 다 써 봐도 안되고.. 실행 파일이 없다는 황당한 메시지만 받고, ls 명령을 해 보면 현재 디렉토리에 분명히 실행권한이 있는 파일이 존재하는데, 실행하려고 하면 없다고...
역시 나는 ... 이런 모든 것을 만든 분들이 위대해 보일 따름이다.
결국 설명은... R이 따옴표 앞에 붙으면, 보통-괄호(중간-괄호 또는 대괄호가 아닌..) _가 따옴표 바로 내부에 붙어야 한다. 그럼, 괄호 자신과 큰 따옴표도 들어갈 수 있다는 것이겠지...
하여간 그러면, \r, \n 이것들이 모두 해석되어서 CR(Carriage Return) 동작이라든가 NL(New Line)동작으로 작동하는 것이 아닌, 그냥 화면에 소스코드에 나온 그대로 \r 로 표시되고, \n 으로 표시된다. \ 문자(back slash)의 C/C++ 언어에서의 특수 해석이 작동하지 않는다는 것이다.
반면에, R이 없는 경우에는 \r 은 커서를 줄의 첫 자리로 옮기고, \n 은 줄을 바꾸는 기능으로 변환해석되어서 작동한다.
조금만 더 예를 들면,
x = R"Hello(Hello( (my ("") \r \n one))Hello";
였다면, x가 출력될 때에는
Hello(my ("") \r \n one)
이 출력되는 것이다. 표현하고 싶은 문자열을 감싸는 경계표시는 시작부분이
R"Hello( 로 시작되고, )Hello" 로 끝나고 이 경계표시는 실제 문자열에는 포함되지 않는다. 이 처음 괄호가 시작되기 전에 들어가는 경계표시 문자열에는 공백문자(스페이스)가 들어가면 안된다.
앞에는 맥OS에 설치하는 방법이었는데,
윈도(윈도10)에 설치하는 방법이 나오기도 했다. 그런데, 우분투를 먼저 윈도10에 설치하라는 재미있는 내용도 있었다.윈도10에 우분투라... MS 스토어였다. https://www.microsoft.com/ko-kr/p/ubuntu/9nblggh4msv6?activetab=pivot%3Aoverviewtab
우분투의 console(terminal?)을 설치하는 것이라고 했다. ubuntu에서 사용하는 몇가지의 여러 shell 명령어를 사용할 수 있게 해 준단다. 모두가, 오래 전에 리눅스 등등의 open source unix 계열에 관심을 접었고 그 이후로 오랜 시간을 지낸 내게는 어리둥절한 혼돈스런 말들이었다. 모두가 뒤섞인다...
I will post out an aricle on how exactly the OS takes this folder and installs the drivers in a day or two. I think, that will make things more clear for all, who have been working with Driver packages.
Thank you so much. Great tip for those that forgot the system32 folder.