pax86
Main Page
Blog
History
 

pax86 - Blog

May 3rd, 2015 - Back to working on pax86

After a hiatus of almost a year, I decided to continue working on pax86. The main reason I stopped working on my emulators was that I wanted to give Retro Infinity Inc time to release their games they licensed my emulator technology for. However, it is starting to look like they won't be able to release anything at least for a while yet, so I thought that perhaps it would be best if I were to move forward towards my eventually releasing my emulators on various mobile phone platforms myself.

Building a VS2012 WP8.0 project using VS2013

I am currently working on the Windows Phone 8 version of my emulator. Since I last worked on it, I have upgraded both my phone and my desktop PC to Windows 8.1, and I had lost the Visual Studio 2012 Express that I used to build pax86 in the process. I decided to install Visual Studio 2013 instead, and see what happens when I try to open my pax86 WP8 project in it. This worked fine, with a message that it is recommended to upgrade the project to target Windows Phone 8.1. I did not want to upgrade the project until I had tested that I can build my native library using the VS 2013 ARMASM tools.

I tested compiling my pax86 library using the VS2013 ARM tools, but that resulted in the project (which was still targeting 8.0) not being able to link in my library (due to a compiler version mismatch). I noticed that VS 2013 includes also Visual Studio 2012 ARM Phone Tools Command Prompt (which I originally used to build my library), so I tried to build my library using that. However, ARMASM compiler just crashed with MSVCDIS110.DLL not found error. I had to hunt for that DLL on the net, but after putting that to the same directory as where the ARMASM tool itself is, I was able to compile a WP8.0 library using VS2013, and link it into my pax86 test project.

Running the newly built pax86 WP8 test project failed to find 4DOS.COM, and it took some experimenting to notice that the new Isolated Storage Tools used a new Shared folder under the LocalFolder root to store the files I tried to send to the phone. After I fixed that in the code, I was able to launch my pax86 WP8 test project on my Nokia Lumia 520 phone running Windows Phone 8.1 OS! I also found a much better tool to transfer files between the phone isolated storage and my PC: Windows Phone Power Tools. That program is much more convenient than using the command line ISETool.exe I had been using before.

Okay, now that I was back in business I decided to test my simple TEST.COM program that tests the BIOS text output routines in all my supported screen modes. Somewhat to my surprise, the text output failed in all the graphics modes! After some more testing I noticed that I had been using a complex addressing mode in my text output routines for graphics mode, and this addressing mode did not seem to work in Thumb2 mode. What was strange was that the compiler did not give an error message about an unsupported addressing mode! The opcode in question was this: 

            ldrb    r0, [r3, r0, lsl #3]!
It does not update the r3 register after the operation, as it does in ARM mode. I had to replace those opcodes with code like this: 
            add     r3, r0, lsl #3
            ldrb    r0, [r3]

Upgrading my Windows Phone 8 project to Windows Phone 8.1

After that fix I began looking into the possibility of launching 4DOS.COM and all the DOS games from the SD Card instead of from the LocalFolder (isolated storage). It would be pretty inconvenient for the end user having to use some external tool to be able to copy games to the phone. It would be much simpler just to have a folder on the SD Card where you can store all your DOS games. I found an MSDN page that describes how to access an SD Card from a Windows Phone program. However, when I tried to get the SD card root folder using Windows.Storage.KnownFolders.RemovableDevices, my code just crashed with a "Not implemented on Windows Phone" exception. Since this is supposed to work, I thought that perhaps I really need to upgrade my project to Windows Phone 8.1.

Upgrading the project was surprisingly easy. My code compiled fine, and actually I did not even need to upgrade the native code DLL, it was enough to upgrade the managed C# main project. Getting the SD Card access to work was not quite so straightforward, though, as I originally did not notice that the Windows Phone 8 WMAppManifest.xml file is actually replaced by the Package.appxmanifest file on Windows Phone 8.1. I had to add the removableStorage capability to the new Package.appxmanifest file, but after that I was able to get a folder access to the SD Card.

Accessing .COM and .EXE files from an SD Card on Windows Phone 8.1

So, now I was able to access the SD Card, however, I still was not able to do much with that access. The afore mentioned MSDN document states:

Well, that is a problem, as there is no way I could register pax86 to handle all the potential file types that a DOS game could attempt to load. In addition, most of the relevant file types (like .COM, .BAT and .EXE) are reserved for the operating system. I registered an .x86 extension for my pax86, and then copied the 4DOS.COM to 4DOS.x86 on the SD Card and attempted to launch it in pax86. Not surprisingly this worked fine. However, that would still not allow me to start any actual DOS game from the SD Card.

Since I had copied (and not renamed) the 4DOS.COM to 4DOS.x86, I still had also the 4DOS.COM program on the SD Card, and when running the 4DOS.x86 and pressing F7, it found that file as well. That was a little bit curious, as based on the above I thought I would not even be able to see the .COM files on the SD Card. Well, I decided what sort of an error message I get when I attempt start the 4DOS.COM within the running 4DOS.x86 command processor, and to my surprise it started up fine! Okay, so what is going on? That .COM extension is reserved by the OS and I certainly had not registered it to my pax86 test program!

Next I copied DOOM on the SD Card, and that too worked fine, so that my pax86 was indeed able to access .COM and .EXE files from the SD Card! However, when I attempted to launch 4DOS.COM directly (using the c# folder access routines), that did cause an "unauthorized access" exception. So, it looked like the low-level C file access routines can access all files on the SD Card, but the managed code file access routines have limitations on their access rights.

Downloading 4DOS.COM from the net

Similarly to what I did with my rpix86 and zerox86 emulators, I wanted the end user to have the option of letting pax86 download the required 4DOS.COM command shell from the internet if it is missing from the disk (or SD Card). So, now that I was able to launch 4DOS.COM from the SD Card also on my WP8 version of pax86, I began working on code that would download it. Of course I don't want to download it if it already exists, so I needed a way to check whether the SD Card already has 4DOS.COM before I start downloading it. Here I again ran into the problem of access rights from the managed C# code (where I wanted to do the download), so I had to code a helper routine on the native code DLL to check for the file existence, and to rename the downloaded 4DOS.x86 file to 4DOS.COM file. In the end I managed to make the code work pretty well, so there is now a simple check and download option when pax86 starts up on WP8.

Access limitations in Windows Phone Store Apps

Until now I had thought that using the native code to access the SD Card would work, but then I ran into a related question on the MSDN forums, where the reply by a Microsoft representative contained the following quote:

Keep in mind that you will not be able to access the SD card directly once your app is published to the store as that is a restricted API. You should submit your app as a beta and then download and install it on a physical device to make sure what you are trying to do is possible once your app has been processed by the store since the restrictions are much more strict than when you sideload your app via the SDK.

Okay, now that did not sound good. I decided to look into submitting pax86 as a beta to the Windows Phone Store, and see what happens. It was not quite straightforward to submit the app, so I'll list the problems I encountered and their solutions here for future reference:

  1. First I had to create a developer account. This was the easy part.

  2. Next, I tried to upload my .xap package, but that generated a huge number of validation errors like the following: 

    1028: The native API MSVCR110D.dll:sprintf() isn’t allowed in assembly PhoneDirect3DXamlApp1Component.dll. Update it and then try again.
1028: The native API MSVCR110D.dll:??1scoped_lock@critical_section@Concurrency@@QAA@XZ() isn’t allowed in assembly PhoneDirect3DXamlApp1Component.dll. Update it and then try again.
1028: The native API vccorlib110d.DLL:?__abi_WinRTraiseObjectDisposedException@@YAXXZ() isn’t allowed in assembly PhoneDirect3DXamlApp1Component.dll. Update it and then try again.
1028: The native API MSVCR110D.dll:fseek() isn’t allowed in assembly PhoneDirect3DXamlApp1Component.dll. Update it and then try again.
...
    I found a question on stack overflow with a similar problem, and the resolution was that you need to upload a RELEASE build, not a DEBUG build. Well, that was just simple click and rebuild, and then I was able to upload my .xap package again.

  3. The upload of the RELEASE build still resulted in two validation errors: 

    3201: The publisher display name, Pate, specified in the package doesn’t match the publisher name, Patrick Aalto, that’s associated with the developer account.
1028: The native API MSVCR110D.dll:_mkdir() isn’t allowed in assembly PhoneDirect3DXamlApp1Component.dll. Update it and then try again.
    Well, okay, I guess I have to change the publisher name of my software to be my full name instead of my nickname, so that was easy. But why was mkdir not allowed? I searched my code for the mkdir calls, and it was used only in the DOS mkdir call emulation. I wanted to get my package tested, so for now I just commented out that call. This allowed the package to get uploaded.

  4. Now I got one step further, but I got an error on the next step: 

    The package identity associated with this update doesn't match the uploaded appx: "2e740376-677c-4df8-b1af-95b72863f017"
    Here also stack overflow was helpful, and I was able to update my Package.appxmanifest file with the correct identity from my developer account.

  5. Okay, now I got so far that the Windows Phone Store began a proper review of my application. This took about 15 minutes, and then I got an email stating that the review result was Non-Compliant. I went to back to my developer account and downloaded the full review report. It had the following problem:

    Well, that was pretty silly. I am submitting my app just for my personal beta test, so what does Microsoft care that I don't have nice logo images for it! Well, I just quickly edited all the images and resubmitted my app, and again waited around 15 minutes for the review. This time it went fine, and I got an email with a link to my app on the Windows Phone Store.

After I installed the pax86 beta test application on my phone, I was able to confirm that indeed, when downloading the app from the store, it has no access to .COM or .EXE files on the SD Card, not even from the native code. This is an annoying limitation when attempting to code an emulator, as the only option remaining is to always run the games from the isolated storage of my application. But how can users copy their DOS games to the isolated storage, as only my pax86 has access to its isolated storage, and it has no proper access to the SD Card where it could copy the games from?

Next I plan to look into what options I have for this copying. I am thinking that since my app can access .x86 files from the SD Card, one option would be to require the users to zip up the game directory on their PC, rename this .zip file to .x86 file, copy this to the SD Card, and then use some new file browser feature in pax86 to copy and unzip the archive file to the pax86 isolated storage. Pretty complicated operation, so I am hoping I can eventually think of some better options.

Anyways, thanks for your interest in my emulators, I hope to continue working on pax86 for various platforms in the future! Oh, and by the way, do not ask for beta access to the pax86 WP8 version yet, it is not at a stage where you could actually do anything with it. :-)

Older blog posts

See here for blog posts from 2014 and before.