26-Apr-2024 02:53 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 228 items in your selection (but only 178 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 228]
[News] OS4 progress since pre-releaseANN.lu
Posted on 08-Jun-2004 21:47 GMT by Peter Gordon228 comments
View flat
View list
Hans-Jorg Frieden has posted a detailed status update on the progress of OS4 to Amigaworld.net. Brief summary:

· Picasso96 and MUI PPC native
· Kernel supports PPC performance monitor and Altivec
· Moovid (released with OS3.9 as "action") is now running native, and can play DivX and other common formats
· GCC 3.4.0 is ported
· The C libraries are much faster. As a result AmiPDF is up to 60 times faster.
· Serial and floppy drivers coming soon
· USB is working and supports HID devices like keyboards and mice as well as HID joysticks and steering wheels, and USB mass storage devices like USB sticks, flash card readers, 7-in-1 card readers and cameras
· A1 IDE device now has working UDMA support. Also, interrupts are no longer polled but delivered properly. This means that the device does not require any CPU time for transfers.

This material will in due course be released for download to registered users of the Developer Pre-release on our web site at: http://www.hyperion-entertainment.biz

There is more detail in the original AW.net posting.
OS4 progress since pre-release : Comment 51 of 228ANN.lu
Posted by Peter Gordon on 09-Jun-2004 11:05 GMT
In reply to Comment 48 (Anonymous):
Yes.
OS4 progress since pre-release : Comment 52 of 228ANN.lu
Posted by Peg2 on 09-Jun-2004 11:10 GMT
In reply to Comment 48 (Anonymous):
If you have the needed headers, yes. If no: what are you want to do without headers? Or how would you imagine the improvements?
Every system needs their own headers. If you cannot accept it, you are blind.

Just complaining about new things doesn't help.
OS4 progress since pre-release : Comment 53 of 228ANN.lu
Posted by Fabio Alemagna on 09-Jun-2004 11:29 GMT
In reply to Comment 50 (Peter Gordon):
> Well, i'm sorry if you see progress as a bad thing.

I don't think that what's being questioned here is "progress", but rather the way some people think progress looks like.

Breaking source compatibility with a so core thing like libraries, well, doesn't seem very smart to me. Better would have been introducing a proper component model, which this interface thing tries to mimik, and implement the old libraries as wrappers around the new components, keeping the ability to implement libraries the old way.
OS4 progress since pre-release : Comment 54 of 228ANN.lu
Posted by Peg2 on 09-Jun-2004 11:37 GMT
In reply to Comment 53 (Fabio Alemagna):
"Breaking source compatibility"

That's not true. See other posts...
OS4 progress since pre-release : Comment 55 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 11:41 GMT
In reply to Comment 50 (Peter Gordon):
Progress is surely no bad thing.... as long as it's not going in the wrong direction like the stuff you demonstrated.
OS4 progress since pre-release : Comment 56 of 228ANN.lu
Posted by drHirudo on 09-Jun-2004 11:44 GMT
In reply to Comment 39 (Kjetil):
Yes, but he have at least one fan who use his nick.
OS4 progress since pre-release : Comment 57 of 228ANN.lu
Posted by Peg2 on 09-Jun-2004 11:47 GMT
In reply to Comment 55 (Anonymous):
It's personal opinion. I think it's good way, you think it's bad way. This disscussion doesn't lead anywhere. Wasn't a good idea to start it. Useless as most of the flames and FUDs...
OS4 progress since pre-release : Comment 58 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 11:47 GMT
What is the benefit of mandatory interfaces? What was insufficient about the traditional way to add new functionality to a library? One could always extend an existing library base with new function vectors, or as a last resort, introduce a library under a new name into the common namespace, when a former attempt was broken. Can we finally give rein to multiple interfaces per library, and a versioning hell like on Windows? Bad library designs aren't exemplary anymore, thanks to the ability to negotiate a (hopyfully) better API later.

Based on the traditional Amiga library interface, any degree of complexity and OO wizardry, even inheritance could have been introduced in a NONE-INTRUSIVE way, that's the complaint. Not the new interface system in itself is necessarily a bad thing, but its foreign ancestry (COM on Windows), its non-evolutionary character, and that it adds another layer of sourcecode incompatibility without sufficient justification. Even with a large number of auto-opened libraries and inline usage, you still need to carry about a whole bunch of new symbols in your code, and manually open libraries and store globals in a different fashion.

It helps to render sources incompatible, and it adds to the #ifdef hell and cruft that has begun with MorphOS. Making oneself distinctive in terms of #ifdefs and annoying case differentiations, that's not progress.

- Oppressor
OS4 progress since pre-release : Comment 59 of 228ANN.lu
Posted by Peter Gordon on 09-Jun-2004 11:47 GMT
In reply to Comment 55 (Anonymous):
Nobody has presented any reason why a flexible library interface system is such a bad thing. Just "its not good". Well, excuse me if i'm not convinced.
OS4 progress since pre-release : Comment 60 of 228ANN.lu
Posted by Peter Gordon on 09-Jun-2004 11:48 GMT
In reply to Comment 53 (Fabio Alemagna):
I have built some of my OS4 programs by adding a few (less than 10) lines to one of the source files. The same source now builds for OS4 and OS3.x.

"Breaks source compatibility"? Hardly.
OS4 progress since pre-release : Comment 61 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 11:55 GMT
In reply to Comment 60 (Peter Gordon):
Fabio can't handle moving targets, OS4 means more work for him ;)
OS4 progress since pre-release : Comment 62 of 228ANN.lu
Posted by Peter Gordon on 09-Jun-2004 11:56 GMT
In reply to Comment 60 (Peter Gordon):
Ooops! "I have built some of my OS4 programs..." is supposed to be OS3 programs.
OS4 progress since pre-release : Comment 63 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 12:01 GMT
In reply to Comment 57 (Peg2):
This is nothing about personal opinion. It's about facts. You can't simply port an OS from one architecture to another architecture and claim API compatibility when you start promoting this type of Interfacing. To provide API compatibility you need to guarantee API compatibility and not start getting 'creative' here. The Amiga community is still big enough and still has a lot of capable developers. You can't simply fuck up an existing and proven API because of your own CASH FLOW interests (Hyperion). You can't simply blow up an entire OS and still sell it as something same to the customers and telling them 'here does the AmigaOS continue' while the resulting OS is everything else than what Amiga makes Amiga. I am a lucky person and was able to play with OS4 as well as MorphOS and was able to play with a lot of sources from both sides (3rd party stuff) and I can tell you that OS4's API haxoring is far to much. If you want to go to something new then I have to agree with Fabio Alemagne here. You should have created something new and wrapped the old Interface correctly and then slowly migrated to something new. The same way MorphOS did this correctly by offering their ABOX and API compatibility and then one day continue with their QBOX which then will be something new but still Amiga from spirit. I am sick of this 'here a bit glue, there a bit glue, there a bit hack' and then call it AmigaOS4 while it has nothing in common with what Amiga was. Using dynamic linked libraries (share libraries) is insane and has nothing in common with Amiga spirit. The Amiga way was and still is shared libraries as we knew it. What OS4 offers now are 3 halfassed ways of dealing with libraries which is a huge mess. Interface API is a mess.

This has nothing to do with blaming OS4 as such, as project, as idea.

I only blame Hyperion for being the wrong people for doing this. And I am quite curious how the future of this OS will look once the first developers start puking. Things like SNAP etc. they have nothing in common with Amiga.
OS4 progress since pre-release : Comment 64 of 228ANN.lu
Posted by Fabio Alemagna on 09-Jun-2004 12:03 GMT
In reply to Comment 54 (Peg2):
> That's not true. See other posts...

Having to manually fiddle with interfaces for libraries that are not automatically opened means breaking source compatibility.

Moreover, if one wanted to port a library to AOS4, there'd be no choice but to use this interface thing, therefore breaking source compatibility in a way that makes it a lot harder to have one common code base for AOS4, MOS and AROS. Mind you, not impossible, just a lot harder.

Also, the interface stuff really useful only when more than one library implements the same interface, as with plugins, but

1) You don't need to hack the compiler and add interfaces support for that</b< purpose, you can simply use macros, as, for example, AROS does.

2) There's not going to be more than one library that implements the Exec interface, and the same goes for intuition, dos, and so on. They are so called "singleton", and interfaces are simply redundant for them.

As said, a true component model would have been a lot better.
OS4 progress since pre-release : Comment 65 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 12:05 GMT
In reply to Comment 58 (Anonymous):
I fully agree with you.
OS4 progress since pre-release : Comment 66 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 12:10 GMT
In reply to Comment 64 (Fabio Alemagna):
Yes Fabio I agree with you. As it looks to me and probably others the OS4 team has entirely alienated the OS from it's users and developers. Betatesters might have been able to raise a voice every now and then but what about the other remaining developers.
OS4 progress since pre-release : Comment 67 of 228ANN.lu
Posted by Fabio Alemagna on 09-Jun-2004 12:10 GMT
In reply to Comment 60 (Peter Gordon):
> I have built some of my OS4 programs by adding a few (less than 10) lines to one
> of the source files. The same source now builds for OS4 and OS3.x.

I can build the same program for AOS3.1, AROS and MOS with a simple -DIPTR=ULONG on the compiler's command line (for AOS). I won't be able to do that with AmigaOS4.

But that's not really the point, Peter... it's the concept that really matters here: there are many ways of achieving a goal, but not all of them are good ones. This is not the good one.
OS4 progress since pre-release : Comment 68 of 228ANN.lu
Posted by Peg2 on 09-Jun-2004 12:17 GMT
In reply to Comment 67 (Fabio Alemagna):
Well, a coder cannot be enough lazy...

In the beginning I've the same opinion as yours, until I've started to use it...
OS4 progress since pre-release : Comment 69 of 228ANN.lu
Posted by Steffen Haeuser on 09-Jun-2004 12:17 GMT
In reply to Comment 43 (Peg2):
>1. RTFM
>2. IFace->OpenWindowTags(...,...,,..);
>to be correct,
>but hey! Look @ this:
>3. #include <inline4/intuition.h>
>OpenWindowTags(...,...,...);

Bad code. It won't work only to include the inline4. Also you should
NEVER NEVER NEVER use compiler-specific includes (like inline4 for OS4,
or pragmas for SAS/C or inline/ for gcc on OS 3.x).

Do it like this and it is fine (setting __USE_INLINE__ in the Makefile):

#include <proto/intuition.h>

...

OpenWindowTags(...

and it will work everywhere.

BTW: Library-Auto-Init for most libs can be done by linking with
-lauto, then you do not have to care about GetInterface/DropInterface.

Actually the library generation tool automatically generates source-code
for such a "auto-open-library". You could then generat a libmylibsauto.a
for example...

Hmmm, seems the MOS-crowd gets desperate, judging recent comments :)

Steffen
OS4 progress since pre-release : Comment 70 of 228ANN.lu
Posted by Fabio Alemagna on 09-Jun-2004 12:23 GMT
In reply to Comment 68 (Peg2):
> In the beginning I've the same opinion as yours, until I've started to use it...

It's not about being lazy, it's about a couple of other things, one of which is of purely practical implications, and the other is more philosophical and concerning the "beauty" of a solution in respect of another one (where "beauty" really refers to the set of things that concern whether the API is orthogonal or not, whether it's lungimirant or not, whether it seamlessy fits with the rest or not, and other such things).
OS4 progress since pre-release : Comment 71 of 228ANN.lu
Posted by Nicolas Sallin on 09-Jun-2004 12:32 GMT
In reply to Comment 37 (Ben Hermans):
cgxvirgin.library offered 3D hardware acceleration first.

Try again.
OS4 progress since pre-release : Comment 72 of 228ANN.lu
Posted by Peg2 on 09-Jun-2004 12:41 GMT
In reply to Comment 63 (Anonymous):
" I only blame Hyperion for being the wrong people for doing this. "

As I said: it's personal. You are blaming Hyperion and I'm not. IMHO Firedens are one of the best persons to improve AmigaOS.
Nobody will change his opinion because of your PR work. So what is it good for? Why don't you sit back and relax?

This leads nowhere else, just flaming, mud throwing and so on...
OS4 progress since pre-release : Comment 73 of 228ANN.lu
Posted by Thomas Würgler/Pagan on 09-Jun-2004 12:47 GMT
In reply to Comment 34 (Don Cox):
I would have mailed you a link, but obviously you know I can't do that. So now it's your turn to write me ;)
OS4 progress since pre-release : Comment 74 of 228ANN.lu
Posted by RiVA Author on 09-Jun-2004 13:06 GMT
In reply to Comment 70 (Fabio Alemagna):
"concerning the "beauty" of a solution in respect of another one (where "beauty" really refers to the set of things that concern whether the API is orthogonal or not, whether it's lungimirant or not, whether it seamlessy fits with the rest or not, and other such things)."

Blaming a new solution because it's different from an old solution doesn't justify anyone to say that it's a bad solution.

We shouldn't put up with the limitations of the old library system, just because it makes it easier to port old software. And porting old software is easy enough anyway, as Steffen wrote, just define __USE_INLINE__ and use libauto and compile. No need to change anything. This isn't much price to pay for the advantages of the new system.
OS4 progress since pre-release : Comment 75 of 228ANN.lu
Posted by Fabio Alemagna on 09-Jun-2004 13:14 GMT
In reply to Comment 74 (RiVA Author):
> Blaming a new solution because it's different from an old solution doesn't
> justify anyone to say that it's a bad solution.

And how did you draw the conclusion that I'm blaming this new solution simply because it's new? I've rather made lots of points which no one, including you, has yet counterargumented, and the point you claim I've made, well, it's unexistent. I've simply never claimed that.

> We shouldn't put up with the limitations of the old library system, just
> because it makes it easier to port old software. And porting old software is
> easy enough anyway, as Steffen wrote, just define __USE_INLINE__ and use
> libauto and compile. No need to change anything. This isn't much price to pay
> for the advantages of the new system.

Perhaps you could read my previous posts, to get a reply to those your points. Won't repeat myself.
OS4 progress since pre-release : Comment 76 of 228ANN.lu
Posted by RiVA Author on 09-Jun-2004 13:29 GMT
In reply to Comment 75 (Fabio Alemagna):
"And how did you draw the conclusion that I'm blaming this new solution simply because it's new?"

You were just explaining that this new library system doesn't fit well with the other systems (here, I guess you were talking about AOS3.x and MOS). So your point was that it's different from the others.

"Perhaps you could read my previous posts, to get a reply to those your points."

I did. You kept going on about breaking source compatibility, having to fiddle with interfaces manually, etc. and I hope you've now understood that this is not the case.
OS4 progress since pre-release : Comment 77 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 13:37 GMT
In reply to Comment 76 (RiVA Author):
I see, you never dealt with serious programming otherwise you might have heard the terminology 'API' and 'ABI' somewhere. Some of us developers don't want "creative" stuff, some of us want a working System. Something to get work done. I don't plan to port my OS3.x program to OS4.x. This has nothing to do with not possible to port it, no it has something to do with sane porting. Now to port my program in a sane way from OS3.x to OS4.x (which of course includes native architecture and native proposed API) then I'd better throw my program into trash and start from scratch because the changes required would be immense. This doesn't mean that I don't need to change some parts in my code when I want to port it to MorphOS or AROS but the amount required to get the program ported correctly with the proposed correct API is less of work than I need for OS4.
OS4 progress since pre-release : Comment 78 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 13:40 GMT
In reply to Comment 11 (Anonymous):
What colour pils did you take ? There is no court case about OS4 and never was. There was Genesi vs Amigainc court case, but that has nothing to do with AmigaOS4. And AmigaInc has nothing to with OS4 anymore.
OS4 progress since pre-release : Comment 79 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 13:42 GMT
In reply to Comment 12 (Anonymous):
Native MUI for OS4 will be version 3.9, not 3.8. 3.8 is for the m68k only.
OS4 progress since pre-release : Comment 80 of 228ANN.lu
Posted by Peter Gordon on 09-Jun-2004 13:42 GMT
In reply to Comment 77 (Anonymous):
"then I'd better throw my program into trash and start from scratch because the changes required would be immense."

Absolutely not true, unless you used an "immense" amount of SAS/C (or other) specific things on every line of your code.
OS4 progress since pre-release : Comment 81 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 13:44 GMT
In reply to Comment 14 (the man in the shadows):
That would be great. And that would show that people can still co-operate.
OS4 progress since pre-release : Comment 82 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 13:45 GMT
In reply to Comment 17 (Jupp3):
No. AFAIK there is no AROS version, that's why AROS has it's own MUI-clone called Zune.
OS4 progress since pre-release : Comment 83 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 13:46 GMT
In reply to Comment 21 (Anonymous):
Yeah me too. i like cats more than any #?dogs :)
OS4 progress since pre-release : Comment 84 of 228ANN.lu
Posted by Fabio Alemagna on 09-Jun-2004 13:47 GMT
In reply to Comment 76 (RiVA Author):
> You were just explaining that this new library system doesn't fit well with
> the other systems (here, I guess you were talking about AOS3.x and MOS). So
> your point was that it's different from the others.

Is that the sole point I've made? Don't think so.

I've made, more or less, the following points:

1) Redundancy issues, coming from using the interface for things that are singletons

2) Inability to write new libraries the "old way", which means that it's a lot harder to mantain an unique code base for all Amiga-like OSs around. And before someone tells me this is not of Hyperion's concern, let me tell you that the easier is to port a program to all the aforementioned OSs, the likely a program will be developed for AOS4 at all, since in the narrow market we're in even 10 customers more make a difference.

3) The "hackish" feeling of this "new way". Although I admit this is more of a personal consideration, it can't be argued that there are cleaner solutions to do what Hyperion has done. A true component model would have been way better, and wouldn't have broken compatibility.

> I did. You kept going on about breaking source compatibility, having to fiddle
> with interfaces manually, etc. and I hope you've now understood that this is
> not the case.

That's not the only thing I've said, I've also said that autoopening of libraries can be done only for so many libraries, certainly not for all libraries that are around. Also, it's not entirely clear to me whether it's possible to use 68k libraries from PPC programs seamlessy (I sincerely hope so). I also said that this was a minor point, among all the other ones.
OS4 progress since pre-release : Comment 85 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 13:52 GMT
In reply to Comment 32 (Anonymous):
Where did you get idea of *.lo or ld.so libraries in OS4 ? I have not seen any talk about that. There is new library API, but that does not mean as dramatic change as to start use unix style libraries.
OS4 progress since pre-release : Comment 86 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 13:54 GMT
In reply to Comment 80 (Peter Gordon):
Why not true ?

How do you feel if you need to change a couple of thousand FooBar(); to IFace->FooBar();

Please understand, this is *not* the question of how you can bypass it by using a different compile mode such as -D_INLINE_ or something or let the App run under the OS3.x emulation. It's a matter of sane programming, that is close the chapter of OS3.x and continue with OS4.x and new architecture. This means that if someone starts porting the app that the correct recommended and proposed API and mechanism are used and no halfassed solution.
OS4 progress since pre-release : Comment 87 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 13:57 GMT
In reply to Comment 85 (Anonymous):
An OS4 Betatester + Developer (also on your internal Developers list) told me. But regardles of that I heard this from various other resources too.
OS4 progress since pre-release : Comment 88 of 228ANN.lu
Posted by Leif on 09-Jun-2004 13:57 GMT
Question for OS4 devs:

Is it still possible to have own rt_init routine in libraries ?
Is it possible to allocate own librarybase in Open() and return
to application ? (multibase libraries)
OS4 progress since pre-release : Comment 89 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 13:59 GMT
In reply to Comment 33 (Anonymous):
Current AmigaOS library API is about 20 yesra old. Sure it works but it has severe restrictions. I'm wery happy that Hyperion created new library API for the OS4, because I have noticed that I simply can't port some stuff to OS3.x, because it's library API does not support some more modern features. If i have understood it right I could port that same stuff to OS4 quite easily.

So if we get better library API, then I really don't care if OS4 library API is not same as in OS3.x. And oldstyle m68k librarues will still work anyway.
OS4 progress since pre-release : Comment 90 of 228ANN.lu
Posted by Leif on 09-Jun-2004 14:01 GMT
In reply to Comment 89 (Anonymous):
Current AmigaOS library API is about 20 yesra old. Sure it works but it has severe restrictions. I'm wery happy that Hyperion created new library API for the OS4, because I have noticed that I simply can't port some stuff to OS3.x, because it's library API does not support some more modern features. If i have understood it right I could port that same stuff to OS4 quite easily.
->-----------------------------------

What features are we talking about ?
OS4 progress since pre-release : Comment 91 of 228ANN.lu
Posted by Peter Gordon on 09-Jun-2004 14:01 GMT
In reply to Comment 86 (Anonymous):
> Why not true ?

Because its not, and if you had any idea what you were talking about, you'd know its not.


> How do you feel if you need to change a couple of thousand FooBar(); to
> IFace->FooBar();

But you don't have to do change a single FooBar() call. Not one.


> Please understand, this is *not* the question of how you can bypass it by
> using a different compile mode such as -D_INLINE_ or something or let the
> App run under the OS3.x emulation.

What? You're just setting one define. Your program compiles, you don't have to change the library calls, and you end up with a fully functional native program. There is nothing wrong, or insane with this.


> porting the app that the correct recommended and proposed API and mechanism
> are used and no halfassed solution.

Its not a "halfassed" solution. Its a real, working, functional, defined, actual solution, and you are just talking nonsense.
OS4 progress since pre-release : Comment 92 of 228ANN.lu
Posted by Peter Gordon on 09-Jun-2004 14:03 GMT
In reply to Comment 87 (Anonymous):
The Friedens have written a method of using dlopen() to open .so libraries. It is not a part of OS4, it doesn't come with OS4, it is not standard, and it has nothing to do with OS4s shared library model.
OS4 progress since pre-release : Comment 93 of 228ANN.lu
Posted by Nicolas Sallin on 09-Jun-2004 14:09 GMT
In reply to Comment 92 (Peter Gordon):
I think he was talking about the external stubs needed to call 68k libraries from PPC code.
That was announced a very long time ago. Hyperion first talked about installing .fd files on users's disc, even...
OS4 progress since pre-release : Comment 94 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 14:14 GMT
In reply to Comment 77 (Anonymous):
You didn't even read what steffen and others said. If you still try to say that you have to make big changes if you want to port OS3.x application to OS4, then you can'ät read or you ignore those explanations by purpose. because what you say really is not true.
OS4 progress since pre-release : Comment 95 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 14:16 GMT
In reply to Comment 86 (Anonymous):
"How do you feel if you need to change a couple of thousand FooBar(); to IFace->FooBar(); "

It was already explained that you don't need to if you want to use old style.
How is it so hard to understand ?
OS4 progress since pre-release : Comment 96 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 14:17 GMT
In reply to Comment 87 (Anonymous):
Various other resources ? like #morphos or ANN ? hah
OS4 progress since pre-release : Comment 97 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 14:18 GMT
In reply to Comment 94 (Anonymous):
But I did read what others wrote. The majority of them simply say that the OS4 approach sucks which I agree with.
OS4 progress since pre-release : Comment 98 of 228ANN.lu
Posted by Anonymous on 09-Jun-2004 14:20 GMT
In reply to Comment 95 (Anonymous):
Yes but you don't get my point here.

> OLD STYLE!!!!

That's probably not the proposed and correct way to port an application to a new architecture and operating system. Using the 'old style' is just one way to port it and I believe you if you say that can be done. The question is whether the old style is the correct style if you want to be compatible with future expansions and improvements. I don't want to port the application 'old style' I want to port it in the correct proposed way which is *not* 'old style'.
OS4 progress since pre-release : Comment 99 of 228ANN.lu
Posted by Steffen Haeuser on 09-Jun-2004 14:23 GMT
In reply to Comment 84 (Fabio Alemagna):
>3) The "hackish" feeling of this "new way". Although I admit this is more of a >personal consideration, it can't be argued that there are cleaner solutions to do >what Hyperion has done. A true component model would have been way better, and >wouldn't have broken compatibility.

Well, to me it looks even less hacky than the old one. And the tools can generate me everything (includes,...) for a library automatically (if I'd liked to do a library with gcc under 3.x it would have been much harder). I can even pre-generate an "empty" library core for a library I want to port from OS 3.x to OS 4, so I "only" have to fill in the functionality then. That makes ports a lot easier.

>to use 68k libraries from PPC programs seamlessy (I sincerely hope so). I also >said that this was a minor point, among all the other ones.

Sure you can use 68k libraries from PPC programs seamlessy.



Steffen
OS4 progress since pre-release : Comment 100 of 228ANN.lu
Posted by Chip on 09-Jun-2004 14:24 GMT
In reply to Comment 77 (Anonymous):
"I see, you never dealt with serious programming "

I see, you never know who you are talking about... pity... Just like the jelious MOS+AROS developers fight against new API design.
Anonymous, there are 228 items in your selection (but only 178 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 228]
Back to Top