I want to set memory size in Windows 10 Sandbox configuration file. Already I set required change in the configuration file but not working. I have followed this <MemoryInMB>value</MemoryInMB> command from Microsoft Windows sandbox configuration, but it's not working. Below is my Windows Sandbox configuration script:
<Configuration>
<VGpu>Disable</VGpu>
<Networking>Default</Networking>
<MemoryInMB>10240</MemoryInMB>
</Configuration>
Here VGpu and Networking are working properly, but the memory size has not changed.
MemoryInMB is a new feature, introduced with Windows 10 build 2004:
https://learn.microsoft.com/en-us/windows/whats-new/whats-new-windows-10-version-2004
Older versions of Windows will just ignore this tag.
It has to do with the minimum. If I am not mistaken the minimum is 2GB. Try setting it up for more than 1024MB, e.g. 8192MB (8GB)
Related
I was going through this appdynamics document page for the installation of C/C++ SDK.
C/C++ SDK installation on Linux
But since, i am doing this for the first time, i am not sure what is meant in the 3rd point.
I think i have to set the location in my LD_LIBRARY_PATH env variable and then invoke them by typing
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/appdynamics-cpp-sdk/lib
Can somebody explain, what needs to be done?
Yes - you need to set "/opt/appdynamics-cpp-sdk/lib" in your "LD_LIBRARY_PATH" environment variable to use the SDK as you have posted.
Generally this is put in a script used to build your application which you are wanting to instrument.
My goal is to be able to adjust the font size at runtime in a C++ app, based on the monitor resolution.
In this question, it's explained how to get the font scaling percentage, but the suggested function GetScaleFactorForMonitor requires Windows 8.1. My C++ app must run on Windows 7 or higher. I have tried several proposed solutions based on getting the ratio of device caps parameters, but they all get 1.0 on a Windows 10 system where the Windows "Make everything bigger" setting is 150%.
Per the MS docs, Visual Studio is adding "dpiAware" to the manifest (this is a setting I can change). Probably because the app is being built on a Windows 7 system, the VS-generated manifest does not include Windows 10 as a supported O/S. If I add the lines
<!--This Id value indicates the application supports Windows 10, Windows Server 2016 and Windows Server 2019-->
<supportedOS Id="{{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
to the manifest, when I run the app on Windows 10, I get a "side-by-side" error.
How can I get this "make everything bigger" and the "make text bigger" settings on a Windows 7 or 10 system?
Build system: 64-bit Windows 7, Visual Studio 2019 16.7.7 Run system: Windows 7 or later
After discussing in the comments, it turns out your actual problem is that you don't declare DPI awareness in your manifest correctly.
You need to merge this into your manifest:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
</windowsSettings>
</application>
</assembly>
Explanation:
dpiAware true is recognized by Windows 7 and Windows 10, and declares system-wide DPI awareness (DPI_AWARENESS_SYSTEM_AWARE). System-wide means that it assumes that all applications on all monitors use the same DPI setting).
dpiAwareness is recognized by Windows 10 (Windows 7 ignores it) and, if present, supersedes dpiAware. It declares per-monitor DPI awareness (DPI_AWARENESS_PER_MONITOR_AWARE), which means that each monitor can have different DPI settings and your application must handle that correctly.(2)
If you do not include this manifest, Windows will virtualize the DPI, meaning it will act as if the DPI setting is always at 96 (100%), and then Windows merely scales the bitmaps (blurry). This is a compatibility measure that ensures that applications which do not implement DPI code can still appear bigger.
Then, on Windows 7, you get the scaling factor using the GetDeviceCaps function with LOGPIXELSX and LOGPIXELSY, and dividing the result by 96 (because 96 dpi is "100%").(1) This will give you the DPI setting of the main monitor. GetDeviceCaps has been the way to get this setting since Windows XP. This will also do fine on Windows 10 if and only if you do not declare DPI awareness per monitor.
On Windows 10, if you declare DPI awareness per monitor, GetDeviceCaps will not suffice because it only returns the DPI setting for the main display. But if you declare PerMonitorV2, then you are obliged to implement per-monitor DPI correctly. To do this, you can call GetDpiForWindow, or MonitorFromWindow + GetDpiForMonitor.
Since you want your executable to run on both Windows 7 and Windows 10, you cannot link against GetDpiForWindow and GetDpiForMonitor because those functions do not exist in Windows 7. You will need manually link at runtime using GetProcAddress.
To merge the manifest, you can use the Manifest Tool in Visual Studio (Project Properties -> Manifest Tool). Put the entire manifest XML text from above into a file (e.g. DpiAwareness.manifest), and specify that under Manifest Tool -> Input and Output -> Additional Manifest Files.
As for the "Make text bigger" accessibility setting: It is a relatively new WinRT setting that is meant for UWP apps. You're not really expected to use it in Win32 applications, so it's going awkward in Win32. I can't help you there because I hate all things UWP. UWP can go die in a fire.
(1) I have never seen a DISPLAY device with a non-1:1 aspect ratio though. It is probably only useful for printers. The fact that GetDpiForWindow, which is the most modern of the mentioned functions, only returns one number, suggests that it is probably safe to assume that the DPI in X direction will always be equal to the DPI in Y direction (on DISPLAY devices).
(2) Note that there is also dpiAwareness PerMonitor (without V2). This is more or less a now-obsolete hack that came with Windows 8. Don't bother with it.
TL;DR What is the sane way to automate invokation of VS 2017 vc_redist when called in a chain of several installers?
The Visual C++ Redistributable Installer that MS provides for VS 15.x (VS 2017), namely both (14.15.26706 - VS 15.8.4)):
vc_redist.x86.exe
vc_redist.x64.exe
As part of our full product installation, I have to run several vcredist installers (also older versions) silently.
The problem now is that these installers will refuse to install if a reboot is pending (e.g. "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" - PendingFileRenameOperations).
When calling these installers with vc_redist /q, they will even trigger an immediate system reboot. This can be fixed by calling them with /q /norestart, however:
When calling vc_redist /q /norestart, and if a reboot is pending prior to this installer, it will return MSI exit code 3010 which indicates that a reboot is required.
However, AFAIK, this exit code also indicates, that this very setup requires a reboot to complete.
Actual question
So, I cannot distinguish whether this installer was succesful and just requires a reboot at the very end of my installation sequence (I do install otehr stuff before and after) - or whether the installer actually refused to do anything and I would need to restart the system and start this installer again!
How can I call this vc_redist in a chain of different third party installers and
ideally require just one reboot at the very end
at the very least, determine whether it installed successfully.
Some additional infos, fwiw:
Not sure these helkp with the question, but for completeness sake.
The installer GUI clearly indicates what is going on: (sorry, german Windows)
"No action was taken because a reboot of the system is required."
This is an InnoSetup built installer for our "product suite", that will be used by customers, the installation order goes as follows:
Run MSVC 2005 (VC8) 32 bit vcredist
Run MSVC 2010 (VC10) 32 bit vcredist
Run MSVC 2017 (VC141) 64 bit vcredist
Run MSVC 2017 (VC141) 32 bit vcredist
Run a few other third party dependecy / library installers
Install the actual application files (via InnoSetup)
Reboot (ask) if any installer indicated a required reboot.
As you can see from this sequence, rebooting after each vcredist woud be insane, and luckily it seems only the 2017 redist exhibits this unfortunate behaviour so far.
Of note: My trial runs on my dev machine all started with a reboot already pending at "step 0", and both the VC2005 and VC2010 installer run just fine (as verified through their GUI progress) even if a reboot is pending before hand. It's the VC2017 installers that refuse to do anything if a reboot is pending.
MSU Packages: After decompiling the vc_redist.x64.exe - which is a WiX bundle - using this command:
dark.exe -x Extract vc_redist.x64.exe
I found that the bundle installs: Update for Universal C Runtime in Windows - KB2999226. This component consists of Windows Update files (*.msu - used by Windows Update) and not just MSI files. I would suspect that they could be designed to require a reboot before allowing installation, but I don't have proof.
Suggestion: Run a check to make sure KB2999226 is installed. How to do this? I don't know a Win32 call, but the WiX guys will probably know. Here are some other suggestions.
Windows: How to List All of the Windows and Software Updates Applied to a Computer
Why are “get-hotfix” and “wmic qfe list” in Powershell missing installed updates?
Identifying installed updates on Microsoft products
The actual Windows Update Files are (over time these file names could change as new versions of this installer with the versionless file name - vc_redist.x64.exe - are released):
Windows6.0-KB2999226-x64.msu
Windows6.1-KB2999226-x64.msu
Windows8.1-KB2999226-x64.msu
Windows8-RT-KB2999226-x64.msu
In other words for Vista, Windows 7, Windows 8 et al. Various Server OS's as well. Windows 10 has this component built-in.
Corporate Deployment: In a corporate environment I would deploy these *.msu files via
the distribution mechanism available - whatever it might be - for
example SCCM - before installing the vc_redist.x64.exe package.
This should yield better control of the distribution process as you get error messages straight from the MSUs themselves.
Frankly these are core-SOE components in my opinion. I don't know why Microsoft keep these runtimes out of the main OS installation. They are crucial for most software.
A description of the decompilation approach using the WiX toolkit's dark.exe binary can be found here: How can I compare the content of two (or more) MSI files?
Strictly speaking, error 3010 is a success result. It means that the install has completed but requires a reboot. I'm not aware of anything to indicate that it means the install didn't start at all. The typical "won't install if reboot pending" is a result of using a launch condition based on the MsiSystemRebootPending property. Failures due to this launch condition do not return return a 3010 result - they usually return a 1602 error as a kind of "user cancel" error.
Well, I am facing a strange problem. I have developed a sample MFC ribbon application on my machine - Windows 7 , with Visual Studio 2008. When I copy paste the .exe onto my laptop and run the app , I don't see the ribbon menu (in fact the app has not menu now) .
I have tried looking up the .dll that load in each case(on my work machine and laptop) using process monitor but I am unable to locate what I might be missing. Any help will be greatly appreciated.
Edit 1 -
Ok, So thanks for your responses. Some progress has been made with this issue
I changed my IDE to VS 2010. The ribbon was coded manually and I figured out if I could add it as a resource maybe the problem would be solved. VS 2008 did not have the option of adding a ribbon as a resource.
I installed the VS 2010 Service Pack Redistributable X86/X64 depending on whether the machine is 32 or 64 bit.
I built a new "ribbontest.exe" app from VS 2010 and deployed it on other machines on which I would test my actual app. The ribbon for "ribbontest.exe" loads without any problems.
When I deploy my app and run it, first the old menubar loads for a sec or two, then the ribbon flashes and disappears.
A little history of the app I am referring to -
Initially my application had the menubar view. I followed this article http://www.codeguru.com/cpp/cpp/cpp_mfc/tutorials/article.php/c14929/MFC-Feature-Pack-An-Introduction.htm to accommodate a ribbon.
Any suggestions?
Most likely there's a conflict in the settings 'paths'. In your InitInstance() handler, you've got a statement like this:
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need
// Change the registry key under which our settings are stored
SetRegistryKey(_T("yourappname"));
If you haven't changed that name yet, do it. If you did, open regedit.exe on your target machine and remove the whole key under HKCU\Software\yourappname and then try again.
MFC stores user customizations of Ribbons/Menus/... under that key. But if you changed your app those settings don't necessarily match anymore and you can end up with stuff not showing correctly or not at all.
Make sure you download and install the Visual C++ Redistributable Runtime on your destination machine: http://www.microsoft.com/en-us/download/details.aspx?id=29
Or, something like it. Make sure you have architecture (x86/x64) correct and make sure it matches with the service pack version you compile with.
Joe is right: you need redistributable.
Joe is right: you cannot run 64-bit program on 32-bit machine.
All of the above would be indicated by the system (missing DLL, configuration incorrect, or 64/32 bit discrepancy)
Joe is right: your application must be built for specific set of minimum Windows version and service pack.
In addition to Joe’s post you must run release build not debug build.
If all of those requirements are met and you still have this problem, try linking MFC statically and see if problem persists.
I'm working on the bootstrap application of a new installer for some of our products. So far, I've been relying on two things that I read about somewhere:
Applications whose name contains "setup" or "install" will run elevated by default.
Applications that run elevated will launch other applications in elevated mode.
Recent testing has found that one or both of these statements is false, because one of the applications that I'm launching is a third party installer that requires elevation, and it's failing because of the elevation requirement.
How do I set my application to require elevation? I know it has something to do with the manifest file. As I'm working in Visual Studio 2008, and the manifest file is generated, I'd like to know what to enter into the project's properties and where to make it require elevation.
When I couldn't find application manifest as a new item that could be added to my project, I went into the online help and found this:
configure the VS2008 in Configuration Properties - Linker - Manifest File - UAC Execution Level (requireAdministrator)
That did the trick.
In VS2008: Add new item; application manifest file (app.manifest; the comments in the template file tell you how to demand more access).
You can now specify the manifest in project properties on the Application tab (but you need to uncheck "Enable the Visual Studio hosting process" to debug it).