WinRT Desktop environment build

[hooddy]

Please compile WinRT build. There is VS2011beta with ARM dlls and VS2012 to compile it.
I miss any 2 window file manager for my Win8.1RT still.

[craigwi]

It is not a goal of this project to support anything besides a native (x86 / x64) desktop app. I will make that clear in the readme.md.

[hooddy]

I didn't mean an metro app. I mean winrt desktop app. Like vuescan works like a charm on my winrt tab. Or Office 2013 for WinRT.

[craigwi]

I see; thanks for clarifying. The only difference then is compiling for ARM. Getting the right tools will be the trick. I'm not interested in downgrading the solution to use VS prior to VS2015, but I do compile ARM apps for my Windows Phone :) and so there might be an easy solution. Let me know if you have specific points on tools which work with VS2015 or VS2017.

[hooddy]

Well as I know VS2012 can build it well. I have WinDjView, Pain.NET, 7zip and few another rebuilded Win32 for WinRT app. In VS2011beta was leaked MFC dlls for ARM. So I'mnot sure how about to VS2015-2017. Anyway Im just a user. All of this apps compiled by some guys. Also there is couple Far manager for WinRT build but I don't have it. Well if ya can build it it would be good. If you don't well it's okay.

[craigwi]

I have setup VS2017 to compile for ARM and get the following error:

C:\Program Files (x86)\Windows Kits\10\Include\10.0.14393.0\ucrt\corecrt.h(225) : warning RC4011: identifier truncated to '_ARM_WINAPI_PARTITION_DESKTOP_S'

I have spend quite some time trying to figure this out. I will now pass this issue on to others to solve.

Let me know if you find a solution. If not, I will consider this issue 'won't fix'.

[NazmusLabs]

Compiling to ARM is a great idea, and looks like a fun challenge to take on.

[Biswa96]

But how one can test/debug it? Most of the developers has not Windows ARM device yet.

[NazmusLabs]

@Biswa96 well, the key word is "yet". :P I really hope we can get more ARM based devices running newer Snapdragon processors and at a cheaper price. Recompiling a lot of desktop apps to ARM literally solves the "x86 emulation" being slow issue. I remember in the beginning finding native x64 apps were rare to none. Now it's rare not to find a native x64 app. I am cautiously optimistic that if we have more ARM devices in the market, more desktop apps devs will try to offer ARM builds, and as more developers try to compile for ARM, we'd learn more kinks and ways to troubleshoot errors like the one mentioned above.

I don't have an ARM Windows Device at hand except a Surface RT running Windows 8.1 on ARM. But, to even run non-Microsoft signed desktop apps, Windows RT 8.1 needs to be jailbroken through a complicated process, one that I am not wanting to risk bricking my RT device with; so, it makes for a very suboptimal testing rig. I wish Windows RT just allowed ARM desktop apps. I mean why even bother having a sort of an artifical "S" mode on Windows RT since it didn't emulate x86 anyway and "normal" users won't go out to build ARM binaries. Sigh.

Then those RT devices could come really handy right now.

[jmiller099]

built it for windows rt arm. ran it on windows rt 8.0 on a surface rt e1. here's the steps and screenshot

http://www.wanderinghuman.com/blog/archives/000123.html

[NazmusLabs]

@jmiller099 Thanks! This would be the best resource we have for now until we have more abundant and affordable Windows 10 ARM devices. It's too bad there's no emulators for Windows 10 on ARM, though it's understandable, as it's a full desktop OS and making an emulator would be a massive undertaking, as I am not aware of a signal publicly available ARM chipset emulators. Even Windows phone emulators were just x86 builds of Windows Phone.

[Biswa96]

One can emulate Windows 10 ARM with Qemu. See this article: https://withinrafael.com/2018/02/11/boot-arm64-builds-of-windows-10-in-qemu/
But it is too slow to test a program. Is it possible to emulate single executable file without the whole OS?

[jmiller099]

I posted the binary in a zip to xda developers windows rt development forum.

[ZanderBrown]

@Biswa96 not sure about Windows hosts but a Linux host can run single executables through qemu

[NazmusLabs]

@Biswa96 okay, that's just amazing! Thanks so much for the link. This is just...awesome. I'm guessing x86 emulation on these arm builds won't work because it relies on emulation features in the latest qualcum chips. But since Windows 10 "expects" the hardware emulation to be there, I wonder how WoW will react if we try to run an x86 executable. I know with Windows RT, Windows knew it couldn't run x86 apps, so trying to run it didn't throw an exception and gave a properly programmed error message. I guess the best way to find out is to give this a shot and just see what happens.

[jmiller099]

@NazmusLabs

I don't know much about WoW. Windows RT would look at the PE header to determine machine type. If the value was not 0x01C4 then it would pre-emptively launch an error dialog saying the program can not run on the machine and exit prior to loading any code.

Therefore I would guess Windows 10 on ARM would make a conditional like the following pseudocode:
switch( pehdr->machine ){
case 0x14c:
LoadCodeandEmulatex86Processor();
break;
case 0x1c4:
LoadCodeAndRunNative32bitApp();
break;
case 0xaa64:
LoadCodeAndRunNative64bitApp();
break;
case 0x8664:
ErrorMessageUntilThePressHintThatx64EmulationIsFinished();
break;
}

[NazmusLabs]

@jmiller099 Windows RT didn't have WoW, so it will just gracefully terminate any attempt to run an x86 app. I tried to do do back in 2013, and it just pops up the same modern dialog box that you get when trying to run 16 bit apps or ARM apps on Windows x64. It says "This app won't run on this PC. Contact the publisher for the version for your PC."

But since Windows 10 on ARM was built with emulation in mind, it has a WoW layer. And depending on how MS handled it, it might be the same experience as on RT or it might bugcheck (BSOD) due to WoW trying to find the emulation instruction set on the non-qualcum processor...or perhaps something else entirely.

[ZanderBrown]

@NazmusLabs or Win CE apps on Win Me....

[hooddy]

It looks that it builded well
https://forum.xda-developers.com/windows-8-rt/rt-development/winfile-t3776111
But it doesn't run well under WinRT8.1 Seems that it runs on WinRT8.0 (there is differrent jailbreaks).

[craigwi]

My suggestion is for @jmiller099 to propose a small set of changes in two parts:

1. changes we want in master that help the WinRT situation (might be slim to none)
2. changes to put in another branch (e.g., named winrt) that support those who want the winrt build.

Ok?

[jmiller099]

@craigwi 

1. the changes required were merging this PR:
   Restore dogfooding in XP #21

which was changed to this based upon your request (still workable for RT):
#59

2. Then for the RT branch only a vs2012 workspace and project file are needed. resolving pollution in master by new commits containing out of scope local variable declarations or cpp for loop iterations is future headache.

Request to you, please merge the latter PR (#59), then I'll make a branch to add my workspace and project files.

@hooddy I don't have an rt 8.1 device to test against, but I think the key difference in the jb is:
8.0 allows unsigned executables.
8.1 requires signed executables but a developer test signature meets the requirement. maybe you can add on to the thread and ask if anyone willing to sign it for rt8.1?

[hooddy]

@jmiller099 there is a tool to sign off local unsigned apps and it works well. So Im not sure it about it. WinDjView compiled some years ago works well under RT8.0 and don't with the same stupid error 1566 in dll. There is an updated build works well under RT8.1 with some limitation. It builded with leaked MFC dll from VS2011beta as I know. There is no much I can say about it coz Im not a developer unfortunately.

[NazmusLabs]

Question: wouldn't it be just best to have the ARM stuff part of the master branch because Windows 10 ARM is now a thing and having an ARM port helps both Windows RT as well as Windows 10 on ARM going forward.

[jmiller099]

@NazmusLabs 

the toolset to build a win 10 on arm exe differs from the toolset to build windows rt exe. I'd imagine the woa10 could and should be mainlined.

for rt8.1 compatibility attempt - I rebuilt the exe linked against custom libs without ordinals and await feedback if it works.

[woachk]

Compiling to ARM turned out to not be that hard. (on VS2017 of course)
A hint: you want to use /MT to run it directly on most RT devices :)
You need to change AdditionalDependencies to ole32.lib;shell32.lib;shlwapi.lib;version.lib;advapi32.lib;gdi32.lib;comctl32.lib;OleAut32.lib because GUI libs aren't included by default to the list on ARM, that's about it.

Prebuilt version available in the XDA forums (latest post).

[woachk]

@hooddy I have MFC for Visual Studio 2017 on ARM if you need it for a reason or another.

[hooddy]

Well it's done by black_blob
https://forum.xda-developers.com/windows-8-rt/rt-development/winfile-t3776111/page2

[craigwi]

Nice work. I must be the lone holdout on VS 2015. Do folks see a reason NOT to move the project forward to VS 2017? What about target platform version? Are we ok with 10.0.16299.0 ?

[Biswa96]

How about two different set of .vcxproj and .sln files? One set for VS2015 and another set for VS2017? This configuration also helps in Appx project.
Also place the solution file out of src folder.

[craigwi]

how does that help with the appx project?

[Biswa96]

If there are seperate .sln and .vcxproj file users don't have to edit those file to support their toolset. Just they click on the build option and good to go. For appx users have to edit VS2015 .project file. Those who uses VS2015 they also don't want to edit project file. These two sets also provide backward compatibility easily.

[hooddy]

@woachk fine! please share ARM MFC for WinRT. Maybe ill find some way to compile soft I need (but ya know all I need already isn't))) it all at xda in my asks).

[woachk]

@hooddy see the ARM64 apps thread, in the download section, the mfc.zip is actually for ARM32. Make sure to use static linking though, I didn't include the DLLs.

[NazmusLabs]

I'm okay with VS2017 and 16299. I maybe wrong, but I think focusing on the latest SDK allows us to not worry about maintaining multiple SDKs. I like the idea of just staying with the latest platform and deal with issues as they come rather than staying on one and then having to eventually upgrade to a new SDK that is several versions or years newer and deal with the pains of a giant upgrade leap.

[craigwi]

My current thinking is to move to VS2017 and 16299 as the only sln/vcxproj files in master. The Windows Store distributable can be created using that. The mingw version has it's own makefile. The retro and other forks/branches can have what they want.

Last call for comments on switching master to VS2017/16299.

[Biswa96]

Two seperate file for Vs15 and Vs17!

[craigwi]

@Biswa96, I did see that request above. Maintaining two files would be extra work that I'm not sure is worth it.

What can you compile with VS2015 that you cannot compile with VS2017? By VS2017 I am referring to the community edition which is available at no cost. At home, that is what I use.

[NazmusLabs]

I personally see nothing that cannot be done in 2017 that is done in 2015. And VS2017 Community edition is free, and the VS installer is very modular, allowing us to choose workloads; so, anyone relying on VS2015 can choose a C++ VS2017 workload to run it side by side with 2015 and without having 2017 take up too much disk space.

[craigwi]

A small question. When I change to VS2017 / 16299, I was thinking of moving the sln file to the root directory. I will also add ARM build per this issue.

Should I move the GNUMakefile to the root too? Any other changes of this nature?

[ZanderBrown]

👍 as long as all paths are updated it would be better to have sln/makefile in root (easier to find if nothing else)

[woachk]

16299 is fine, the VS build corresponding to 17134 adds arm32/arm64 MFC, which isn't used in this project.
You might have to add <WindowsSDKDesktopARMSupport>true</WindowsSDKDesktopARMSupport> and <WindowsSDKDesktopARM64Support>true</WindowsSDKDesktopARM64Support> in the Global PropertyGroup in the VCXProj to avoid errors.

[woachk]

Visual Studio 2015 with 14393 works fine for ARM 32-bit and ARM64 with the internal addon too. ;)
You have to add the above change to the vcxproj though, and as it makes no harm...
For the record, ARM and ARM64 MinGW are perfectly good and usable.

[craigwi]

Master branch now uses VS2017, SDK 16299 and compiles for ARM. ARM build not tested yet!

Many thanks to @woachk for the settings to make this work on 16299.

[hooddy]

@craigwi push it away for testing pls

[craigwi]

A current build can be found at https://winfilerelease.blob.core.windows.net/craigwi/ARM/Winfile.exe.

[hooddy]

Well... It works!) How to trasnalte it into russian?

[NazmusLabs]

@craigwi Question: is this using the new ARM64 compiler announced at Build 2018? If I'm not mistaken, that requires a preview versions of VS and Win10 RS5 SDK, no?

[craigwi]

No, just VS2017 and SDK 16299 per the vcxproj. The build system I use, which also signs the files, honors those settings.

@hooddy, thanks for trying it out. Can others confirm?

[hooddy]

Well there is an one issue still. I need to put msvcp140.dll n vcruntime140.dll into app folder or system. But its ok i suppose.

[Biswa96]

That remind me something from past...

[hooddy]

The menu font is hard to view.

Can ya fix it please?

[craigwi]

Any ideas about what to do about the font issue? It sure does look different (bold).

[clzls]

@hooddy To translate, simply download files ending in _en_US.* in the folder src/lang, translate them to Russian, change en_US to your language code, and make a pull request to add them into this repo. If you don't know how to use git, you can mail them to us.
@craigwi Lack of certain fonts? (I don't have WinRT devices though)

[hooddy]

@craigwi seems to be its ok. Maybe this was glitch. Ive download this once again n its ok now. Maybe I just have to reboot my tab.

@clzls i do this later tanks.

[craigwi]

Thanks @hooddy. I'll close this issue since we have a ARM-based desktop build. Open new issues for new problems.

[Poopooracoocoo]

@craigwi

we have an ARM-based desktop build

Mind adding that to your README?