OSDev.org

Octocontrabass wrote: You can write a user interface in C if you use NativeActivity. There are a handful of APIs you can use directly from C, but I think you can use JNI to access most (if not all) of the usual Android APIs.

Can you comment on this please:

"You may still need a little Java/Kotlin though, like for onCreate and other stuff."

NativeActivity is the Java code that handles onCreate. You don't need to include any of its code in your app, it's built into Android.

I don't know if there's any "other stuff" you can't do with NativeActivity and JNI, I haven't tried writing an entirely-native-code app yet.

Octocontrabass wrote:NativeActivity is the Java code that handles onCreate. You don't need to include any of its code in your app, it's built into Android.

I don't know if there's any "other stuff" you can't do with NativeActivity and JNI, I haven't tried writing an entirely-native-code app yet.

Thanks for that. Further investigation found some links:

https://github.com/cnlohr/rawdrawandroid

https://developer.android.com/ndk/sampl ... le_na.html

https://stackoverflow.com/questions/329 ... ithout-jni


but in each case, OpenGL is used, which is used for games, not "normal apps". Is that an issue (maybe it's not?)?

Either way - do you know if it is possible to avoid OpenGL regardless?

And finally - one thing I am interested in is for the text on the screen to be "readable" by blind people. So it needs to be text, not graphics, so that they can use inbuilt (to Android) text to speech. So if OpenGL takes that away, or makes it difficult, then that would be a reason to avoid it.

And if that is the case, we are more likely to switch the 800 lines of Kotlin to (presumably?) 800 lines of Java, rather than making things more difficult for blind people.

It makes it more difficult for us to maintain though - as we normally program in C90, not the latest Turtle Graphics fad. But ... blind people.

kerravon wrote:Either way - do you know if it is possible to avoid OpenGL regardless?

I've never tried it so I don't know if it's possible. If it's possible, you would need to use JNI to access the Java UI APIs.

kerravon wrote:It makes it more difficult for us to maintain though - as we normally program in C90, not the latest Turtle Graphics fad.

Turtle graphics have been around longer than C.

kerravon wrote:And I'm about to do a fresh build which means there will be a mismatch likely starting in the next 24 hours until PdAndro copies across the new bios.exe.

PdAndro has finally been republished, so the mismatch has gone, and you now have a Win32 ARM mini-clone. Which will survive Microsoft's threats to remove support for 32-bit ARM apps in a future Win 11 ARM release.

And the old release of Android was managed to be supported. So the pdld author (from Slovakia) is able to run it on his (old) phone.

kerravon wrote: ↑Sun May 19, 2024 8:32 pm

kerravon wrote:And I'm about to do a fresh build which means there will be a mismatch likely starting in the next 24 hours until PdAndro copies across the new bios.exe.

PdAndro has finally been republished, so the mismatch has gone, and you now have a Win32 ARM mini-clone. Which will survive Microsoft's threats to remove support for 32-bit ARM apps in a future Win 11 ARM release.

And the old release of Android was managed to be supported. So the pdld author (from Slovakia) is able to run it on his (old) phone.

There were two issues previously:

1. I didn't have 64-bit "double" available as soft float, so I made the compiler use 32-bit doubles, which meant it wasn't always Win32 compatible.

2. gcc 3.2.3 uses double itself, and internal issues meant that I wasn't really able to stand up a self-compiling gcc 3.2.3

Both of those issues have now been resolved. The new APK is available in both the Google Play Store (published a week ago) and https://github.com/robertapengelly/Pdos ... o/releases (tagged in the last 24 hours).

However, there is still one main issue remaining - 64-bit parameters should be aligned by skipping a register parameter as required. gcc 3.2.3 is not doing this, so a program doing printf("%f", 3.4); will not work on real Windows 11 ARM 32-bit. bwbasic.exe is such a program. But I presume almost no-one uses real Windows for ARM and 32-bit support is supposedly going to be removed from a future Windows 11 ARM anyway, so it's largely a moot point.

The self-recompilation ability of my fork of gcc 3.2.3 means that this issue should be able to be fixed using PdAndro itself.

kerravon wrote: ↑Thu Jun 20, 2024 1:52 pm However, there is still one main issue remaining - 64-bit parameters should be aligned by skipping a register parameter as required. gcc 3.2.3 is not doing this, so a program doing printf("%f", 3.4); will not work on real Windows 11 ARM 32-bit. bwbasic.exe is such a program. But I presume almost no-one uses real Windows for ARM and 32-bit support is supposedly going to be removed from a future Windows 11 ARM anyway, so it's largely a moot point.

A new version of PdAndro has been released. This issue has now been fixed. Plus the ARM64 version is now Win64 ARM64 compatible too. It is built independently with Visual Studio though - I don't have my own tools to do that on the Android itself. Plus I have a mainframe emulator for all 4 Android targets. Using the mainframe emulator, you could use gcc for the mainframe to eventually stand up a compiler that could target ARM64. The mainframe emulator is only suitable for z/PDOS-generic, and also has some deficiencies that are being ironed out, so I'm not sure you can use the mainframe compiler in practice right at this moment.