26-Apr-2024 11:31 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 146 items in your selection (but only 96 shown due to limitation) [1 - 50] [51 - 100] [101 - 146]
[Web] Newly released CAM article on OS 4ANN.lu
Posted on 09-Aug-2003 09:30 GMT by Christian Kemp (Edited on 2003-08-09 11:35:17 GMT by Christian Kemp)146 comments
View flat
View list
SimplePPC submitted news about a newly released CAM article on OS 4, where "AmigaOS 4's powerful shared library concept [is] explained by Hans-Joerg Frieden of Hyperion Entertainment."
Newly released CAM article on OS 4 : Comment 51 of 146ANN.lu
Posted by Hans-Joerg Frieden on 10-Aug-2003 17:08 GMT
In reply to Comment 40 (Don Cox):
> That's the point at which I stop buying updates. If my programs don't work any
> more, I may as well go over to Mac. A better aim would be to try to increase the
> number of Amiga programs that work.

There are no plans to remove the 68k part any time soon, don't worry :-)
Newly released CAM article on OS 4 : Comment 52 of 146ANN.lu
Posted by Hans-Joerg Frieden on 10-Aug-2003 17:18 GMT
In reply to Comment 42 (Joe "Floid" Kanowitz):
> If you sandbox everything in an emulation, of course it works, but it's
> just an emulation...

Exactly. The point being, we didn't want to give the impression that there is old and new. Granted, 68k programs will be slower and don't benefit from the added API's, but they do look and feel exactly like the new programs (the look/visual consistancy was an important point).

It goes so far that is allows you to write PowerPC plugins for a 68k program (I should really do an ArtEffects plugin just to show this is possible), making gradual migration of 68k to PowerPC even more likely.

> Throwing the child out with the bathwater can sometimes seem equally elegant
> (OS/2 was fun to use, some people like OS X), but it wouldn't make sense for
> OS4.

No, it wouldn't. There are too many useful programs out there. One of the reason for sticking with the Amiga is that these "old" programs still work and do the job.
Newly released CAM article on OS 4 : Comment 53 of 146ANN.lu
Posted by Hans-Joerg Frieden on 10-Aug-2003 17:23 GMT
In reply to Comment 49 (Anonymous):
> Is that actually true RIGHT NOW, or is it something still to be finally
> integrated?

I'm not sure what you mean? We didn't implement the swapper task yet - it's not a priority right now - but FinalWriter works flawlessly. The mechanics are already there (tasks are frozen upon a page fault, with illegal page access being punished by death).
Newly released CAM article on OS 4 : Comment 54 of 146ANN.lu
Posted by Anonymous on 10-Aug-2003 17:23 GMT
In reply to Comment 13 (Don Cox):
>If it has the functions that somebody wants, why change it?

HUH? You're telling me that no software should be updated because there's always someone who likes things the way they are? If what you're saying it's true we would all be living like the Amish, or worse, using Windows 3.1
Newly released CAM article on OS 4 : Comment 55 of 146ANN.lu
Posted by Amon_Re on 10-Aug-2003 17:26 GMT
In reply to Comment 54 (Anonymous):
ROTFL! Now that's a good line :)

"If what you're saying it's true we would all be living like the Amish, or worse, using Windows 3.1"... Needed a good laugh :)

Cheers
Newly released CAM article on OS 4 : Comment 56 of 146ANN.lu
Posted by Anonymous on 10-Aug-2003 17:32 GMT
In reply to Comment 20 (Ben Hermans/Hyperion):
I think is immature and arrogant to give an answer like your. If he's completely wrong why don't you explain the reason in a nice and friendly manner instead? I think his reasoning was polite after all.

And before I get labeled as a blue camp troll, I'm a boing ball troll ;-)
Newly released CAM article on OS 4 : Comment 57 of 146ANN.lu
Posted by Jonny Johansson on 10-Aug-2003 18:05 GMT
In reply to Comment 39 (Don Cox):
Don Cox wrote:

>Well you said "Oh, how does the GUI work for this one and what is the output >like?" so I told you. I assumed you wanted an answer to your question.

Ow! Guess I didn't come across the right way. Please ignore any percieved
negativity in what I wrote.

You do have a way of going beyond the call of duty. -Does that sound better? :7
Newly released CAM article on OS 4 : Comment 58 of 146ANN.lu
Posted by KenH on 10-Aug-2003 18:37 GMT
In reply to Comment 56 (Anonymous):
Yes it does appear to be abrupt on paper (Some people do have that style, but don't mean to insult). A smiley wouldn't go amiss. Maybe he didn't understand it enough to explain it :)


>I think is immature and arrogant to give an answer like your. If he's completely wrong why don't you explain the reason in a nice and friendly manner instead? I think his reasoning was polite after all.
Newly released CAM article on OS 4 : Comment 59 of 146ANN.lu
Posted by Johan Rönnblom on 10-Aug-2003 19:44 GMT
In reply to Comment 38 (Hans-Joerg Frieden):
Hans-Jörg Frieden wrote:
> There is a distinct line in AmigaOS 4's design, where the part on
> one side of the line is 68k/legacy and the other part is PowerPC/New
> stuff.

Sounds a lot like a "box" approach imo. No need to start another
useless argument, but if someone could explain why it would be
inappropriate to think of one side of this very distinct line as one
"box" and the other side as another "box", I'd be interested in
hearing.
Newly released CAM article on OS 4 : Comment 60 of 146ANN.lu
Posted by Kjetil on 10-Aug-2003 20:32 GMT
In reply to Comment 59 (Johan Rönnblom):
Basically when you referring to box your are thinking about some thing boxed inn,

good example boxes are:

1) MSDOS emulation in windows3.1, it don't know allot about the rest of the OS,
2) Shapeshifer
3) MacOnLinux
4) Java

Good examples for task based emulation,

1) Wine (you can debate this one tow if you will)

A Box emulation should have it how task scheduler and it should emulate some kind of environment, API emulation, memory address emulation.

1st of all it do not have a separate task scheduler

2en it has no API emulation layer, it has a API legacy layer that is really not the same as long as there is no translation involved between JMP_TABELL (old) and library function it's not a emulation.

3rd it not typical to revolve new library's and memory address and OS resource with in a BOX concept.

the only thing that aliens with box concept is that it run's in it's own memory area and that is not really true eater when it makes heavy use of replacement PPC library's and resources.
Newly released CAM article on OS 4 : Comment 61 of 146ANN.lu
Posted by Kjetil on 10-Aug-2003 20:35 GMT
In reply to Comment 60 (Kjetil):
<READ THIS ONE FOUND SOME SPELLING ERROR A BIT TO LATE>

Basically when you referring to box your are thinking about some thing boxed inn,

good example boxes are:

1) MSDOS emulation in windows3.1, it don't know allot about the rest of the OS,
2) Shapeshifer
3) MacOnLinux
4) Java

Good examples for task based emulation,

1) Wine (you can debate this one tow if you will)

A Box emulation should have it's own task scheduler and it should emulate some kind of environment, API emulation, memory address emulation.

1st of all it do not have a separate task scheduler

2en it has no API emulation layer, it has a API legacy layer that is really not the same as long as there is no translation involved between JMP_TABELL (old) and library function it's not a emulation.

3rd it not typical to revile new library's and memory address and OS resource with in a BOX concept.

the only thing that aliens with box concept is that it run's in it's own memory area and that is not really true eater when it makes heavy use of replacement PPC library's and resources.
Newly released CAM article on OS 4 : Comment 62 of 146ANN.lu
Posted by EyeAm on 10-Aug-2003 21:07 GMT
In reply to Comment 37 (Joe "Floid" Kanowitz):
>Oh, and for EyeAm... You're aware that that's basically the approach DragonFly >hopes to take, right? Wonder how ridiculous it would be to apply a PEACE-like
>(http://chiharu.haun.org/peace/) API layer and appropriate emu-libs (Reaction >or MUI -> Qt/GTK/???) when that project's ready. :)

I vaguely recall DragonFly, and have briefly researched other OSes, including PEACE. I believe any idea deemed useful or facilitating an elegant simplicity or ease-of-use many are accustomed to desiring should be overlooked or abandoned because another has the same idea. Otherwise: AROS wouldn't exist because Amiga already did; MorphOS wouldn't because Amiga did; AmigaForever wouldn't because UAE did; or Microsoft wouldn't because everyone else did. ;-)

>[Very, of course, but one of the objectives is to make such things easier, >even if only as a side effect of 'cleaning' up the overall kernel design. >Cripes, I can't wait until it's finished enough for a luser like me to benefit >from it... They even have Billsey types showing up and thanking them for >losing the daemon iconography, promising to evangelize it to all the >institutions who snubbed other BSDs over such concerns!]

Hmm... I should add a devil to my OS project, somewhere >;-)

>It's a strange, strange planet, and I've had too much coffee again.

Sometimes strange is good. Rob Halford is back with Judas Priest after about ten years :D Rock on!

--EyeAm
http://eyeam.darrelltown.com
Newly released CAM article on OS 4 : Comment 63 of 146ANN.lu
Posted by EyeAm on 10-Aug-2003 21:09 GMT
In reply to Comment 62 (EyeAm):
Oops... "I believe any idea deemed useful or facilitating an elegant simplicity or ease-of-use many are accustomed to desiring should be overlooked or abandoned because another has the same idea." should read "should NOT be overlooked" :)
Newly released CAM article on OS 4 : Comment 64 of 146ANN.lu
Posted by Megol on 10-Aug-2003 21:10 GMT
In reply to Comment 48 (Raffaele):
Why argue who copies who? This "copying" is what drives the technical evolution imnsho...

"MS copied IBM OS2 structure (kicking in the ass their old IBM partners) to obtain a real multitasking into WIN 95 and its sequel...
(You know it. They partecipate the developing of OS2 only to achieve as many know-how they can)"
Microsoft _developed_ the basic structure, the kernel and the user interface for the early OS/2 versions. IBM have mostly developed drivers and the later versions of the GUI (in reality they bought the GUI technology from another firm). If you think that OS/2 was good you really should thank Microsoft and not IBM. BTW the Windows 9x series have a completly different design than OS/2...

"M$ copied also some amigaish structures..."
What would those "structures" be? I have a pretty good idea how both the AmigaOS and Windows 9x/Windows NT are designed (even though I don't have detail knowledge) and can't think of anything... But as usual both the developers
Newly released CAM article on OS 4 : Comment 65 of 146ANN.lu
Posted by Raffaele on 11-Aug-2003 01:20 GMT
In reply to Comment 64 (Megol):
Mr. Megol made a question upon a statement of mine:

>"M$ copied also some amigaish structures..."
>What would those "structures" be?
>I have a pretty good idea how both the AmigaOS
>and Windows 9x/Windows NT are designed
>(even though I don't have detail knowledge)
>and can't think of anything...
>But as usual both the developers
1)
GDI (Graphics Device Interface) system of Win sounded to me an Amigaish way to let graphical structures to be managed.
An impression??? Maybe!
(And maybe some more talented programmers here or expert could confirm/deny my assumption)

2)
The fact that M$ had buyed in the past "Bars&Pipes Pro" program to copy its structure of managing sound and put it into DirectX system is another success of M$ to pick up technologies from other platforms and embrace it into their...

3)
And also I have a strong suspect (but I have not so deep know-how into IT to prove it) that event-driven system of Win95 is nearby to Amiga Intuition more than Mac Finder (which was instead the interface structure M$ programmers had in their mind when they realized Windows 3.0/3.1)

If I was wrong with my statements then please correct me, I am open to any enlightenments &/or any corrections to what I said...

Ciao,

Raffaele
Newly released CAM article on OS 4 : Comment 66 of 146ANN.lu
Posted by Raffaele on 11-Aug-2003 01:33 GMT
In reply to Comment 65 (Raffaele):
Pardon...

>had buyed = bought

I made a mistake by thinking in my language grammatics...
Newly released CAM article on OS 4 : Comment 67 of 146ANN.lu
Posted by Alkis Tsapanidis on 11-Aug-2003 03:47 GMT
In reply to Comment 60 (Kjetil):
And you just admitted that MorphOS has a Box concept and not a task based emulation... It really depends on what you mean with task based though.
That other thread was very annoying...
Newly released CAM article on OS 4 : Comment 68 of 146ANN.lu
Posted by Hans-Joerg Frieden on 11-Aug-2003 04:42 GMT
In reply to Comment 59 (Johan Rönnblom):
> Sounds a lot like a "box" approach imo.

No. A box approach would mean that there is a complete Amiga running on the other side of the line. This is not the case. There is only so much that a 68k program can run. It's running on the same scheduler, using the same resources.
Newly released CAM article on OS 4 : Comment 69 of 146ANN.lu
Posted by Treke on 11-Aug-2003 06:09 GMT
HJF:
The ExecSG is itself a Marvelous achievement. Who was involved in the design ?
Just currious ;)

Personally, I don't know the internals, but Exec seems to me a bit big mass in one library (even when the functionality is nicely divided with different interfaces).
In the old times ( Sassenrath & co ... like design ) the memory protection was intended to place in the Dos.library, exec was intended just for task rescheduling, and so on...

It just seems to me, that the granularity is slightly big for an amiga system.
Or, Im just plainly wrog. Hmm, it is possible to divide exec to more modules ?
From the functionality points for sure. But maybe there are some hard dependencies as you mentioned earlier ?

re

Treke
Newly released CAM article on OS 4 : Comment 70 of 146ANN.lu
Posted by Ben Hermans/Hyperion on 11-Aug-2003 06:43 GMT
In reply to Comment 69 (Treke):
There are already subsystems in ExecSG.

The HAL for instance, the memory system or even the scheduler.

The thing is that you need all of that functionality available on start-up of the system.
Newly released CAM article on OS 4 : Comment 71 of 146ANN.lu
Posted by Kjetil on 11-Aug-2003 09:17 GMT
In reply to Comment 69 (Treke):
The old design off exec.library
Contained

Tings like enable/disable multitasking
Memory allocation,
Open/Close library’s,
Open/Close devices

The Kickstart it self contains several library’s to work,

exec.library:

The main library contains task handling / memory handling / resource handling / signalling / and exec communication, exec.library is the most important library in the AmigaOS, it is a start up library the first library to be accessed by any program, the task scheduling it self is controlled by some executive sub calls, interrupts and not directly by the exec.library

Dos.library

Controls reading and writing to file systems, and it interface whit the scsi.device, trackdisk.device etc, dos library is all sow response boll for execution of programs.

Graphic.library

Responsibility for gfx tuff.

--------
You can think of library’s as cocking books, it has index register that points to different articles in the book with different recipes for doing different things.
Newly released CAM article on OS 4 : Comment 72 of 146ANN.lu
Posted by Treke on 11-Aug-2003 09:50 GMT
BenH, Kjetil: Thanx.

I'm just speculating, because I guess, I've read articles (not so sure) that in original design of the dos.library (not that from metacomco) had to handle also the processes structures as well and so on ...

My speculation was just to divide the different functionality into separate libraries. Because if you will not need the code in the future, you just not start that library.
Dividing exec to smaller libs like: execmain.library, execemul.library, executility.library and then writing a small 'startup.library' which is started instead of exec and then starts execmmu.library, execmain.library, etc ... should not be a problem.
With this you minimise the changes, when old code is not needed in the next versions of the operating system. Now you need to load the whole exec event if you don't need the code inside. (for example when petunia makes it in more compatible stage and interpretive emulation can be skipped, you need to make changes in exec ...)

Small speculations ;)

But if you say, it is needed, then it is needed ;)))

re

Treke
Newly released CAM article on OS 4 : Comment 73 of 146ANN.lu
Posted by Kjetil on 11-Aug-2003 10:11 GMT
In reply to Comment 72 (Treke):
When I talked about multi headed library’s I’m saying that library has tow set of index’s on index for Arabic and one for Greek, while the content of the pages is written in English, sins bout Arabic and Greek people can understand English they do not need to have separate versions of the books, (I know it’s a bad example), having one single library for bout 68k and PPC that is what is separate it form a box design, and no you can not divide library’s as the function expect the find the articles in the right place this is way you have the dual headed library. Just image ripping out the sport section of New York Post, I bet there be a lot of confused American football fans.
Newly released CAM article on OS 4 : Comment 74 of 146ANN.lu
Posted by Johan Rönnblom on 11-Aug-2003 10:22 GMT
In reply to Comment 68 (Hans-Joerg Frieden):
Hans Jörg Frieden wrote:
> A box approach would mean that there is a complete Amiga running
> on the other side of the line. This is not the case. There is only
> so much that a 68k program can run. It's running on the same
> scheduler, using the same resources.

Ok. So if someone else implemented a solution which did not have a
complete system running on one side of the "line", and where the same
scheduler and the same resources were used for both emulated and
native tasks, then you would not agree with their terminology if they
called it a boxed emulation?
Newly released CAM article on OS 4 : Comment 75 of 146ANN.lu
Posted by priest on 11-Aug-2003 10:30 GMT
In reply to Comment 74 (Johan Rönnblom):
"So if someone else implemented a solution which did not have a
complete system running on one side of the "line", and where the same
scheduler and the same resources were used for both emulated and
native tasks"

btw. does there exist such solution?

"then you would not agree with their terminology if they
called it a boxed emulation?"

my 0.2 cents: I know one other solution where native apps run in the same "box" as the emulated ones... that definitely does not sound too "boxed" to me. ;-)
Newly released CAM article on OS 4 : Comment 76 of 146ANN.lu
Posted by Ben Hermans/Hyperion on 11-Aug-2003 10:37 GMT
In reply to Comment 74 (Johan Rönnblom):
No offense but this whole box business started because that is the terminology that the MorphOS development team used for years.

A/Box, Q/Box etc.
Newly released CAM article on OS 4 : Comment 77 of 146ANN.lu
Posted by Anonymous on 11-Aug-2003 10:47 GMT
In reply to Comment 53 (Hans-Joerg Frieden):
>The mechanics are already there (tasks are frozen upon a page fault, with illegal page access being punished by death).

Is that going to make things better, I wonder? Many illegal page accesses are completely harmless and/or have no immediate consequence. If all those tasks are just killed, users will loose a lot of data. I prefer to have a choice if I want to continue with FinalWriter and safe my important document rather than being told that some irrelevant part if it just read from byte 0 and I have to say bye bye to it.
Newly released CAM article on OS 4 : Comment 78 of 146ANN.lu
Posted by Anonymous on 11-Aug-2003 10:51 GMT
In reply to Comment 72 (Treke):
>My speculation was just to divide the different functionality into separate libraries. Because if you will not need the code in the future, you just not start that library.

Good point.
Newly released CAM article on OS 4 : Comment 79 of 146ANN.lu
Posted by DaveP on 11-Aug-2003 12:03 GMT
In reply to Comment 77 (Anonymous):
> Is that going to make things better, I wonder? Many illegal page accesses are completely harmless and/or have no immediate consequence.

Beyond using address 0 what are you thinking about?

> If all those tasks are just killed, users will loose a lot of data.

Rogue tasks can destroy data from other applications. I would prefer strict memory access.

> I prefer to have a choice if I want to continue with FinalWriter and safe my important document rather than being told that some irrelevant part if it just read from byte 0 and I have to say bye bye to it.

I would suggest that address 0 (NULL pointer) is a special case.Normally the data at address 0 is not read anyway, but the value of the NULL pointer is read. The problem is once an application has accessed an area of memory that it does not own and is not authorised for, its going to have unpredictable effects so allowing it to continue could make the situation worse and even impact the stability of the operating system.

The best answer is to kill unstable programs for users, let unstable programs be trapped and debugged for the developer/tester purpose, and stable programs that are well written will not cause the exceptional condition in the first place right?
Newly released CAM article on OS 4 : Comment 80 of 146ANN.lu
Posted by Senex on 11-Aug-2003 12:04 GMT
In reply to Comment 53 (Hans-Joerg Frieden):
> but FinalWriter works flawlessly.

If this will still be the case on a pure PPC-mainboard and if MOS then will still not be able to run FW 100% flawlessly, you should make an OS4-version for Pegasos as well, since already this feature alone would make me buying your OS (additionally to MOS, of course).
Newly released CAM article on OS 4 : Comment 81 of 146ANN.lu
Posted by Anonymous on 11-Aug-2003 12:13 GMT
In reply to Comment 79 (DaveP):
> Beyond using address 0 what are you thinking about?

Countless minor errors, don't know where to start. If you have 512 MB RAM, the chance that writing anywhere (let alone reading anywhere, e.g. from previously allocated but now released memory) will take down the computer immediately is miniscule. It's good to be notified to push developers towards better source code but shutting such applications down and loosing all their data is like shooting shoplifters.
Newly released CAM article on OS 4 : Comment 82 of 146ANN.lu
Posted by Ben Hermans/Hyperion on 11-Aug-2003 12:36 GMT
In reply to Comment 77 (Anonymous):
Reading address 0 won't result in termination, we consider that a special case.

Other than that, programs which start poking around outside their allocated memory space will fail.

These programs should be considered broken.
Newly released CAM article on OS 4 : Comment 83 of 146ANN.lu
Posted by DaveP on 11-Aug-2003 13:09 GMT
In reply to Comment 81 (Anonymous):
"the chance that writing anywhere (let alone reading anywhere, e.g. from previously allocated but now released memory) will take down the computer immediately is miniscule."

Im sorry but a computer that is under stress will contain many allocated areas of memory, generally fragmented around the address space. An application that uses or writes to random areas of memory can do serious damage and is as Ben sayes broken. Its not just a minor error, its a rogue task and whilst a minor bug if this the only app running ( although you then have to think about OS tasks, memory used by devices and memory used by resident functions ) the effects might be minimal the problem comes when someone runs Voyager which say writes memory which is actually used by Exec and bang! Bye system! Or by say AmigaWriter - bang! Someone reports a bug in AmigaWriter.

I think the proportion of apps that contain this kind of flaw is likely to be tiny, very tiny and those that do need to be exposed to the user as the problem applications they are. :-)
Newly released CAM article on OS 4 : Comment 84 of 146ANN.lu
Posted by Anonymous on 11-Aug-2003 13:11 GMT
In reply to Comment 82 (Ben Hermans/Hyperion):
>Other than that, programs which start poking around outside their allocated memory space will fail. These programs should be considered broken.

I guess "fail" means "be terminated"? In that case I stand by my comment that a lot of people will be very annoyed with OS4. If not, please clarify. It's one thing to discuss ideal software on ann. You are right, software with such errors is faulty. But you will feel very different when you have worked two hours on a Pagestream document and then it's killed right under your mouse pointer because of an error that, statistically, might have done no or no immediate harm on AmigaOS3.

Also, please take into account that pointing out errors to programmers by killing their software is pointless if said programmers are no longer around (in other words, I don't by the kill-to-have-better-software-in-the-long-term argument).

Personally, I would feel very nervous knowing that the OS can kill applications left and right at any time, knowing the mediocre QA of most Amiga software. Install mungall and enforcer and then show me a single program does does not, at some point, generate hits. Not much happens in most cases (if mungwall is not installed).
Newly released CAM article on OS 4 : Comment 85 of 146ANN.lu
Posted by DaveP on 11-Aug-2003 13:18 GMT
In reply to Comment 84 (Anonymous):
Id say it will be a revelation for Amiga Users, instead of the whole OS falling over and GURUing only a task will go, and there is more than likely to be information about it.
Newly released CAM article on OS 4 : Comment 86 of 146ANN.lu
Posted by Anonymous on 11-Aug-2003 13:28 GMT
In reply to Comment 83 (DaveP):
>Im sorry but a computer that is under stress will contain many allocated areas of memory,

I don't really need your education, thank you very much, my software is in stores right now and I generally know what Im talking about ;-)

> Its not just a minor error, its a rogue task and whilst a minor bug if this the only app running

The scenario painted by you, a rogue application flood-filling memory, is extremely rare. But what is not quite that rare is uninitialized pointers, badly initialized pointers (NULL pointers), obsolete pointers (to previously owned memory) and careless use of pointers (writing over allocated space). Of these, only writing to NULL pointers poses the immediate danger of a total crash. All other cases come with a pretty high chance of no immediate harm.

>I think the proportion of apps that contain this kind of flaw is likely to be tiny, very tiny

In your dreams. A lot of software was developed on systems with no MMU and has never received enforcer testing. But what is more problematic is that all applications include work from other people and are beyond the programmer's control. For example, if I compile with BASIC, I have no control over the low-level code at all.
Newly released CAM article on OS 4 : Comment 87 of 146ANN.lu
Posted by Joe "Floid" Kanowitz on 11-Aug-2003 14:00 GMT
In reply to Comment 73 (Kjetil):
Kjetil said,

> When I talked about multi headed library’s I’m saying that
> library has tow set of index’s on index for Arabic and one
> for Greek, while the content of the pages
> is written in English, sins bout Arabic and Greek people can
> understand English they do not need to have separate versions
> of the books, (I know it’s a bad example), having one single
> library for bout 68k and PPC that is what is separate it form
> a box design, and no you can not divide library’s as the
> function expect the find the articles in the right place this
> is way you have the dual headed library. Just image ripping
> out the sport section of New York Post, I bet there be a lot
> of confused American football fans.

Okay, so the filename references(?) are the titles in English, the Arabic table of contents is reserved in its usual place (since, uh.. the arabs were doing algebra first..), and the Greeks have the sense to flip forward a bit to the second listing...

Meanwhile, the librarian can offer Arabic-to-Greek translation, and if the author was smart, he's included a trained lemur with his book, to slip in Greek-to-Arabic translations on the fly? :)

So much for that analogy. You didn't even rig it so I could talk about us Americans being too dumb to flip ahead while trying to find our sports sections. ;)
Newly released CAM article on OS 4 : Comment 88 of 146ANN.lu
Posted by Ben Hermans/Hyperion on 11-Aug-2003 14:00 GMT
In reply to Comment 86 (Anonymous):
>I don't really need your education, thank you very much, my software is in stores right >now and I generally know what Im talking about ;-)

It would certainly help if you would have the courage of putting your name to such statements.

We could then at least evaluate whether or not the quality of your software warranted such statements.

As you pointed out yourself, the quality of software is quite variable.
Newly released CAM article on OS 4 : Comment 89 of 146ANN.lu
Posted by bill on 11-Aug-2003 14:09 GMT
ah a dos system shell. that wont come out no mater how many broken promises. this jsut shows its not amiga.
Newly released CAM article on OS 4 : Comment 90 of 146ANN.lu
Posted by Anonymous on 11-Aug-2003 14:10 GMT
Oh by the way hans bs on that that is windows os dont lie .
Newly released CAM article on OS 4 : Comment 91 of 146ANN.lu
Posted by Don Cox on 11-Aug-2003 14:13 GMT
In reply to Comment 86 (Anonymous):
"I don't really need your education, thank you very much, my software is in stores right now and I generally know what Im talking about ;-)"

You can't expect any respect if you post anonymously.
Newly released CAM article on OS 4 : Comment 92 of 146ANN.lu
Posted by Anonymous on 11-Aug-2003 14:14 GMT
notepad .hhahaha thats microsoft sad very sad
Newly released CAM article on OS 4 : Comment 93 of 146ANN.lu
Posted by Peter Gordon on 11-Aug-2003 14:21 GMT
In reply to Comment 92 (Anonymous):
> notepad .hhahaha thats microsoft sad very sad

Notepad is not just a microsoft-ism. AmigaOS had a text editor called Notepad in all release versions from the very beginning, up to 1.3 (AFAIK). So its just as "traditionally Amiga" as it is "traditionally Microsoft", if not moreso. (anyone know what version of Windows first shipped with "Notepad" and if it preceeded Workbench 1.0?).
Newly released CAM article on OS 4 : Comment 94 of 146ANN.lu
Posted by Anonymous on 11-Aug-2003 14:21 GMT
In reply to Comment 88 (Ben Hermans/Hyperion):
>We could then at least evaluate whether or not the quality of your software warranted such statements.

And what if not? I don't get your point. The issue is how OS4 will deal with applications and their errors and what consequences that will have for users. Please don't evade the subject.
Newly released CAM article on OS 4 : Comment 95 of 146ANN.lu
Posted by Anonymous on 11-Aug-2003 14:23 GMT
In reply to Comment 91 (Don Cox):
>You can't expect any respect if you post anonymously.

But I do expect exactly that, on a factual basis. It's not as if I'm posting nonsense (I hope). And yet, you feel you have to explain to me that memory "is fragmented" on a system "in stress". Duh.
Newly released CAM article on OS 4 : Comment 96 of 146ANN.lu
Posted by Ben Hermans/Hyperion on 11-Aug-2003 14:34 GMT
In reply to Comment 95 (Anonymous):
An unverifiable factual basis such as "my software is in stores"?
Newly released CAM article on OS 4 : Comment 97 of 146ANN.lu
Posted by Hans-Joerg Frieden on 11-Aug-2003 14:49 GMT
In reply to Comment 69 (Treke):
> The ExecSG is itself a Marvelous achievement. Who was involved in the design ?

I'd say it was about 95% my brother Thomas' doing. I came up with the new library model. Most of the implementation was also done by Thomas.

> In the old times ( Sassenrath & co ... like design ) the memory protection was
> intended to place in the Dos.library, exec was intended just for task
> rescheduling, and so on...

You can't put memory protection into DOS library. It is a very fundamential issue, and DOS library sits too high up to cope with this.

> Hmm, it is possible to divide exec to more modules ?

You seem to overestimate Exec's size. It's about 250 Kilobytes of code. This also contains utility.library and expansion library (basically what is the file "kernel" on disk), which could theoretically be pulled out from the kernel itself (at least expansion; utility is more integrated with Exec so that Exec can also use TagItem calls).
Newly released CAM article on OS 4 : Comment 98 of 146ANN.lu
Posted by Hans-Joerg Frieden on 11-Aug-2003 14:51 GMT
In reply to Comment 74 (Johan Rönnblom):
> then you would not agree with their terminology if they
> called it a boxed emulation?

A "boxed" emulation for me is something that runs as a single task or a few tasks on the host system. A task-based emulation is when a 68k task is a task like anyone else in the system.
Newly released CAM article on OS 4 : Comment 99 of 146ANN.lu
Posted by Hans-Joerg Frieden on 11-Aug-2003 14:54 GMT
In reply to Comment 77 (Anonymous):
> Many illegal page accesses are completely harmless and/or have no immediate
> consequence.

An illegal page access is exactly that - illegal. It might not make the big impact immediately, but it goes by unnoticed and does *not* make your system any more stable.

> If all those tasks are just killed, users will loose a lot of data

A task can always install a recovery handler. However, a program that does illegal access is a danger to system integrity, and much more desastrous damage can occur than loosing your unsaved data.

> I prefer to have a choice if I want to continue with FinalWriter and safe my
> important document rather than being told that some irrelevant part if it just
> read from byte 0 and I have to say bye bye to it.

If the program is well-behaved, nothing happens. However, as I said, an illegal page access is a bug.
Newly released CAM article on OS 4 : Comment 100 of 146ANN.lu
Posted by Hans-Joerg Frieden on 11-Aug-2003 14:55 GMT
In reply to Comment 80 (Senex):
> If this will still be the case on a pure PPC-mainboard

We aren't using the 68k CPU under OS 4...
Anonymous, there are 146 items in your selection (but only 96 shown due to limitation) [1 - 50] [51 - 100] [101 - 146]
Back to Top