@Ami603

Quote:

Wasn't the Amiga philosophy something like:"if it works well for others,we'll benefit&improve it".

I really hope they arent doing that with the X86 family. I dont want to "benefit" of an improved slowtium4.

BTW, does anyone how to improve an X86?

-Frank

Quote:

If others would only use PutMsg to put messages into the port, then it would work, but looking at the recent discussion on UtilityBase about abusing undocumented features in the system, you can imagine that some "clever" guys will queue up the message directly...

It was never forbidden by Commodore and struct MsgPort is documented anyway... there always are developers who find another way to do what they want. I have seen OS4 native code calling 68k ExecBase functions via Emulate() when another violates SysV ABI...

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Quote:

It was never forbidden by Commodore and struct MsgPort is documented anyway... there always are developers who find another way to do what they want.

When there is access functions like PutMsg() and GetMsg(), queueing messages directly would be wery bad programming style. It's not about programmers freedom to do things the way they want. It's about doing things so that your code and system will work as they should in the future too. Queueing messages directly would be sure way to brake your code when system structures change.

Same applies to those AllocVec discussions in the IntuitionBase. If you do not follow the official documentation then it's your own fault if your code wont work after internal system structures change. Those undocumented "features" are just hacks and using them is bad programming style.
If many guys use those undocumented things it wont make those any less hackish.

Last edited by miksuh on 14-Dec-2005 at 07:37 PM.
Last edited by miksuh on 14-Dec-2005 at 07:16 PM.
Last edited by miksuh on 14-Dec-2005 at 06:59 PM.

Quote:

The new system only discerns between MEMF_SHARED and MEMF_PRIVATE. The old flags are still supported because of backward compatibility.

Does this also apply to interrupt code?

Also, I wonder if the new memory system supports custom exception handlers for different
memory regions (which, as far as I understand it, would be a slab then).

This was indicated in an earlier draft of AmigaOS4 functionality and could e.g. be used to
map a set of frames to a file like the Unix mmap() functionality. (this can of course be
implemented in other ways too)

AllocVec() is different case. Its internal behaviour is well known but it was never documented when struct MsgPort is. Changing MsgPort structure is next to impossible:

a) allocating one on your own has been valid from 1.0 to 3.9 and not forbidden in 4.0
b) there are no Set/Get methods to access MsgPort data (mp_SigBit...)
c) peeking to message list is needed sometimes anyway
d) feel free to fix struct Process (yes, I know there is GetProcMsgPort())

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

Quote:

It was never forbidden by Commodore and struct MsgPort is documented anyway...

No, but it is stupid regardless... there's PutMsg that will do what you need to put a message to a port... no need to do it yourself.

Quote:

there always are developers who find another way to do what they want.

Well, as long as they don't break rules, it's ok. Of course, all the structures on AmigaOS have always been open and even documented, which was a good thing back then, but it bites us in the back today...

However, and that's an important point, it's in most cases totally useless to go "short cuts" when there's a function that actually does what you are trying to accomplish... nevertheless, people do it.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

Quote:

Does this also apply to interrupt code?

Yes. If in doubt, you can lock the memory in place.

Quote:

Also, I wonder if the new memory system supports custom exception handlers for different memory regions (which, as far as I understand it, would be a slab then).

Yes, it does support that, but that functionality is internal to the kernel libraries.

Quote:

This was indicated in an earlier draft of AmigaOS4 functionality and could e.g. be used to map a set of frames to a file like the Unix mmap() functionality. (this can of course be implemented in other ways too)

This will be offered later as an encapsulated interface, i.e. you don't do that by hand, you'll have functions for that.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

Quote:

Changing MsgPort structure is next to impossible:

Actually, it is possible. Every port (and most system structure) start with a node structure. The node type can be set to something different (let's say NT_NEWPORT), and the functions can then act accordingly.

Since we now have a function (AllocSysObject) that is used to allocate such structures, it's possible...

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@itix

e) Direct messing around with MsgPort struct is used everywhere and by everyone. Including examples in autodocs, examples on DEV CDs. Done by all kind of coders, including OS3 coders, OS4 coders, AROS coders, MorphOS coders. Present in apps for all these OSes, including apps which are part of the OS itself. No need to be clever to come up with such code. It's normal code. A good example is CloseWindowSafely.

@itix

MsgPort is now just an example. I'm sure you have heard about abstract datatype. MsgPort is almost like an abstract datatype: it has internal storage structure and access functions for it. Ofcourse it would be more abstract if typedef struct {} MsgPort; would have been used instead of struct MsgPort {}. ADT should be like black box, which internal implementation is not important. So there is no need for public documents of the internal structure. Anyway you should never ever access internal ADT structure directly, even if you can, because if you do so then you loose the benefits of abstraction. You create unnesessary dependencies which will make future changes difficult or impossible. Accessing those structures directly was nice in the 80's and early 90's, but not today when ADT and OO is preferred. Unfortunately AmigaOS was designed to be a bit too open.

Last edited by miksuh on 14-Dec-2005 at 10:47 PM.
Last edited by miksuh on 14-Dec-2005 at 10:38 PM.
Last edited by miksuh on 14-Dec-2005 at 09:48 PM.
Last edited by miksuh on 14-Dec-2005 at 09:47 PM.

Hi to all the Naysayers,


AOS: Here yesterday, today, AND tomorrow!!


Have a nice day!

I can see people having a nice technical discussion here, no acting like nay-sayers.

_________________

AMiGR:
And as long as it can be kept this way, i'm really sure we all will benefit from some interesting points.
Everything that tries to push our system further,taking advantage of today's standards is a win-win situation.Yes i know that AmigaOS in its current incarnations and legacy baggage may have some limits, don't forget that it hasn't been in active development since quite some years,but in the meanwhile we are enjoying its growing stage.

_________________
Cuida tus piedras gordas.

A1200/030 32Mb
A4000D
A1-X1000.

I read about it Sounds very interesting and promising They
are really pushing the OS4 even further into perfection!

And Hyperion LOVE teasing us by giving us these facts, in time
for the final release we still don't know about

Hyperion, you guys are freakin' COOL!

@Helgis

Yep, good work again I like the way how OS4 is modernized piece by piece.

Last edited by miksuh on 15-Dec-2005 at 12:14 AM.

@Milush

Thank you Hope i spelled your nick correctly.
If not, then forgive me

@helgis

You didn't But it does not matter

Logic behind my nick is quite simple My firstname is Mika, some of my friends call me as Miksu, and my surname starts with H. So that's why it's miksuh

Last edited by miksuh on 15-Dec-2005 at 12:23 AM.

Hi miksuh,


I use "copy" and "paste" so I got it right.

Quote:

miksuh wrote: Logic behind my nick is quite simple My firstname is Mika, some of my friends call me as Miksu, and my surname starts with H. So that's why it's miksuh

The first and last letters should be capital, then.

MiksuH



Hi AMiGR,

No, no naysaying going on here, but those people, they're looking in, gnashing their teeth, I can hear it.


Hear this....

(micro)AmigaOne! AOS4.0! Ready before it was made!

Okay, doesn't make much sense, so I'll do better next time.

Quote:

A good example is CloseWindowSafely.

Right, that's one of the unfortunate instances where it's necessary. Still, a lot of people DO access system structures even if they don't need to. That isn't limited to message ports. It's all over the place. And _MOST_ of these accesses are completely unnecessary.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

Quote:

A good example is CloseWindowSafely.

Unfortunately, yes... Commodore has always been to easy with internal system structures. Matter of fact is that the Autodocs and RKM are full of bad examples, and full of actually wrong examples (the BOOPSI example code is especially bugged).

At one point these things must change, but introducing a new API for it now is going to be too much of a hassle... Things are bound to change later down the road anyway.

CloseWindowSafely isn't required anymore BTW, that is internally handled by Intuition.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail