@DaveP and all

Hello guys, I am scratching my head on this but here is my opinion and thoughts on the following sentences and paragraphs -


If you want AmigaOS to be targeted to everywhere then you have to write this thing in a completely platform independent fashion and if things are focused on PPC.
Then you are not going to ever get market in the handheld portable market except for maybe under emulation which is guaranteed to be a market for piracy and $0 revenue proceeds because people don't generally spend money for OSs, apps, ect. when emulated because those who typically use emulation (running AmigaOS 4.x insided - lets say an AmigaOne emulator on Windows 8 or 9 (whatever it be called) then you can be certain that they are too cheap to spend money because they play it for the fun not serious work.

Emulator users typically don't spend money on stuff being ran under emulation. They will spend money for their native OS & HW.

Despite opinions of Amiga Inc. and Bill McEwen, they have the right general principle for an AmigaOS that is portable. They need an OS that is not locked to a CPU and include implementation of AmigaAnywhere or similar API system and the very OS is built on top of that base technology.

Remember an OS is simply a program. Modern computers is no different then the old C64. The hw provides the interrupts that allows for task switching. We can assume that is there in all modern (hw made since 1995). An OS that is portable has to be written on a platform that allows it to be ran and activated at the BIOS (or similar mechanism).

So for hypothetical theory, you write a multi-user, multi-task OS engine and kernal in C/C++ using AmigaAnywhere & perhaps OpenGL API, then in the OS package, you include the API libraries like (AmigaAnywhere, OpenGL, SDL, ect.) to build applications, games,ect.)

If the games are distributed in source code form and compiled (as part of the "Installation" process is compiling the source code) then you got portable software.

Java is portable because it is distributed as source or compiled to a VM byte code system. But Java needs a Run-time player (compiler) to convert byte code to native binary. The draw back is run-time byte code to native binary slows app performance down but with advanced hw is not noticable but taking source and compile to native code as part of installation process using the OS packaged AA/SDL/OpenGL/ect. supporting compiler system would give you a native code that runs at full speed.

I probably haven't covered every aspect but just to highlight the principle idea. With varying hw infrastructure, it would be reasonable to assume that hw will act to varying degree of performance and some degree of variability but an app/game can be built around the principle of portability.

The programmer will have to implement logic to determine the needed "includes" (C/C++ parlance) for the given platforms but there is some limitation to planning and a selective degree of platforms/products to plan for.

You can't really plan for something that is made in the future.

There are many snares and people make hw that has proprietary (unique to how it works and so on) features / functions for obvious reasons on purpose. You can't plan for what currently doesn't exist but only when it does come into existance.

You can only do a limited degree on future planning but can't assume that everyone will follow the rules and make one unified platform because everyone is competing with each other and makes their own unique hw with some standardization but rarely entirely so. They want something unique to market.

Otherwise, everything is a simple toaster and these companies that produce toasters are explosively growing. They often don't even really market them. When that happens, growth has been reached and from that point on, things will be stagnant until someone breaks the rules and diverge to make something new. There is a danger to universal conformity to one universal standard. It leads to a trap of industry/market stagnation.