OpenRCT2/src/openrct2-win/openrct2-win.cpp

59 lines
2.1 KiB
C++
Raw Normal View History

2017-01-04 23:10:16 +01:00
/*****************************************************************************
* Copyright (c) 2014-2024 OpenRCT2 developers
2017-01-04 23:10:16 +01:00
*
* For a complete list of all authors, please refer to contributors.md
* Interested in contributing? Visit https://github.com/OpenRCT2/OpenRCT2
2017-01-04 23:10:16 +01:00
*
* OpenRCT2 is licensed under the GNU General Public License version 3.
2017-01-04 23:10:16 +01:00
*****************************************************************************/
Remove exe / com wrapper around openrct2.dll for Windows (#10727) We get repeated reports of people saying the game is incorrectly reported as a virus. It is becoming more inconvenient for players and even myself, because when we attempt to download a build, it is immediately deleted by scanners (including the default for Windows: Windows Defender). One scanner is not too much of an issue, but the game is flagged by almost half of available scanners as reported by VirusTotal. So why is it being flagged? Windows has a very annoying concept, the subsystem for a binary. The console subsystem allows stdin / stdout as you would expect, just like posix. Unfortunately if a user runs a console subsystem binary from the desktop or explorer, the game will be opened under conhost and thus you get a console showing alongside the game window. This is not a good user experience for most players. To resolve this, you can use the windows subsystem, but this will detach stdin and stdout immediately on launch. There are hacks that can be done in code to allocate a new console but I found this to not work very well with stdin or other terminal emulators. My solution to the problem was to have two binaries: openrct2.exe and openrct2.com. Both are executable but openrct2.exe is windows subsystem, openrct2.com is console subsystem. The desktop shortcut opens openrct2.exe with no console window showing. Typing openrct2 on the command line will execute openrct2.com (as .com has higher PATH precedence than .exe by default) with working stdin and stdout. In order to reduce the size, I have the entire game inside openrct2.dll and then supply two tiny wrapper EXEs that simply route main(...) into the DLL. These wrapper EXEs are the problem, they are very small and do nothing but call into a DLL, this must match virus signatures too closely and their size probably reduces the data available for the scanner to analyse. So as I can not find any other way of achieving my goal of a cli and gui version of OpenRCT2, this changes the build to publish openrct2 as a single executable (rather than a DLL + wrapper EXE), and then duplicate the entire ~10MB exe again and flip the subsystem flag. The installer and zip size won't be affected as this extra size will be completely compressed out, but when unpacked will lead to an extra ~10MB on disc. But I think it is a fair compromise. VirusTotal now reports all artefacts as safe, for now anyway.
2020-02-18 12:35:27 +01:00
// Windows.h needs to be included first
2017-01-04 23:10:16 +01:00
#include <windows.h>
// Enable visual styles
2018-06-22 23:25:16 +02:00
#pragma comment( \
linker, \
"\"/manifestdependency:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
2017-01-04 23:10:16 +01:00
Remove exe / com wrapper around openrct2.dll for Windows (#10727) We get repeated reports of people saying the game is incorrectly reported as a virus. It is becoming more inconvenient for players and even myself, because when we attempt to download a build, it is immediately deleted by scanners (including the default for Windows: Windows Defender). One scanner is not too much of an issue, but the game is flagged by almost half of available scanners as reported by VirusTotal. So why is it being flagged? Windows has a very annoying concept, the subsystem for a binary. The console subsystem allows stdin / stdout as you would expect, just like posix. Unfortunately if a user runs a console subsystem binary from the desktop or explorer, the game will be opened under conhost and thus you get a console showing alongside the game window. This is not a good user experience for most players. To resolve this, you can use the windows subsystem, but this will detach stdin and stdout immediately on launch. There are hacks that can be done in code to allocate a new console but I found this to not work very well with stdin or other terminal emulators. My solution to the problem was to have two binaries: openrct2.exe and openrct2.com. Both are executable but openrct2.exe is windows subsystem, openrct2.com is console subsystem. The desktop shortcut opens openrct2.exe with no console window showing. Typing openrct2 on the command line will execute openrct2.com (as .com has higher PATH precedence than .exe by default) with working stdin and stdout. In order to reduce the size, I have the entire game inside openrct2.dll and then supply two tiny wrapper EXEs that simply route main(...) into the DLL. These wrapper EXEs are the problem, they are very small and do nothing but call into a DLL, this must match virus signatures too closely and their size probably reduces the data available for the scanner to analyse. So as I can not find any other way of achieving my goal of a cli and gui version of OpenRCT2, this changes the build to publish openrct2 as a single executable (rather than a DLL + wrapper EXE), and then duplicate the entire ~10MB exe again and flip the subsystem flag. The installer and zip size won't be affected as this extra size will be completely compressed out, but when unpacked will lead to an extra ~10MB on disc. But I think it is a fair compromise. VirusTotal now reports all artefacts as safe, for now anyway.
2020-02-18 12:35:27 +01:00
// Then the rest
#include <algorithm>
2020-07-10 19:43:49 +02:00
#include <iterator>
Remove exe / com wrapper around openrct2.dll for Windows (#10727) We get repeated reports of people saying the game is incorrectly reported as a virus. It is becoming more inconvenient for players and even myself, because when we attempt to download a build, it is immediately deleted by scanners (including the default for Windows: Windows Defender). One scanner is not too much of an issue, but the game is flagged by almost half of available scanners as reported by VirusTotal. So why is it being flagged? Windows has a very annoying concept, the subsystem for a binary. The console subsystem allows stdin / stdout as you would expect, just like posix. Unfortunately if a user runs a console subsystem binary from the desktop or explorer, the game will be opened under conhost and thus you get a console showing alongside the game window. This is not a good user experience for most players. To resolve this, you can use the windows subsystem, but this will detach stdin and stdout immediately on launch. There are hacks that can be done in code to allocate a new console but I found this to not work very well with stdin or other terminal emulators. My solution to the problem was to have two binaries: openrct2.exe and openrct2.com. Both are executable but openrct2.exe is windows subsystem, openrct2.com is console subsystem. The desktop shortcut opens openrct2.exe with no console window showing. Typing openrct2 on the command line will execute openrct2.com (as .com has higher PATH precedence than .exe by default) with working stdin and stdout. In order to reduce the size, I have the entire game inside openrct2.dll and then supply two tiny wrapper EXEs that simply route main(...) into the DLL. These wrapper EXEs are the problem, they are very small and do nothing but call into a DLL, this must match virus signatures too closely and their size probably reduces the data available for the scanner to analyse. So as I can not find any other way of achieving my goal of a cli and gui version of OpenRCT2, this changes the build to publish openrct2 as a single executable (rather than a DLL + wrapper EXE), and then duplicate the entire ~10MB exe again and flip the subsystem flag. The installer and zip size won't be affected as this extra size will be completely compressed out, but when unpacked will lead to an extra ~10MB on disc. But I think it is a fair compromise. VirusTotal now reports all artefacts as safe, for now anyway.
2020-02-18 12:35:27 +01:00
#include <openrct2-ui/Ui.h>
#include <openrct2/core/String.hpp>
Remove exe / com wrapper around openrct2.dll for Windows (#10727) We get repeated reports of people saying the game is incorrectly reported as a virus. It is becoming more inconvenient for players and even myself, because when we attempt to download a build, it is immediately deleted by scanners (including the default for Windows: Windows Defender). One scanner is not too much of an issue, but the game is flagged by almost half of available scanners as reported by VirusTotal. So why is it being flagged? Windows has a very annoying concept, the subsystem for a binary. The console subsystem allows stdin / stdout as you would expect, just like posix. Unfortunately if a user runs a console subsystem binary from the desktop or explorer, the game will be opened under conhost and thus you get a console showing alongside the game window. This is not a good user experience for most players. To resolve this, you can use the windows subsystem, but this will detach stdin and stdout immediately on launch. There are hacks that can be done in code to allocate a new console but I found this to not work very well with stdin or other terminal emulators. My solution to the problem was to have two binaries: openrct2.exe and openrct2.com. Both are executable but openrct2.exe is windows subsystem, openrct2.com is console subsystem. The desktop shortcut opens openrct2.exe with no console window showing. Typing openrct2 on the command line will execute openrct2.com (as .com has higher PATH precedence than .exe by default) with working stdin and stdout. In order to reduce the size, I have the entire game inside openrct2.dll and then supply two tiny wrapper EXEs that simply route main(...) into the DLL. These wrapper EXEs are the problem, they are very small and do nothing but call into a DLL, this must match virus signatures too closely and their size probably reduces the data available for the scanner to analyse. So as I can not find any other way of achieving my goal of a cli and gui version of OpenRCT2, this changes the build to publish openrct2 as a single executable (rather than a DLL + wrapper EXE), and then duplicate the entire ~10MB exe again and flip the subsystem flag. The installer and zip size won't be affected as this extra size will be completely compressed out, but when unpacked will lead to an extra ~10MB on disc. But I think it is a fair compromise. VirusTotal now reports all artefacts as safe, for now anyway.
2020-02-18 12:35:27 +01:00
#include <stdio.h>
#include <stdlib.h>
#include <string>
#include <vector>
Remove exe / com wrapper around openrct2.dll for Windows (#10727) We get repeated reports of people saying the game is incorrectly reported as a virus. It is becoming more inconvenient for players and even myself, because when we attempt to download a build, it is immediately deleted by scanners (including the default for Windows: Windows Defender). One scanner is not too much of an issue, but the game is flagged by almost half of available scanners as reported by VirusTotal. So why is it being flagged? Windows has a very annoying concept, the subsystem for a binary. The console subsystem allows stdin / stdout as you would expect, just like posix. Unfortunately if a user runs a console subsystem binary from the desktop or explorer, the game will be opened under conhost and thus you get a console showing alongside the game window. This is not a good user experience for most players. To resolve this, you can use the windows subsystem, but this will detach stdin and stdout immediately on launch. There are hacks that can be done in code to allocate a new console but I found this to not work very well with stdin or other terminal emulators. My solution to the problem was to have two binaries: openrct2.exe and openrct2.com. Both are executable but openrct2.exe is windows subsystem, openrct2.com is console subsystem. The desktop shortcut opens openrct2.exe with no console window showing. Typing openrct2 on the command line will execute openrct2.com (as .com has higher PATH precedence than .exe by default) with working stdin and stdout. In order to reduce the size, I have the entire game inside openrct2.dll and then supply two tiny wrapper EXEs that simply route main(...) into the DLL. These wrapper EXEs are the problem, they are very small and do nothing but call into a DLL, this must match virus signatures too closely and their size probably reduces the data available for the scanner to analyse. So as I can not find any other way of achieving my goal of a cli and gui version of OpenRCT2, this changes the build to publish openrct2 as a single executable (rather than a DLL + wrapper EXE), and then duplicate the entire ~10MB exe again and flip the subsystem flag. The installer and zip size won't be affected as this extra size will be completely compressed out, but when unpacked will lead to an extra ~10MB on disc. But I think it is a fair compromise. VirusTotal now reports all artefacts as safe, for now anyway.
2020-02-18 12:35:27 +01:00
static std::vector<std::string> GetCommandLineArgs(int argc, wchar_t** argvW);
2017-01-04 23:10:16 +01:00
/**
* Windows entry point to OpenRCT2 with a console window using a traditional C main function.
*/
2018-06-22 23:25:16 +02:00
int wmain(int argc, wchar_t** argvW, [[maybe_unused]] wchar_t* envp)
2017-01-04 23:10:16 +01:00
{
auto argvStrings = GetCommandLineArgs(argc, argvW);
Remove exe / com wrapper around openrct2.dll for Windows (#10727) We get repeated reports of people saying the game is incorrectly reported as a virus. It is becoming more inconvenient for players and even myself, because when we attempt to download a build, it is immediately deleted by scanners (including the default for Windows: Windows Defender). One scanner is not too much of an issue, but the game is flagged by almost half of available scanners as reported by VirusTotal. So why is it being flagged? Windows has a very annoying concept, the subsystem for a binary. The console subsystem allows stdin / stdout as you would expect, just like posix. Unfortunately if a user runs a console subsystem binary from the desktop or explorer, the game will be opened under conhost and thus you get a console showing alongside the game window. This is not a good user experience for most players. To resolve this, you can use the windows subsystem, but this will detach stdin and stdout immediately on launch. There are hacks that can be done in code to allocate a new console but I found this to not work very well with stdin or other terminal emulators. My solution to the problem was to have two binaries: openrct2.exe and openrct2.com. Both are executable but openrct2.exe is windows subsystem, openrct2.com is console subsystem. The desktop shortcut opens openrct2.exe with no console window showing. Typing openrct2 on the command line will execute openrct2.com (as .com has higher PATH precedence than .exe by default) with working stdin and stdout. In order to reduce the size, I have the entire game inside openrct2.dll and then supply two tiny wrapper EXEs that simply route main(...) into the DLL. These wrapper EXEs are the problem, they are very small and do nothing but call into a DLL, this must match virus signatures too closely and their size probably reduces the data available for the scanner to analyse. So as I can not find any other way of achieving my goal of a cli and gui version of OpenRCT2, this changes the build to publish openrct2 as a single executable (rather than a DLL + wrapper EXE), and then duplicate the entire ~10MB exe again and flip the subsystem flag. The installer and zip size won't be affected as this extra size will be completely compressed out, but when unpacked will lead to an extra ~10MB on disc. But I think it is a fair compromise. VirusTotal now reports all artefacts as safe, for now anyway.
2020-02-18 12:35:27 +01:00
2022-05-10 12:55:39 +02:00
SetConsoleCP(OpenRCT2::CodePage::UTF8);
SetConsoleOutputCP(OpenRCT2::CodePage::UTF8);
Remove exe / com wrapper around openrct2.dll for Windows (#10727) We get repeated reports of people saying the game is incorrectly reported as a virus. It is becoming more inconvenient for players and even myself, because when we attempt to download a build, it is immediately deleted by scanners (including the default for Windows: Windows Defender). One scanner is not too much of an issue, but the game is flagged by almost half of available scanners as reported by VirusTotal. So why is it being flagged? Windows has a very annoying concept, the subsystem for a binary. The console subsystem allows stdin / stdout as you would expect, just like posix. Unfortunately if a user runs a console subsystem binary from the desktop or explorer, the game will be opened under conhost and thus you get a console showing alongside the game window. This is not a good user experience for most players. To resolve this, you can use the windows subsystem, but this will detach stdin and stdout immediately on launch. There are hacks that can be done in code to allocate a new console but I found this to not work very well with stdin or other terminal emulators. My solution to the problem was to have two binaries: openrct2.exe and openrct2.com. Both are executable but openrct2.exe is windows subsystem, openrct2.com is console subsystem. The desktop shortcut opens openrct2.exe with no console window showing. Typing openrct2 on the command line will execute openrct2.com (as .com has higher PATH precedence than .exe by default) with working stdin and stdout. In order to reduce the size, I have the entire game inside openrct2.dll and then supply two tiny wrapper EXEs that simply route main(...) into the DLL. These wrapper EXEs are the problem, they are very small and do nothing but call into a DLL, this must match virus signatures too closely and their size probably reduces the data available for the scanner to analyse. So as I can not find any other way of achieving my goal of a cli and gui version of OpenRCT2, this changes the build to publish openrct2 as a single executable (rather than a DLL + wrapper EXE), and then duplicate the entire ~10MB exe again and flip the subsystem flag. The installer and zip size won't be affected as this extra size will be completely compressed out, but when unpacked will lead to an extra ~10MB on disc. But I think it is a fair compromise. VirusTotal now reports all artefacts as safe, for now anyway.
2020-02-18 12:35:27 +01:00
std::vector<const char*> argv;
std::transform(
argvStrings.begin(), argvStrings.end(), std::back_inserter(argv), [](const auto& string) { return string.c_str(); });
// Ensure that argv[argc] == nullptr, as mandated by the standard
argv.push_back(nullptr);
return NormalisedMain(argc, argv.data());
Remove exe / com wrapper around openrct2.dll for Windows (#10727) We get repeated reports of people saying the game is incorrectly reported as a virus. It is becoming more inconvenient for players and even myself, because when we attempt to download a build, it is immediately deleted by scanners (including the default for Windows: Windows Defender). One scanner is not too much of an issue, but the game is flagged by almost half of available scanners as reported by VirusTotal. So why is it being flagged? Windows has a very annoying concept, the subsystem for a binary. The console subsystem allows stdin / stdout as you would expect, just like posix. Unfortunately if a user runs a console subsystem binary from the desktop or explorer, the game will be opened under conhost and thus you get a console showing alongside the game window. This is not a good user experience for most players. To resolve this, you can use the windows subsystem, but this will detach stdin and stdout immediately on launch. There are hacks that can be done in code to allocate a new console but I found this to not work very well with stdin or other terminal emulators. My solution to the problem was to have two binaries: openrct2.exe and openrct2.com. Both are executable but openrct2.exe is windows subsystem, openrct2.com is console subsystem. The desktop shortcut opens openrct2.exe with no console window showing. Typing openrct2 on the command line will execute openrct2.com (as .com has higher PATH precedence than .exe by default) with working stdin and stdout. In order to reduce the size, I have the entire game inside openrct2.dll and then supply two tiny wrapper EXEs that simply route main(...) into the DLL. These wrapper EXEs are the problem, they are very small and do nothing but call into a DLL, this must match virus signatures too closely and their size probably reduces the data available for the scanner to analyse. So as I can not find any other way of achieving my goal of a cli and gui version of OpenRCT2, this changes the build to publish openrct2 as a single executable (rather than a DLL + wrapper EXE), and then duplicate the entire ~10MB exe again and flip the subsystem flag. The installer and zip size won't be affected as this extra size will be completely compressed out, but when unpacked will lead to an extra ~10MB on disc. But I think it is a fair compromise. VirusTotal now reports all artefacts as safe, for now anyway.
2020-02-18 12:35:27 +01:00
}
static std::vector<std::string> GetCommandLineArgs(int argc, wchar_t** argvW)
Remove exe / com wrapper around openrct2.dll for Windows (#10727) We get repeated reports of people saying the game is incorrectly reported as a virus. It is becoming more inconvenient for players and even myself, because when we attempt to download a build, it is immediately deleted by scanners (including the default for Windows: Windows Defender). One scanner is not too much of an issue, but the game is flagged by almost half of available scanners as reported by VirusTotal. So why is it being flagged? Windows has a very annoying concept, the subsystem for a binary. The console subsystem allows stdin / stdout as you would expect, just like posix. Unfortunately if a user runs a console subsystem binary from the desktop or explorer, the game will be opened under conhost and thus you get a console showing alongside the game window. This is not a good user experience for most players. To resolve this, you can use the windows subsystem, but this will detach stdin and stdout immediately on launch. There are hacks that can be done in code to allocate a new console but I found this to not work very well with stdin or other terminal emulators. My solution to the problem was to have two binaries: openrct2.exe and openrct2.com. Both are executable but openrct2.exe is windows subsystem, openrct2.com is console subsystem. The desktop shortcut opens openrct2.exe with no console window showing. Typing openrct2 on the command line will execute openrct2.com (as .com has higher PATH precedence than .exe by default) with working stdin and stdout. In order to reduce the size, I have the entire game inside openrct2.dll and then supply two tiny wrapper EXEs that simply route main(...) into the DLL. These wrapper EXEs are the problem, they are very small and do nothing but call into a DLL, this must match virus signatures too closely and their size probably reduces the data available for the scanner to analyse. So as I can not find any other way of achieving my goal of a cli and gui version of OpenRCT2, this changes the build to publish openrct2 as a single executable (rather than a DLL + wrapper EXE), and then duplicate the entire ~10MB exe again and flip the subsystem flag. The installer and zip size won't be affected as this extra size will be completely compressed out, but when unpacked will lead to an extra ~10MB on disc. But I think it is a fair compromise. VirusTotal now reports all artefacts as safe, for now anyway.
2020-02-18 12:35:27 +01:00
{
// Allocate UTF-8 strings
std::vector<std::string> argv;
Remove exe / com wrapper around openrct2.dll for Windows (#10727) We get repeated reports of people saying the game is incorrectly reported as a virus. It is becoming more inconvenient for players and even myself, because when we attempt to download a build, it is immediately deleted by scanners (including the default for Windows: Windows Defender). One scanner is not too much of an issue, but the game is flagged by almost half of available scanners as reported by VirusTotal. So why is it being flagged? Windows has a very annoying concept, the subsystem for a binary. The console subsystem allows stdin / stdout as you would expect, just like posix. Unfortunately if a user runs a console subsystem binary from the desktop or explorer, the game will be opened under conhost and thus you get a console showing alongside the game window. This is not a good user experience for most players. To resolve this, you can use the windows subsystem, but this will detach stdin and stdout immediately on launch. There are hacks that can be done in code to allocate a new console but I found this to not work very well with stdin or other terminal emulators. My solution to the problem was to have two binaries: openrct2.exe and openrct2.com. Both are executable but openrct2.exe is windows subsystem, openrct2.com is console subsystem. The desktop shortcut opens openrct2.exe with no console window showing. Typing openrct2 on the command line will execute openrct2.com (as .com has higher PATH precedence than .exe by default) with working stdin and stdout. In order to reduce the size, I have the entire game inside openrct2.dll and then supply two tiny wrapper EXEs that simply route main(...) into the DLL. These wrapper EXEs are the problem, they are very small and do nothing but call into a DLL, this must match virus signatures too closely and their size probably reduces the data available for the scanner to analyse. So as I can not find any other way of achieving my goal of a cli and gui version of OpenRCT2, this changes the build to publish openrct2 as a single executable (rather than a DLL + wrapper EXE), and then duplicate the entire ~10MB exe again and flip the subsystem flag. The installer and zip size won't be affected as this extra size will be completely compressed out, but when unpacked will lead to an extra ~10MB on disc. But I think it is a fair compromise. VirusTotal now reports all artefacts as safe, for now anyway.
2020-02-18 12:35:27 +01:00
for (int i = 0; i < argc; i++)
{
argv.push_back(String::ToUtf8(argvW[i]));
Remove exe / com wrapper around openrct2.dll for Windows (#10727) We get repeated reports of people saying the game is incorrectly reported as a virus. It is becoming more inconvenient for players and even myself, because when we attempt to download a build, it is immediately deleted by scanners (including the default for Windows: Windows Defender). One scanner is not too much of an issue, but the game is flagged by almost half of available scanners as reported by VirusTotal. So why is it being flagged? Windows has a very annoying concept, the subsystem for a binary. The console subsystem allows stdin / stdout as you would expect, just like posix. Unfortunately if a user runs a console subsystem binary from the desktop or explorer, the game will be opened under conhost and thus you get a console showing alongside the game window. This is not a good user experience for most players. To resolve this, you can use the windows subsystem, but this will detach stdin and stdout immediately on launch. There are hacks that can be done in code to allocate a new console but I found this to not work very well with stdin or other terminal emulators. My solution to the problem was to have two binaries: openrct2.exe and openrct2.com. Both are executable but openrct2.exe is windows subsystem, openrct2.com is console subsystem. The desktop shortcut opens openrct2.exe with no console window showing. Typing openrct2 on the command line will execute openrct2.com (as .com has higher PATH precedence than .exe by default) with working stdin and stdout. In order to reduce the size, I have the entire game inside openrct2.dll and then supply two tiny wrapper EXEs that simply route main(...) into the DLL. These wrapper EXEs are the problem, they are very small and do nothing but call into a DLL, this must match virus signatures too closely and their size probably reduces the data available for the scanner to analyse. So as I can not find any other way of achieving my goal of a cli and gui version of OpenRCT2, this changes the build to publish openrct2 as a single executable (rather than a DLL + wrapper EXE), and then duplicate the entire ~10MB exe again and flip the subsystem flag. The installer and zip size won't be affected as this extra size will be completely compressed out, but when unpacked will lead to an extra ~10MB on disc. But I think it is a fair compromise. VirusTotal now reports all artefacts as safe, for now anyway.
2020-02-18 12:35:27 +01:00
}
return argv;
2017-01-04 23:10:16 +01:00
}