Windows OS support improvements in Xemu

[lgblgblgb]

Since I don't use (and never used) Windows, my experience and knowledge is rather limited on Windows OS. Most of my current knowledge is because my will to support Windows users that they can use Xemu, thus some intensive searching/reading of various MS knowledge base (KB) articles, experimenting, and having a Windows 10 VM in VirtualBox to try things.

I would be grateful if experienced Windows users and especially programmers/developers can comment my writings here, or even correct me, if I am wrong.

Also have a look on: #385

Running as Administrator

As a main security rule, nobody even should run anything but important admin tools (which can't work without extra privileges) as Administrator (Windows) or root (UNIX systems). For sure, Xemu does not contain any malicious code by will, but it's also not designed/audited not to contain some potentially exploitable security risks. Thus for sure, as the general rule says, Xemu shouldn't ever run with elevated privileges, and it also does not require it.

Xemu has check to refuse work on UNIX-like systems, if it is tired to be run as root. However nothing similar for Windows. I experimented some code to check this, and I can put into Xemu. However I am not sure about the impact of this. Is it typical to have Windows users running their whole system as Administrator all the time? So if I put this code into Xemu, it would render Xemu unusable for them. It's not an issue on UNIX-like systems, at least, it's not common to have users running GUI as root but I have no idea about Windows.

The check is about trying to tell if Xemu runs as administrator, regardless if it's because user used the "Run as administrator" functionality as a user, or being an Administrator already, it does not matter at all (the only important part, that running Xemu with admin privileges is a danger).

As @deathybrs commented already: maybe I should not worry as much for the users' safety. However: The only reason I worry for others' safety, that Windows systems in general alarms users that this is an unknown exe, not signed (sure as a hobby developer, producing totally free software, I have no way to sign these executables), "are you sure to run it" and also sometimes some false alarms on virus/trojans in Xemu. I have been already confronted with very angry people stating that Xemu is a scam to put trojan into their system as their virus protection warned Xemu to be that. You see, since the generic suspect here, I would like to be careful then Xemu won't be the point in a Windows system which is really helped their system being exploited then ... Sure these claims above (trojan etc) are false, but can rightfully rises eyebrows of users already (when seeing windows warnings on unknown/unsigned exe, maybe virtus protection alerts etc) thus better to be extra careful at this point.

The code used (proposal) to tell if running with admin privileges:

static inline BOOL is_running_as_win_admin ( void )
{
        BOOL ret = FALSE;
        HANDLE htoken = NULL;
        if (OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &htoken)) {
            TOKEN_ELEVATION elevation;
            DWORD cbsize = sizeof(TOKEN_ELEVATION);
            if (GetTokenInformation(htoken, TokenElevation, &elevation, sizeof elevation, &cbsize))
                    ret = elevation.TokenIsElevated;
        }
        if (htoken)
            CloseHandle(htoken);
        if (ret)
            DEBUGPRINT("WINDOWS: warning, running as administrator!" NL);
        return ret;
}

Please share your opinion on this with me! Thanks!

My Windows 10 VM and update problems

Well, not so much Xemu related directly to be honest ... So feel free to skip this section, which is kind of selfish with my own problem :)

However this is my only way to develop for Windows, using a VM. Since I am not an experienced Windows user and especially not an admin, I am kinda stuck though, since my (activated) Windows 10 VM could not be updated since a while. I get the following error:

I've tried several things, suggested by various sources, including:

• Using the update troubleshooter, it found something to be fixed (no reports after repeated run then) but the problem is still there
• I've tried everything from here https://techloris.com/windows-update-error-0x8007000d/

But nothing helps. And no, I don't want to reinstall Windows! It's like being a parent and having some problem with the child, it's not the solution to "let's make another one" :) Problems should be found and fixed at the root cause. However my limited knowledge on Windows is really a barrier here ....

If anyone has any suggestion, please tell me! Thanks!

"International" (UTF-8) file name capable filesystem functions in Windows

Windows seriously lagged behind virtually any OSes that it could not support non-US characters in file names in any filesystem related functions, unless someone used another set of those functions (oh my god!) with wchar types everywhere. Since Xemu is cross platform and should run on UNIX-like OSes (including MacOS, Linux) and Windows as well, I couldn't put easily too much Windows specific code into it, or it become very complicated and cumbersome to maintain because of platform-dependent multiple versions of the same code.

So Xemu till now had serious issues in situations when a Windows user has username with "special character" in it, or want to open any files anywhere where the path of filename contains such a character. Which is kind of lame from me&Xemu, let's be honest.

I had a chat on Discord with Serentty that starting with some builds of Windows 10, Microsoft finally started to support UTF-8 (after decades long waiting) strings as file names / paths in the normal set of filesystem functions (does not require special, Windows-only version of wchar capable functions set). This motivated me to try to figure out how this can be done.

What I could come up with:

the windows resource file (.rc) should contain this file:

1 RT_MANIFEST "../../build/windres-manifest.xml"

And an XML file should be constructed when, which according to Microsoft it contains something like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <assemblyIdentity name="xemu" version="6.0.0.0"/>
  <application>
    <windowsSettings>
      <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
    </windowsSettings>
  </application>
</assembly>

Files in the dev branch:

• https://github.com/lgblgblgb/xemu/blob/dev/build/windres-manifest.xml
• https://github.com/lgblgblgb/xemu/blob/dev/build/windres.rc

I'm a bit clueless what exactly "name" and "version" should be (at the assemblyIdentity tag), should it be aligned with some other value, like the ones in the .rc file, or whatever ...

This is used than with gcc-mingw's windres utility (Xemu is compiled on Linux even for Windows, using the mingw cross compiler to produce exes). According

Needless to say, it seems to overkill for me, to have such a heavy weight machinery to enable UTF-8 filenames instead of calling a simple function or something ... But that's Windows, I am not even surprised, and anyway, I am happy to have any way to do this. According to my tests, it seems to work, though I have to be sure I have this line in the windres.rc file:

 #include <winuser.h>

Actually, lacking this caused me some three hours headache while trying various things why it does not work.

If you have any suggestion, correction, opinion on this (especially from programmers/developers for Windows in this case), please share with me! Thanks!

Still on the .rc file

As mentioned in the previous question, the .rc file is:

#include <winver.h>
#include <winuser.h>
1 VERSIONINFO
BEGIN
BLOCK "StringFileInfo"
BEGIN
	BLOCK "040904E4"
	    BEGIN
		VALUE "Comments",		"https://github.com/lgblgblgb/xemu/wiki"
		VALUE "CompanyName",		"LGB (Gabor Lenart)"
		VALUE "FileDescription",	"xemu - X-Emulators"
		VALUE "InternalName",		"xemu"
		VALUE "LegalCopyright",		"GNU/GPL (General Public License) v2 or later"
		VALUE "OriginalFilename",	"xemu"
		VALUE "ProductName",		"xemu"
	    END
      END
 END
 1 ICON "../../build/xemu.ico"
 1 RT_MANIFEST "../../build/windres-manifest.xml"

To be honest, I am totally lost here, it's merely the product of "try&error" and from various examples by browsing the Internet. I couldn't even find an extensive document what format of this .rc file is, so I have questions like this:

• What is that "1" number? Some examples do not have number there but various other things like CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "src/c/arch/win32/manifest.xml" instead of just 1 RT_MANIFEST "src/c/arch/win32/manifest.xml"
• Also some examples have things like 101 ICON DISCARDABLE "src/c/arch/win32/icon.ico", what is 101 here? How is it different from 1? What is DISCARDABLE?
• What is "040904E4" why that hex number, what does it mean exactly? Are there others?
• Also, following some examples, I have those info lines on "Comments", " "ProductName" etc filled. But then in Windows, right clicking on the exe, and get properties, I can though see the correct icon from "1 ICON", none of those textual infos are displayed. Why? And then what are these for?
• The mentioned manifest file (for the UTF-8) also contains "name" and "version" at one place, should be aligned with the info here? Or something else?

For the last point, here is a screenshot (where I expect to see those info, but all fields are empty, regardless I have info for those in the .rc file, though the icon is OK):

So you can see my stupidity here, I have no idea, in general :) Unlike UNIX systems, there is no such a thing that the man utility that basically I can have manual on everything, commands, system calls, APIs etc etc, it's sometimes very hard to find information on Windows stuffs, which is a piece of cake with UNIX-like systems in general.

Windows console handling

Xemu has some "black magic" code dealing with the "Windows console", which is - again - a very unique special Windows madness compared to other host OSes. Basically it "works", however there are problems:

• The code is really ugly
• Even I - the author - don't know how it works (I used several examples found on the Net, experimenting, modifying, etc)
• Sometimes - for unknown reasons - other opened files are corrupted, see CORE: on Windows file handle of closed console still in use later, can even corrupt files used by Xemu then #262, though it's unclear if this issue is already really fixed or not

Anything other?

Please tell me, if you have any opinion, suggestion on the Windows releases of Xemu. Surely I am more interested on Windows-specific things in this topic at least, not something which is Xemu on general, but what is specific to Windows versions or affecting only Windows users. Thanks!

[deathybrs]

While it is not common to run Windows as a full administrator, those that do tend to be power users as you have to go out of your way to set it up that way (these days)... I wouldn't worry too much about forcing safety for people who are capable enough of putting their windows into a permanent unsafe state.

Unfortunately, the other two things are not something I can contribute to.

[lgblgblgb]

@deathybrs Thanks for your comment. Well, indeed. The only reason I worry for others' safety, that Windows systems in general alarms users that this is an unknown exe, not signed, "are you sure to run it" and also sometimes some false alarms on virus/trojans in Xemu. I have been already confronted with very angry people stating that Xemu is a scam to put trojan into their system as their virus protection warned to be that. You see, since the generic suspect here, I would like to be careful then it won't be the point a system is exploited ... Sure these claims are false, but rises eyebrows of users already thus better to be extra careful at this point.

Btw, updated the original text with this.