Monogame Exit() Obsolete for Desktop Program - exit

I'm in the process of upgrading my Monogame project to the newest version (3.5).
I've systematically gotten rid of all the insane error messages (so far) except one:
Error 9 'Microsoft.Xna.Framework.Game.Exit()' is obsolete: 'This platform's policy does not allow programmatically closing.'
I'm just calling a simple "Exit()" when the user clicks the corresponding sprite in the UI.
case click.exit:
Exit();
break;
Is there a new way of telling the game I want to quit and return to Windows?

This is not supported on certain platforms (Windows Phone, Windows Store, iOS), because it would cause rejection in the app certification. On these platforms, apps must be closed by the user using OS interactions (task switcher, Alt-F4...). For example, this Windows 8 document was cited in the MonoGame change. On other platforms, Exit() is supported.

Fixed it.
I created a new, blank project and used it as a reference to find the correct assembly to use in the existing project.
For me, it was under:
C:\Program Files (x86)\MonoGame\v3.0\Assemblies\Windows\MonoGame.Framework.dll
This one wasn't showing up in the reference manager for some reason. I had to manually browse to it. No more errors about Exit().

Related

File association issue when double-clicking (Windows message popping)

When we double-click on a file (extension .AQ9) from our own application (developped in MFC C++), we receive this message:
Windows cannot find "name of the file.AQ9". Make sure you typed the name correctly, and then try again.
But the file opens anyway without problem (we just close the message and continue to work). We maintain this application for quite a while now (several years, like 15 years) and it's just recently that we have this message only in Windows XP. I don't know what changed exactly on our side since we don't know exactly when it started and the application has more than 2 millions line of code. Also, we create the setup using Install Shield, so maybe it's related to this (but we use this for the latest 10 years without any problem)
The file association seems fine, since it opens the file anyway. If the application is already opened and that we double-click on the file, no message is shown.
My guess is that the slight delay of the splash screen may scare Windows XP in thinking that the file cannot be opened but it's like less than a second... If it's the case, is there a way to specify somewhere a "timeout" before this message is shown? At least for our application.
I've also check in the windows event log but there is nothing I can see about this error.
This question looks like this one but he still gets the message when the application is already launched, which is not my case.
I had a similar problem this year, with the same symptoms, and I was able to get rid of the message by removing the "ddeexec" registry entry associated with the sofware (in your case : HKEY_LOCAL_MACHINE\SOFTWARE\Classes\your software.Document\Shell\Open\ddeexec)
I'm not sure why it worked well before. I suspect a windows update to be the culprit :P

Windows Store C++ apps cannot create files using fopen() under Windows 8.1

We have several Windows 8 Store C++ apps that need to maintain configuration and data files.
Files are written in subfolders of Windows::Storage::ApplicationData::Current->LocalFolder. Example:
C:\Users\<username>\AppData\Local\Packages\<packagename>\LocalState\SubFolder1\SubFolder2\data.txt
In Windows 8.1 we have received a few reports from users that say state isn't remembered between app invocations. Upon closer inspection the files are not created (the subfolders are indeed created, but there are no files inside them)
Notes:
Subfolders are created using CreateDirectory(), files are created using fopen()
Files are created/opened using absolute paths
This always worked under Windows 8.0 and the code has not been changed since. In fact, one of our user reports stated that the app saved files fine under Windows 8.0, but stopped saving after the user upgraded to Windows 8.1.
We have not been able to replicate the issue locally using Windows 8.1. We're not sure how common this failure is, but we estimate that most users are unaffected. Affected users do not appear to have any special hardware/software configuration.
If a user is affected, then files are consistently never saved, even after retrying or uninstalling and re-installing the app (i.e., it's not a case of intermittent failure)
It's hard to get error information given (i) the rarity of the issue (ii) the fact that the logs that would reveal this are by definition not saved, and (iii) the apps don't require internet connectivity so there is no alternative communication channel.
Can anyone think of any reason why this might fail under Windows 8.1?
Are there non-ascii characters in path to appdata? CreateDirectory has unicode version, but fopen takes const char* strings as argument.
If I were you, I'd try to abstract away from OS-specific calls using something like boost or Qt. That should work, because Qt uses unicode string for opening files and Boost should have something similar (unsure about this one).
Also on windows compiler _wfopen may be present. It is the same as fopen, but takes wchar_t strings as argument. It should work for you, but you'll need a few ifdefs here and there.
You could also try setting current directory with function that supports unicode and then calling fopen, but I wouldn't call it a "clean" solution.
Anyway, when you run into problem that is related to system calls, then on machine with a problem you can monitor calls using something like process monitor. You could instruct user with a problem to do that and send you a log.
Why don't you use the Windows.Storage classes to work with filesystem? WinRT is recommended way to work with IO not legacy C API. I believe it is more robust approach and you could get more info about the cause from WinRT exception rather than from an unknown failure of old API.

My programs are blocked by Avast Antivirus

I'm an amateur programmer, and I'm getting desperate and mad because of a big issue: most of my programs are blocked by Avast Antivirus, while some aren't, and I don't understand why.
The more I try to investigate, the less I understand what the problem could be.
I'm requesting your help to find a solution so that my programs are no longer blocked, or, as a default, at least some strong clues that would explain why it might be the case.
There are already many topics about that on the web. However, most of them give only superficial answers: they just explain how antivirus software works with signatures and detection heuristics, or state that you just have to add the offending application in the white list without asking any other question. While it is certainly correct, it's not acceptable answers in my sense, because I'm still left with my own programs that refuse to work without any concrete idea to start investigating.
First of all, the only antivirus software that blocks my programs is Avast 7.x. No other antivirus software see any inconvenient to run my software. Secondly, I haven't installed Avast myself; it is installed on a friend's machine.
I have Windows 7, and he has Windows XP. I'm completely sure that the problem is avast only: when it is temporarily disabled, or if the program is added to its white list, everything works nicely as expected.
Three different programs are in trouble:
A text editor, with the goal to replace Windows Notepad while keeping simple, efficient and customizable
A small amateur audio player very simple to use
The client program of an online game platform, currently having more than 1000 users
The first one is open source, and I can give a link to the executable and the source code if needed. The two others are closed source but free to use, I can give a link to the executable of the current version only.
The only obvious common things between these three programs are me as a developer, my Windows 7 machine that compiled them, the compiler family which is MinGW/GCC, and they are all Win32 GUI applications without any framework (no MFC, no WPF, no Qt, wxWidgets or whatever; just pure Win32/C GUI applications).
Here are my observations and thoughts so far:
Versions 1.1, 1.2.1 and 1.3 of my text editor are blocked. They are in C, not C++, have been compiled with GCC 3.4.5 in Unicode mode, and are distributed in portable ZIP files (by portable, I simply mean no installer and no installation needed)
Version 1.4.1 of the same text editor isn't blocked. It has been compiled with GCC 4.7.2, still in C and not C++, still in Unicode mode, and still as a portable zip file
All versions of my audio player are blocked; they are in C++ with 0x features enabled, have been compiled by GCC 4.7.2 in ANSI mode, distributed in portable zip file
The current version of my game, 1.7.2, isn't blocked. it is in C, has been compiled with GCC 3.4.5 in ANSI mode, and is distributed as an Inno Setup 5 installer.
The new version of my game, 2.0.0, which is currently a private beta, is blocked. It is in C++ with 0x features enabled, has been compiled with GCC 4.7.2 in Unicode mode. I share it with my private beta-testing team as zip files within a private Dropbox folder
The problem is caused by Avast 7.x auto-sandbox. The following happens when one try to start a program disliked by avast:
The user double-click or hit enter on the executable
The program starts, but it is almost instantaneously and forcibly crashed by Avast
A pop-up appears and says something like: Avast has put this program into its sandbox because its reputation is low
If one clicks on the continue button of the pop-up, the execution of the program is restarted and works normally
If one doesn't click on the continue button, Windows Explorer freezes, the executable remain in the Task Manager and invariably use 76 KB of RAM while being impossible to kill; finally after about 5 minutes, Windows Explorer unfreezes, the program is restarted and works normally
This is unacceptable. Newbie users of my program, especially the game, don't know how antivirus software works; don't know how to put it into the white list and why it will unblock it; don't know how to change settings of their antivirus software; if they see the pop-up, won't understand it and will end up being afraid or disappointed because they can't play without knowing why; and if they don't see the pop-up, I can't expect them to wait 5 minutes with a half-freezing computer. each time they want to play.
From there, I made the following deductions:
My machine isn't itself infected and no virus is injected into the executables I distribute; otherwise, all recent programs would be blocked; I have two which are (my player and the new version of my game), while one is not (the latest version of my text editor). The 1.7.2 of the game has been compiled in march 2012, while the 1.4.1 of the text editor is from October 2012.
The newest version of GCC 4.7.2 is not in cause, by the same reasoning; same for ANSI vs Unicode compiling.
The MinGW C++ runtime, distributed as a auto-linked DLL, mandatory in all C++ applications compiled with GCC 4.7.2, is probably not the cause, because many well-known programs use it; and my text editor is blocked and is in C, and thus don't use it.
My audio player and my game have the audio library in common; this later is not the cause, because the version 1.7.2 of my game works and the newest private beta not. And of course, that audio library is also used in many other known or less known applications that aren't blocked.
Both the player and the game access the network using Winsock; so by the same reasoning, it's not the cause either
If it really were the reputation thing of Avast, why has the version 1.4.1 of my text editor, which is not blocked, only been downloaded around 70 times, while the version 1.3 which is blocked has been downloaded more than 300 times? It looks completely illogical. Are 70 users sufficient to claim something about reputation? Is it more with 300 users? I really don't think so... probably a critical mass of a dozens thousands users is necessary.
Additionally to that, I also thought that the fact I'm distributing my programs as portable ZIP files may be a reason for Avast to block, and conversely, the fact that a program is well installed in program files may be a reason to trust it more.
So I made a simple experience: I compiled a new Inno Setup 5 installer for the beta 2.0.0 of my game, as well as one for the version 1.3 of my text editor, and discover that the installers themselves were blocked!
I made another experience with my friend, where I tried to find exactly the place where the programs crash, based on using MessageBeep (MessageBox is also blocked!). I didn't noticed anything problematic. The game is blocked when SetDlgItemText is called for the first time in the login dialog box, but if I remove all SetDlgItemText it is blocked further down. In the text editor, it is blocked while populating the menu bar...
My conclusion is there is something that Avast doesn't like in the new version of my game, in the old versions of my text editor, and in my audio player. Something that is absent in the newest version of my text editor. What could it be? Do you have any clue? Do you have only an idea on how I could proceed to find what it is so that I can hope to fix it? Is there only a way to analyse such a problem, or is the whole world screwed by Avast?
Note that I'm a single person and not a company, all those programs are free to use, I have not pay any IDE to develop them, and I'm not paid by the users when they use them, so I assume that a certificate is probably not affordable at all. Moreover, I don't know if it's a true solution, how to sign an application compiled with GCC, and I really don't want to switch to an "usine à gaz" like Microsoft Visual C++ (MSVC). I would prefer strongly forget that option if there is any other solution, even a very dirty one.
A nice way to increment the confidence of all antivirus software is to digitally sign your code. Thawte has the cheapest well-recognized certificates starting below 100 € / year.
Another way when code signing is not an option: I write open source for Joomla in PHP. After I received the first indications that Avast marked my file as a (false) positive, I contacted them and they whitelisted my file within hours.
In order to make my life easier, I am creating a separate file with the supposedly "dangerous" function, so that future changes to the program won't require to resubmit it for whitelisting.
Possibly the speed in their response was helped by the fact that reading a short PHP file is faster than reverse engineering compiled code; nonetheless they were kind, quick and effective.
Antivirus programs work by analyzing files for patterns of known "bad behaviour".
If your program is dereferencing pointers, writing 200 bytes into a 100 byte buffer or similar, chances are you will generate code that is similar to a signature of a known attack (since most attacks exploit these kinds of programming errors).
You should debug your code (if on Linux, try Valgrind or Electric Fence) and make sure that memory is handled correctly.
You can be interested in the article The Case of Evil WinMain.
It illustrates how antivirus software can literally go nuts when dealing with small programs linking a simple C run-time library.
The only thing you can do is signal the problem to the antivirus makers and hope in a fair behavior from them.
All right, I figured it out. Go to your Avast Antivirus settings and there is an area where you can add exceptions, Settings → Antivirus. Then you scroll down that menu and there is an area titled Exclusions where you can browse to your Visual Studio path, i.e., C: → john → Documents → VisualStudio2010 → projects.
Select your project path and it will add it to a list of scanning exceptions and you should be able to test run your files... it worked well for me. I also disabled deep scan in the same menu due to a suggestion from another member.
I recently encountered an issue where some of my applications would not run. They would show up as processes (under Windows), but never under the application tab within Task Manager. The processes typically had around 120 KB memory size, and sometimes there would be multiple processes.
The culprit is Avast DeepScreen. From Avast:
The DeepScreen Technology allows Avast to make real-time decisions when an unknown file is executed.
In my case, MATLAB was blocked, as were some other applications.
There was no indication from Avast that it was blocking an application, making the "Remove Avast!" comment above quite appropriate.
Avast has a feature called cybercapture/deep scan.
This is what's causing your troubles.
It doesn't even bother with the heuristics.
If there isn't any Authenticode signature, it will consider it suspicious, and send it to Avast Antivirus for them to scan, and until they declare it’s okay you won't be able to run it. Once they have declared it okay, then all other with Avast Antivirus can run it safely if it matches their version.
Most of the antivirus programs give options to enable exceptions.
Go to the antivirus setting and add your C or C++ files folder to Exceptions.
Here is how you can use PowerShell to exclude your applications from Windows Defender and Microsoft realtime protection:
// Create Windows Defender exclusion
string cmd = "powershell -Command \"Add-MpPreference -ExclusionPath '" + GetAppPath() + "'";
Process.Start(new ProcessStartInfo() { FileName = "cmd.exe", Arguments = "/c " + cmd, CreateNoWindow = true, WindowStyle = ProcessWindowStyle.Hidden }).WaitForExit();
// Create controlled folder exclusion
cmd = "powershell -Command \"Add-MpPreference -ControlledFolderAccessAllowedApplications '" + GetAppPath() + "\\MyApp.exe" + "'";
Process.Start(new ProcessStartInfo() { FileName = "cmd.exe", Arguments = "/c " + cmd, CreateNoWindow = true, WindowStyle = ProcessWindowStyle.Hidden }).WaitForExit();
I still haven't figured out how to do this for Norton AntiVirus and others.
Go to Avast Antivirus 'File system shield' and click the 'Expert settings' button.
Then find and click the 'Exclusions' option from the menu on the left side. Add your project folder in the file exclusion list. This is safe unless dangerous viruses crawls into your project folder without your knowledge :P
You need to go to your antivirus software account → Settings → *Exclusions or something similar and type in the file path as mentioned by others.
I did it with Avast Antivirus. The first time around it didn't work, so I uninstalled and installed. Then I went to exclusions and it works now.

Collect crash .dmp and .hdmp files after a crash of C++ service and a user-mode app

I'm coding in C++/MFC using WinAPIs. My software consists of a local service and a user-mode app that provides user interface for a logged in Windows user. I'm looking for a way to collect .dmp and .hdmp files in case of crash in either of those modules. I know that WER supposedly collects them and submits them to Microsoft. Is there a way to collect those files and keep them somewhere on the hard drive?
PS. I need this to work under Windows XP SP3, Vista, 7, 8.
Windows 2000 and XP already save crash dumps using DrWatson. Running drwtsn32.exe allows you to get/configure the path to the log and the dump files.
Windows Vista+ only uses WER, which doesn't save a dump by default, but you can enable creation of user mode dumps.
I set the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\DumpType value to 2 to save full dumps which, by default are stored in %LOCALAPPDATA%\CrashDumps (C:\Users\dee.earley\AppData\Local\CrashDumps).
Installing a debugger like WinDebug will also allow you to catch exceptions from user mode apps and the service as they occur.
Microsoft's DebugDiag tool is quite useful for monitoring processes and spitting out dump files on exceptions and crashes.
http://www.microsoft.com/en-us/download/details.aspx?id=26798
I've used this in multiple customer environments to track down problems that I could not reproduce in my own environment.
If you are looking a way for handling crash on customers side the best solution is using google-breakpad library. In your case exception handler will write dump files on the disk.

How can I disable the Program Compatibility Assistant for my program in C++/Win32?

When my application exits, the Windows "Program Compatibility Assistant" appears. I want to not have that window appear when my application terminates.
This is the solution by my problem http://msdn.microsoft.com/en-us/library/dd371711(v=vs.85).aspx
I added custom manifest.
If you're seeing this dialog, one of two things can be happening:
Your program was detected as an installer, and Windows is offering to elevate the installer for you. There's little you can do about this, because this elevation check is heuristically determined by the filename. If your program contains "setup", "instal" (yes, a single l), or a few others in it's filename, the dialog will appear, and there's nothing you can do about it.
EDIT: Apparently there might be a way around this... see comments.
Alternately, you could be calling some API that is deprecated for the current version of Windows, or calling some API incorrectly, triggering compatibility heuristics. If this is the case, you just have to find the place in your program which is triggering the heuristic. You can use the Application Compatibility Toolkit (ACT) to determine what's triggering the dialog, IIRC.
There's no way to just "disable" this dialog -- you have to fix what's triggering it in the first place to make it go away.