Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
67 user(s) are online (45 user(s) are browsing Forums)

Members: 2
Guests: 65

trixie, ddni, more...

Headlines

 
  Register To Post  

Future OS4 direction
Not too shy to talk
Not too shy to talk


See User information
Quoted from Rogue from aw.net:

Quote:
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.

Go to top
Re: Future OS4 direction
Not too shy to talk
Not too shy to talk


See User information
@jahc

I find this revelation very interesting...

Soon to own a powerful AmigaOne X1000 with latest AmigaOS 4.1 incarnation ;) Dual Core PPC!

- Helgis
Go to top
Re: Future OS4 direction
Quite a regular
Quite a regular


See User information
@jahc

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 that are missing right now.

Like I wrote on amigaworld.net, this was part of a very early draft I had written.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top
Re: Future OS4 direction
Not too shy to talk
Not too shy to talk


See User information
@Helgis

Its hardly a revelation. OS4 was *always* going this way...

Go to top
Re: Future OS4 direction
Not too shy to talk
Not too shy to talk


See User information
@Helgis

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.

Go to top
Re: Future OS4 direction
Home away from home
Home away from home


See User information
@jahc

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.
Go to top
Re: Future OS4 direction
Just can't stay away
Just can't stay away


See User information
Hi @Rogue
@jhc
Quote:
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!

Go to top
Re: Future OS4 direction
Not too shy to talk
Not too shy to talk


See User information
@LiveForIt

Wine Is Not an Emulator.

Go to top
Re: Future OS4 direction
Just can't stay away
Just can't stay away


See User information
Hi @LiveForIt
@Rob

(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.

Go to top
Re: Future OS4 direction
Just popping in
Just popping in


See User information
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.

maybe I think just too loudly... ?

Go to top
Re: Future OS4 direction
Just popping in
Just popping in


See User information
@Mlehto

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!

Happiness is mandatory
Go to top
Re: Future OS4 direction
Just popping in
Just popping in


See User information
@Rogue

Will you be moving to 64-bit at the same time?

Go to top
Re: Future OS4 direction
Home away from home
Home away from home


See User information
@Rogue

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.

Hans

Go to top
Re: Future OS4 direction
Not too shy to talk
Not too shy to talk


See User information
@Hans

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.

Go to top
Re: Future OS4 direction
Quite a regular
Quite a regular


See User information
@xeron

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.

cheers
tony
Go to top
Re: Future OS4 direction
Home away from home
Home away from home


See User information
@tonyw

I would imagine that exec functions such as SuperState() and Disable() will dissapear too.

Hans

Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project