26-Apr-2024 07:15 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 146 items in your selection (but only 46 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 101 of 146ANN.lu
Posted by Anonymous on 11-Aug-2003 15:26 GMT
In reply to Comment 96 (Ben Hermans/Hyperion):
>An unverifiable factual basis such as "my software is in stores"?

No, on the basis of facts that are relevant to the question, Ben. Your tendency to evade the technical discussion of measures and consequences is getting a bit frustrating.
Newly released CAM article on OS 4 : Comment 102 of 146ANN.lu
Posted by Anonymous on 11-Aug-2003 15:34 GMT
In reply to Comment 99 (Hans-Joerg Frieden):
>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.

Hard to argue with that but I'm still thinking you are shooting over the line a bit if you just terminate software. What exactly is the problem with adopting a slighly more flexible approach? I would be perfectly comfortable with a built-in enforcer-style system that pops up a window and warns me that an application has just caused an illegal access (with big red letters warning me to save any open document now and reboot or suspend the software). That will at least give me a good chance to rescue my data.
Newly released CAM article on OS 4 : Comment 103 of 146ANN.lu
Posted by Nate Downes on 11-Aug-2003 15:45 GMT
In reply to Comment 98 (Hans-Joerg Frieden):
Agreed there. But how do you classify a box that doesn't emulate anything, it's just a protected API setup?
Newly released CAM article on OS 4 : Comment 104 of 146ANN.lu
Posted by Kjetil on 11-Aug-2003 15:58 GMT
In reply to Comment 87 (Joe "Floid" Kanowitz):
/*
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...
*/

The point of having different index's in English book is that an English word can really have better described meaning if you look up the Latin words.

/*
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? :)
*/

It more like some of the first Cristian presets that head there books in Latin or Hebrew, translated as faithed with where environment or by the roles of the lands king, this is way you have protestant, catholics and orthodox Christians.

(AROS,MorphOS,AmigaOS4.0,Amitalon,AmigaOSXL,UAE,PUP,WUP)

:-/

/*
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. ;)
*/

The point is that not every one will read the sports section, butt the once ho normally do will find them self reading half way trow the economy section before detecting there fault, and there be to latte to go over to "sports illustrated" as there heads will be spinning by then. :-)
Newly released CAM article on OS 4 : Comment 105 of 146ANN.lu
Posted by Kjetil on 11-Aug-2003 16:04 GMT
In reply to Comment 103 (Nate Downes):
Clarey you can invent a new name, like USB = Universal Serial Bus,
Newly released CAM article on OS 4 : Comment 106 of 146ANN.lu
Posted by Treke on 11-Aug-2003 17:17 GMT
In reply to Comment 99 (Hans-Joerg Frieden):
Thanx for enlightment

I've just read the CAOS story: http://www.thule.no/haynie/caos.html
So I just concluded some issues ;)

re

Treke
Newly released CAM article on OS 4 : Comment 107 of 146ANN.lu
Posted by Johan Rönnblom on 11-Aug-2003 20:43 GMT
In reply to Comment 98 (Hans-Joerg Frieden):
Hans-Jörg Frieden wrote:
> A "boxed" emulation for me is something that runs as a single task
> or a few tasks on the host system.

Fair enough. Guess we can kill this old "MOS sucks because it uses
boxed emulation"-argument then, if you don't even consider it to be
box emulation (just to be clear - I don't blame you for this
argument - but there's a certain subgroup of people who *might* just
listen to what you say.. :).
Newly released CAM article on OS 4 : Comment 108 of 146ANN.lu
Posted by Johan Rönnblom on 11-Aug-2003 20:50 GMT
In reply to Comment 82 (Ben Hermans/Hyperion):
Ben Hermans wrote:
> 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.

Not according to my autodocs. I guess either you're not really aware
how OS4 will work, or the OS4 design will have some rather important
changes made to it, or people will be quite disappointed regarding
compatibility with Amiga software.
Newly released CAM article on OS 4 : Comment 109 of 146ANN.lu
Posted by hammer on 11-Aug-2003 21:14 GMT
In reply to Comment 103 (Nate Downes):
>But how do you classify a box that doesn't emulate anything, it's just a >protected API setup?
What about WINE's example?
Newly released CAM article on OS 4 : Comment 110 of 146ANN.lu
Posted by hammer on 11-Aug-2003 21:36 GMT
In reply to Comment 48 (Raffaele):
Windows NT 4.0/5.x's core has some similarities with Digital's VMS.

Reference
http://www.winnetmag.com/Articles/Index.cfm?ArticleID=4494
Newly released CAM article on OS 4 : Comment 111 of 146ANN.lu
Posted by hammer on 11-Aug-2003 22:29 GMT
In reply to Comment 110 (hammer):
Addendum to post 110

References
http://www3.sympatico.ca/n.rieck/docs/Windows-NT_is_VMS_re-implemented.html
http://www.everything2.com/index.pl?node=Windows%20NT
Newly released CAM article on OS 4 : Comment 112 of 146ANN.lu
Posted by Nate Downes on 12-Aug-2003 00:00 GMT
In reply to Comment 109 (hammer):
WINE is a perfect example, but how do you classify such a system? It is not an emulator, nor a virtual machine, if you want to be technical about it.
Newly released CAM article on OS 4 : Comment 113 of 146ANN.lu
Posted by Kjetil on 12-Aug-2003 04:28 GMT
In reply to Comment 112 (Nate Downes):
Wine has several API emulation components and lots of DLL’s interfacing Linux .so library files. It has it own knernel32 design working on top of Linux with it own task
scheduling, kill wine task and you kill all win32 apps, with wine you can make Linux programs interface with wine, as example of that you have the BitWarriors Quick Time Wrapper for Linux.

I’m thinking about Wine as Transparent Box emulation or I will prefer to call it API emulator, how ever they call it task based emulation, and I don’t really think that is really shouted.

Clearly they have defined it like this.

Box emulation be in hardware emulation
Task Based emulation being software emulation.
Newly released CAM article on OS 4 : Comment 114 of 146ANN.lu
Posted by DaveP on 12-Aug-2003 05:44 GMT
In reply to Comment 86 (Anonymous):
Im afraid you do need that kind of education, sorry, software I have worked on is used in commercial transaction processing. So if this comes down to a dick measuring contest rather than something about the facts you might want to zip up right now, or rather in future avoid such extraneous extensions to what was up to this point normal debate.

The scenario painted by me as you call it is one that happens quite regularly on the Amiga, as you say a lot of the software is buggy as hell. I don't know about you but the much vaunted reliable AmigaOS experience passes me by.

I would rather the application that caused the problems was killed than the side effects of the bugs that you seem to think an OS should tolerate in some magical way because of mathematical probabilities.

If you access ( read/write ) memory randomly you are going to cause side effects. Fact. Whether serious or harmless depends on the roll of a dice.

What we are arguing about now is probabilities.

You might want to keep the OS you work on in the dark ages merely to keep a user space app running, but frankly I think AmigaOS needs an upgrade and the programmers a kick in the pants don't you?
Newly released CAM article on OS 4 : Comment 115 of 146ANN.lu
Posted by Ben Hermans/Hyperion on 12-Aug-2003 05:45 GMT
In reply to Comment 108 (Johan Rönnblom):
I hope this was not some pedantic reference to public memory?

In any case, I refer you to what Hans-Joerg wrote a few comments up.

I detect nothing in his reply which would contradict what I wrote.
Newly released CAM article on OS 4 : Comment 116 of 146ANN.lu
Posted by Don Cox on 12-Aug-2003 06:40 GMT
In reply to Comment 114 (DaveP):
"You might want to keep the OS you work on in the dark ages merely to keep a user space app running, but frankly I think AmigaOS needs an upgrade and the programmers a kick in the pants don't you?"

99% of the programmers left the building years ago. The existing collection of Amiga programs will not, in general, get updated or debugged.

Nor will the "replacements" actually replace them. You would think it would be straightforward to write a DPaint clone, but nobody has managed it so far.

There is a real dilemma. Update ruthlessly, and you have an OS with about six programs. Concentrate on compatability and you have lots of programs but less stability.
Newly released CAM article on OS 4 : Comment 117 of 146ANN.lu
Posted by priest on 12-Aug-2003 07:19 GMT
In reply to Comment 115 (Ben Hermans/Hyperion):
I think this is the problematic part.
"programs which start poking around outside their allocated memory space will fail"

It will kill apps that rely on being able to "poke" memory outside "their" allocated memory space. (accessing data that was delivered to them via a pointer in a message)

IIRC, this is more correct for AOS4.0:
"programs which start poking around outside allocated memory space will fail"
= poking in SW code area or in unallocated memory etc.

"Better" memory protection will appear later in the (very) distant future, after all important apps have been adapted to the new way of doing things...

Or what?
Newly released CAM article on OS 4 : Comment 118 of 146ANN.lu
Posted by Olegil on 12-Aug-2003 07:50 GMT
In reply to Comment 116 (Don Cox):
And we all know that you would prefer to run DPaint, yes yes. Heard it all before. The thing is, you can still run OS3.9 dualbooted with OS4 on your old machines. You're not forced to format anything.

Also, all the applications you keep going on about are 10 years old. One could argue that this is more than the expected lifespan of a discontinued product. In fact, one SHOULD argue this.

You know, the version of IE that came with NT4.0 isn't able to access msn.com to download an updated version. While this might be a BIT tough on people, it's how the rest of the world operates. I feel that it's better to have a small application base at release time but with a HUGE potential and plenty of eager enthusiasts than a huge base of 10 year old application but no potential and no eagerness.

It's about time you bloody well stopped talking about what can't be done and start focussing on what CAN be done, or I'll come over and point my finger at you ;-)
Newly released CAM article on OS 4 : Comment 119 of 146ANN.lu
Posted by Rik Sweeney on 12-Aug-2003 09:22 GMT
>For example, suppose that the variable "IExec" contains a pointer to
>the "main" interface of Exec library, which is of type "struct ExecIFace".
>Calling the "AllocVec" function would look like this...

You know, when I was reading this paragraph I couldn't help but feel like Dr. Evil and his "Lasers"

:)
Newly released CAM article on OS 4 : Comment 120 of 146ANN.lu
Posted by DaveP on 12-Aug-2003 09:25 GMT
In reply to Comment 117 (priest):
Using pointers from structures in message passing still works from what I can see.:-D

If you go poking around memory randomly, expect to be brought down though.
Newly released CAM article on OS 4 : Comment 121 of 146ANN.lu
Posted by Anonymous on 12-Aug-2003 10:11 GMT
In reply to Comment 114 (DaveP):
>If you access ( read/write ) memory randomly you are going to cause side effects. Fact.

The World according to DaveP ;-) You don't seem to have ever touched a compiler. To correct you:

1. random reads and random writes can have a side effect
2. they do not necessarily have a side effect
3. side effects, if any, can vary from inconsequential to severe
4. Amiga applications have memory access bugs (period).

I will go a bit more technical below because you don't seem to have the background to discuss this matter at this point. But before I do that, I want to clarify my point:

If you have a system that was build with memory protection and has evolved since then (like Linux), any application that was written knows the rules. Illegal page hits are rare. In that environment, it's acceptable to take drastic measures because not doing so would undermine the integrity and standing of the OS. Better software is produced. AmigaOS4 comes from a different background: most applications that will run on it were not or not fully tested with it (even it they are recompiled with gcc for AOS4). Most are frozen in the current state and will not be touched again. Many have memory access bugs. To me it appears as if, with such a muddled background, taking the high route - it's a bug, terminate the process - is just plain stupid because it will make the using experience rather unfriendly. Users will loose data with this approach. It's an extremly annoying experience to have FinalWriter killed with ten new pages right under your nose to preserve the integrity of Workbench. Instead of this radical approach, I would want to be informed that the integrity of the system may be damaged but still be given time to save my work, at my own risk.

1.Why random reads and writes do not "cause side effects. Fact."

Much software is written with C and a weak point of C are pointers, careless use probbaly causes the majority of bugs (other errors will not be discussed here; errors like division by zero are not related to memory protection anyway). Typical errors with pointers:

1a. Initializing pointer to NULL and then using it

Write access with a NULL pointer/a dereferenced NULL pointer (pointer->member) is probably terminal and should not be permitted. Read access may not have a side effect at all or it may be harmless: If you are reading a string from 0, lets say the default file name for "Save...", you get garbage. That's a side effect but does not necessarily hurt if a a zero (ie a string terminator) is reached soon. No buffer overflows and a wrong file name is a minor annoyance. In other cases, you may have no side effect at all. For example, the pointer might be used as pointer to a boolean that decides whether the program asks before it exits. Booleans are zero or not-zero. There is a good chance that the random read procuces the correct value. Finally, most features in software are not used. In FinalWriter, I might use 5% of the functions during a session. You may have a wrong pointer that sets some option to a wrong value but the feature that depends on it is never used. No visible side effect in that case, too.

1b. Uninitialized pointers

While NULL pointers are quite rare, uninitialized pointers are not: In C, local variables, pointers included, are by default undefined (have a random value rather than zero). Some compilers warn users about unitialized pointers but many do not. With regard to illegal read accesses, the scenario is identical with the paragraph above: you can be lucky and often are. With regard to write access, the scenario is improved: a random pointer will point to a random address. The chance that you overwrite critical memory is miniscule. The odds are imrpoved by the fact that allocated memory usually grows from one end of the address space. In a 512 MB system, much of the address space will just be empty space.

1c. Careless use of pointers

Statistically, accessing memory that was just freed is one of the most common mistakes with regard to illegal memory accesses. An example is given below. Very often, these errors do not have any side effect at all: it can be hoped that the memory was not yet allocated again. Amazingly, that is very often the case (developers use the mungwall program to immediately trash freed memory to discover such bugs). But even if the memory is now used differently, the situation corresponds to 1b and may still be resolved nicely. Example: Think about traversing a list, freeing certain nodes. DaveP, to show that you have a clue about programming, please correct ;-)

// remove nodes with priority 10

struct Node *node;

for (node = list->lh_Head; node->ln_Succ; node = node->ln_Succ) {

if (node->ln_Pri == 10) {

Remove(node);

FreeVec(node);
}
}
Newly released CAM article on OS 4 : Comment 122 of 146ANN.lu
Posted by Anonymous on 12-Aug-2003 10:14 GMT
>So if this comes down to a dick measuring contest rather than something about the facts you might want to zip up right now

A childish touch for good measure never hurts ;-)
Newly released CAM article on OS 4 : Comment 123 of 146ANN.lu
Posted by Johan Rönnblom on 12-Aug-2003 10:20 GMT
In reply to Comment 115 (Ben Hermans/Hyperion):
Ben Hermans wrote:
> I hope this was not some pedantic reference to public memory?

Pedantic or not.. in AmigaOS, nearly all (allocated) memory is public.
If it's true as some people said below, that only programs which
start poking around outside memory that has been allocated *at all*
will be terminated, this is fine. But it's not what you wrote. And the
importance is quite crucial.

While I expect future AmigaOS (and MOS) apps to allocate non-public
memory, which will make it possible to protect this memory from
other apps, this is not the case today. And IMO it's important that
people don't get the impression that this will be possible with
existing Amiga programs.
Newly released CAM article on OS 4 : Comment 124 of 146ANN.lu
Posted by Rik Sweeney on 12-Aug-2003 10:29 GMT
In reply to Comment 121 (Anonymous):
When I'm clearing linked lists I generally do the following, it's quite safe:

Counter *c1,*c2;

for (c1=counterhead->next;c1!=NULL;c1=c2)
{
c2 = c1->next;
free(c1);
}
Newly released CAM article on OS 4 : Comment 125 of 146ANN.lu
Posted by DaveP on 12-Aug-2003 10:41 GMT
In reply to Comment 121 (Anonymous):
Yes of course, that is the obvious conclusion to make, an assertion about someone making random reads and writes to addresses on an OS without proper memory protection clearly leads to the fact that I know nothing about compilers.( rolls eyes ).

Come on, you can do better than that. If you want to continue to make this a denegration fight, by all means carry on, you are going to be doing it without me reading or replying.
Newly released CAM article on OS 4 : Comment 126 of 146ANN.lu
Posted by Ben Hermans/Hyperion on 12-Aug-2003 10:56 GMT
In reply to Comment 123 (Johan Rönnblom):
I should clarify that what I was saying relates only to OS 4 native applications.

The intention is to trap most illegal memory accesses by 68K programs, not execute them and then resume the 68K program.

This is only true for 68K programs, OS 4 native programs will be treated more severely.
Newly released CAM article on OS 4 : Comment 127 of 146ANN.lu
Posted by Hans-Joerg Frieden on 12-Aug-2003 11:10 GMT
In reply to Comment 102 (Anonymous):
> What exactly is the problem with adopting a slighly more flexible approach?

There isn't any problem from a technical point of view. Exec does know where the problem comes from (68k vs. PowerPC) and could act accordingly...

A possibility would be to post a requester saying that the task did something nasty and allow for "Kill", "Allow" and "Allow always"...

> That will at least give me a good chance to rescue my data.

True. I am concerned with stability of the system as a whole, though. Any such illegal access might bring the system down, if not right away, it might happen after some time. I am concerned that people might think that because nothing happened things are still all right.

I'll look into this. It's not difficult to add.

If you want to continue discussion this, please contact my in private.
Newly released CAM article on OS 4 : Comment 128 of 146ANN.lu
Posted by Hans-Joerg Frieden on 12-Aug-2003 11:14 GMT
In reply to Comment 108 (Johan Rönnblom):
> Not according to my autodocs.

The autodocs don't say that you are allowed to poke where you like. In fact, poking outside physical memory will result in a guru even on the 68k (bus error).

The autodoc for AllocMem specifically mentions that MEMF_PUBLIC means this is "Memory that must not be mapped, swapped, or otherwise made non-addressable". This implicitly says that memory that is not flagged as MEMF_PUBLC *CAN* be made non-addressable, and that therefore it is an error to access it.

Having said this, PUBLIC memory can still be accessed from everyone on OS 4, because it is flagged as public. But that's it.
Newly released CAM article on OS 4 : Comment 129 of 146ANN.lu
Posted by Hans-Joerg Frieden on 12-Aug-2003 11:17 GMT
In reply to Comment 121 (Anonymous):
> Very often, these errors do not have any side effect at all: it can be hoped
> that the memory was not yet allocated again.

I don't think that system stability should have anything to do with "hope".
Newly released CAM article on OS 4 : Comment 130 of 146ANN.lu
Posted by Hans-Joerg Frieden on 12-Aug-2003 11:20 GMT
In reply to Comment 123 (Johan Rönnblom):
> Pedantic or not.. in AmigaOS, nearly all (allocated) memory is public.

IF the memory is allocated *with* MEMF_PUBLIC, this doesn't pose a problem for ExecSG, because the PUBLIC attribute is invented *exactly* for the purpose of sharable memory.

However, if the memory is NOT flagged MEMF_PUBLIC, it is automatically to be considered private. Read the autodoc on AllocMem about becoming non-addressable.
Newly released CAM article on OS 4 : Comment 131 of 146ANN.lu
Posted by Anonymous on 12-Aug-2003 11:54 GMT
In reply to Comment 129 (Hans-Joerg Frieden):
>I don't think that system stability should have anything to do with "hope"

Neither do I; was just pointing out the error in DaveP's statement that illegal accesses always have an effect.
Newly released CAM article on OS 4 : Comment 132 of 146ANN.lu
Posted by Olegil on 12-Aug-2003 12:02 GMT
In reply to Comment 131 (Anonymous):
He didn't say they always had a noticeable effect (that I can see, anyway. Maybe I missed a posting or ten ;-) ).

But writing to random places in memory will MOST CERTAINLY not be "usually harmless", because if there is memory there, there's a good chance it will be someone elses, if there isn't memory there there's a good chance you'll see a bus error.

Which of these is the harmless one, again? Good programs do not write at random addresses.
Newly released CAM article on OS 4 : Comment 133 of 146ANN.lu
Posted by DaveP on 12-Aug-2003 12:05 GMT
In reply to Comment 132 (Olegil):
Nope, I didnt. But Ive got used to people slightly modifying my words to argue against something I have never said.
Newly released CAM article on OS 4 : Comment 134 of 146ANN.lu
Posted by Anonymous on 12-Aug-2003 12:25 GMT
In reply to Comment 133 (DaveP):
>Nope, I didnt. But Ive got used to people slightly modifying my words to argue against something I have never said.

Maybe you should get used to reading your own comments. If I may help your memory: "If you access (read/write) memory randomly you are going to cause side effects. Fact."
Newly released CAM article on OS 4 : Comment 135 of 146ANN.lu
Posted by Anonymous on 12-Aug-2003 12:51 GMT
In reply to Comment 134 (Anonymous):
Hey, can you say "pedant"?

/ian/
Newly released CAM article on OS 4 : Comment 136 of 146ANN.lu
Posted by Anonymous on 12-Aug-2003 12:51 GMT
In reply to Comment 132 (Olegil):
>But writing to random places in memory will MOST CERTAINLY not be "usually
harmless"

For a start, we were talking about memory accesses, not necessarily writes (I'm only mentioning that as a comment, illegal reads can be equally harmful). Furthermore, we are not (only) talking about random accesses but abbout illegal accesses. It just happens that many illegal accesses are illegal but not random. Finally, you are using a double negative. The positive form of your statement is that illegal writes are usually fatal. I have never investigated that but simple statistic would not support your point of view. With 512+ million addresses, the chance that a truly random, illegal write access does no major harm is quite significant. To do harm you would (a) have to hit an address that is subsequently read and used and on top of that (b) write a value that causes harm. For non-random accesses chances are not that rosy because that category includes NULL pointers and obsolete pointers (with a good chance that they point into dangerous territory).

Anyway, my point is NOT that illegal accesses are good or never do any harm or whatever you seem to read into me. I'm just advocating alternative measures than death penalty (and loss of data). What Ben said a few comments above sounds interesting: tolerate accesses but do not execute writes. Maybe there are other solutions, too. Think about how FAT deals with errors when one block is linked into two files: it just duplicates the block. It's a bit stupid on first sight but could prolong the life of an application long enough to allow saving?
Newly released CAM article on OS 4 : Comment 137 of 146ANN.lu
Posted by Kjetil on 12-Aug-2003 13:57 GMT
In reply to Comment 136 (Anonymous):
The problem is that programs doing random or is misbehaving is normally repeating them self as well over and over again, so lets say you have program that is doing, harmfully write access, and that programs run's x times faster now that program will crash x time faster on a faster computer so you hardy have any use for it, and one more thing if you have lots of programs open, you have noe problem filling the memory, and likelihood of hitting used memory grater.

programs that may crash now is programs doing things like

void main()
{
char *mem;
if (mem = (void *) malloc( 100 ) )
{
for(a=0;a<=100;a++)
{
*mem=0; mem++;
}
free(mem);
}
}

when the program should be written

void main()
{
char *mem;
if (mem = (void *) malloc( 100 ) )
{
for(a=0;a<100;a++)
{
*mem=0; mem++;
}
free(mem);
}
}
Newly released CAM article on OS 4 : Comment 138 of 146ANN.lu
Posted by Kjetil on 12-Aug-2003 14:09 GMT
In reply to Comment 137 (Kjetil):
/*
This is an exsampel where found pointer is not set, and program returns random number when pointer found, in the dynamic tabel, it will may be work 90% of the time and may crash the program, if found pointer is not zero
*/

void *find_ptr(dynamic_tab_type *tabel,void *ptr)
{
void *found;

while (tabel)
{
if (tabel==ptr) found = tabel;
tabel = tabel -> next;
}

return tabel;
}

dynamic_tab_type *main = 0;

int main()
{
dynamic_tab_type *tab;

main = init_main_tab();

for(;;)
{
value = find_item_by_name("test");
if (tab = find_ptr( main , value ) )
{
free_item(&main,tab);
}
}
}
Newly released CAM article on OS 4 : Comment 139 of 146ANN.lu
Posted by Anonymous on 12-Aug-2003 14:10 GMT
In reply to Comment 137 (Kjetil):
>The problem is that programs doing random or is misbehaving is normally repeating them self as well over and over again

Maybe, maybe not. I don't think the effects can be generalized. I know from my own experience that enforcer hits can be harmless (per se) or harmless most of the time(no mungwall around). The really serious stuff - writing to a NULL pointer, normally does not make it into a release version. To be as safe as possible, I don't release software without running it at least through two compilers who pick up different errors. The optimizer in one compiler is good at noticing uninitialized pointers etc.

As to your example, I don't get it. You free a memory pointer after incrementing it. Not good.
Newly released CAM article on OS 4 : Comment 140 of 146ANN.lu
Posted by Kjetil on 12-Aug-2003 14:30 GMT
In reply to Comment 139 (Anonymous):
not at all I count 101 bytes and set them all to zero, while allocated data is 100 byte, after that i free the data when finished with it, Imagen this type of code doing smooth effects on a Image.

it is just a tiny bug but hard to spot really.

To the fix it you can write

for(a=0;a<100;a++)

or

for(a=1;a<=100;a++)
Newly released CAM article on OS 4 : Comment 141 of 146ANN.lu
Posted by Kjetil on 12-Aug-2003 14:48 GMT
In reply to Comment 139 (Anonymous):
The bug you found Whit Killie the program with i a second, that where not the bug I where thinking about really. it's an otter common bug i guess.
Newly released CAM article on OS 4 : Comment 142 of 146ANN.lu
Posted by Nate Downes on 12-Aug-2003 15:37 GMT
In reply to Comment 113 (Kjetil):
Let us break down the word emulation. It's root is Emulate, which in Websters, reads:
To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system.

Alright, so by that definition, WINE is an emulator.
Newly released CAM article on OS 4 : Comment 143 of 146ANN.lu
Posted by Kjetil on 12-Aug-2003 19:50 GMT
In reply to Comment 142 (Nate Downes):
You can call it integration, may be there term is better, as Wine can read and writes to Linux directory's and use linux resources, Linux programs that know about Wine can access it's dll's, clipboard works between the system etc. TCP/IP stack is sheared etc.

Wine the API integration.

In way calling wine a emulator is like calling Java a emulator, than again Java is not imitating any thing else then it self.
Newly released CAM article on OS 4 : Comment 144 of 146ANN.lu
Posted by Nate Downes on 13-Aug-2003 21:33 GMT
In reply to Comment 143 (Kjetil):
Not a bad way to put it. But on the same note, so is MorphOS's ABox system.
Newly released CAM article on OS 4 : Comment 145 of 146ANN.lu
Posted by Kjetil on 14-Aug-2003 17:11 GMT
In reply to Comment 144 (Nate Downes):
ABox is what the developers of MorphOS call it, relay integration is not good word as I first think any way extension is better word to extend some thing is really what WINE and ABOX is doing, for linux user WINE is used as replacement for not having native library's or programs, like QuickTime Player or some videocodexes, apparently WINE as api integration suffer from not emulation hardware so you can expect to run every application and if allows suffer from not having some dll's need hear and there that can communicate with Linux as side effect, some dll will act strange when they are used with some windows dll's etc. and the path conversion system is not as good C:\windows is written like c://windows// it suffer from not being UNIX like, and programs will run slowly compared with Windows environment, or native linux programs, many due to the extra conversion layer,

MorphOS ABOX how ever acts more of it own from what I understand has no dual environment (NO GTK,NO GNOME,NO X-Windowes,No LPD) to think off, then again this limit's it interaction with the quark as side effect and there for you bound to get in to trouble whit the integration of Q/Box and the otter system resources with out opening up the system to task-based emulation, it clear that are dropping the old design, the good thing is that many MorphOS users have head the opportunity to use some thing Amiga like system while there old Amiga can't compete with the speed, The AmigaOS4.0 development has shore taken time, even if it finely is showing some progress.

I like to stress this maintaining tow separate environment (Quark,Abox) is a double job, maintain tree environments are triple job, (Quark,Abox,Qbox), getting the tree environments to work to getter is even grater job whit out bugs, going trow some execute otter box's library function it equals latency, and it's really unnecessary, it adds extra CPU load, So doing a clean cut like MorphOS promote is not a easy task, and when it involves moving step by step or stage by stage it will be pain full experience compared with full scaled upgrade like with AOS4.0; it only moves once and than then it only GFX upgrades and bug fixing left nice!!!
Newly released CAM article on OS 4 : Comment 146 of 146ANN.lu
Posted by Nate Downes on 15-Aug-2003 14:31 GMT
In reply to Comment 145 (Kjetil):
you just thrown this huge rant and made a simple mistake in your premice:

The "QBox" is a term covering all parts of MorphOS not inside of the ABox, including Quark.

So, your "3 environments" arguement is a complete fabrication, since one of those environments encompasses the other two.
Anonymous, there are 146 items in your selection (but only 46 shown due to limitation) [1 - 50] [51 - 100] [101 - 146]
Back to Top