FWIW, I am not saying that AmigaOS 4.0 is a dead end design. However, everybody with half a brain cell will agree that to evolve the current design, you need to do something about the way certain things are handled right now.
Apple did the same thing. They invented the Classic environment for binary compatibility, Carbon for source code compatibility, and Cocoa for the new stuff. This is very similar to what we want to do:
- A virtual environment to run classic OS 4 binaries in. - A compatibility library that will allow you to compile OS 4 source code to the new system, trying to stay as compatible as possible and to go with as little changes as possible, with possibilities to narrow down incompatibilities (like with Carbon where you could "close" system structures and use new accessor functions). - A new API for the "native" stuff.
The virtual environment may still be self-hosted for resource-limited devices, and will be continued to be developed.
If you really think that AmigaOS can be developed into a more modern system without doing this, you must clearly have a different idea about "modern" than I have. But memory protection is a must, and it simply is NOT POSSIBLE with the open structure approach that we have right now.
Rogue, if you guys do embark on these major changes, new API etc.. will this bring full memory protection, and full resource tracking to AmigaOS?
I'll port all my software over if/when the time comes anyway. I quite like the sound of a compatibility library. Sounds like it will help ease the transition, if we get to that stage.
Great that you are here now. I have said multiple times that I am not a Helge from Norway, but people have still confused me with you! Too bad the name is so common in our countries, maybe I should rename my nickname if that is possible?
But maybe things are clearer now for some peoples.
It?s quite clear that current state of the AmigaOS3.x/4.0 has some limitations or some broken design issues.
We have many new features in the AmigaOS4.x they can be used by new programs, but when you write program for the OS, that is generally you have to resort to old ways doing things because that how thing was designed to work in MUI, Graphics, Intuition, dos and everywhere else, so new features are kind of limited to new components and internal use in programs where it does not conflict whit some API or OS structure,
So now is the time for a general update of every thing, so we can have full memory protection and SMP support.
But this will break whit older program, and there?s nothing we can do about that, or is there, well emulators like WINE, Shapeshifter and UAE has been around for ages, and this how AmigaOS4.x will keep running AmigaOS4.0 and AmigaOS3.x programs that are system friendly by the old design.
It will be just like running WarpUP programs on update 3 or 4, hopefully it will a bit more compatible.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
This is going to take a good while still. But yes, this is aimed at getting full memory protection and resource tracking and other things...
I don't know too much about memory protection, task and resource tracking, but this 'restore session' on reboot would be the most welcome item on my OS4 wish list. Is that really hard to do? I ask because the XP here via FF updates automatically and shuts down all work and windows and warm restarts the system. Really shocking sometimes if a lot of work and tasks are pending -- all of sudden disappear!
(Wine Is Not an Emulator) Software that runs Windows applications under Linux and other versions of Unix running on an x86 PC. Wine runs Windows executables as they are. It executes them by trapping the calls from the application to the Windows interface (the Windows API), converting the arguments in the call where necessary and directing them to X Window routines, which perform the actual processing. For example, Linspire (formerly Lindows) is a Linux desktop operating system that uses Wine to also run Windows programs.
I personally think, that this is more than welcome.
Only thing, what worries bit. When coder base is large, transition from old system to new happens painlessly. When it is thin, things get more difficult.
Or maybe redesigning makes it more attractive for point of view of programmers from "outside" ... More modest OS, more new programmers.
Well a lot of OS4 apps are reasonably small and I imagine most people currently developing on OS4 will support improvements and want to keep their apps "native". I also imagine that these changes are a loooooong way off - maybe a couple of years or more down the line, so no panic just yet.
The biggest challenge will be in providing detailed examples and documentation, which has always been difficult to find for OS4. I get the impression that a number of people coding on OS4 are reasonably new to programming (myself included) and frankly, have very little idea whether we are going about things in the right way or not. Any drastic changes must be accompanied by lots of documentation!
I think that a list of programming recommendations that will minimise the porting effort from the current OS4 to the version with full memory protection would be helpful. For example, are you planning on replacing the message passing system completely? Or will we need to declare memory for messages as MEMF_SHARED? Or is there something else that needs to be done?
I don't know if you can answer these questions right now, as I have no idea how far planning/design is for these changes. However, having a list of recommended programming practises would be appreciated.
I would imagine that if you used IExec->AllocSysObjectTags( ASOT_MESSAGE, ... ) you won't go far wrong, that way what memory to use for inter-process communication is decided by the kernel.
Quite right. The AllocSysObject[Tags]() is these days the preferred means of allocating memory for -well- a System Object. It means that the object can be tracked and removed painlessly if your program crashes. ASO[T] is a step towards resource tracking (not the first step, just another step).
By using AllocSysObjectTags(), you can specify as tags all the flag stuff that used to take a whole line of source.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
