27-Apr-2024 04:43 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 327 items in your selection (but only 127 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 250] [251 - 300] [301 - 327]
[News] Strong Genesi presence at AmiwestANN.lu
Posted on 29-Jul-2003 17:41 GMT by Daniel Miller327 comments
View flat
View list
In the Genesi presentation on Sunday, Matt Sealey got up and did a passionate job explaining all the great things that are available and coming for MorphOS. The other Genesi speakers did an excellent team presentation that showed off the great benefits and many positive attributes of MorphOS on the Pegasos. My early reporting for Amiga-News.de related the story of Saturday's Genesi presentation, which went poorly due to technical problems unrelated to the abilities of MorphOS or the technical excellence of the Pegasos. The problems owed more to configuration and hard-drive settings, and the Genesi team stumbled a bit because of that. Conversely the OS4 presentation, done on a A4000 (OS4 has yet to be demonstrated on an Amiga One), went very well. In all cases those reports dealt only with Saturday. The Genesi presentation on Sunday went smashingly, and they showed a lot of teamwork and frankly they recovered completely from Saturday I wrote the Saturday's report as a journalist, not a MorphOS advocate. I don't like it being portrayed the way it has been on ANN in the post by anonymous AM. My article was not about the stupid OS4 vs. MorphOS war, it was about Amiwest on Saturday. The MorphOS presentation on Sunday kicked ass. I am sorry I wasn't able to report on it later Sunday, being on the road. It is a bit of an injustice that so called advocates are the ones who do a lot of the reporting, leaving Internet readers hostage to their prejudices. I tried to stay away from that in my reports. In the Genesi presentation on Sunday, Matt Sealey got up and did a passionate job explaining all the great things that are available and coming for MorphOS. The other Genesi speakers did an excellent team presentation that showed off the great benefits and many positive attributes of MorphOS on the Pegasos. Bill Buck spoke very well also. Genesi made a lot of friends on Saturday and Sunday, and showed that they 100% earned their place in the Amiga community, where they belong. They have an almost complete solution that is so far more advanced than OS4 that it is not even funny. The OS4 presenter did a great with the presentation but as far as the actual product there is absolutely no comparison. Maybe someday Hyperion and partners will produce something to compae with MorphOS and Pegasos but not yet, and this fact was clear to anyone who attended Amiwest. I wish ANN would adopt a policy of not letting anonymous posters leave news stories. The article as characterized by AM is an oversimplification and really is a distortion. Let's leave the MorphOS-OS4 war behind for once. At Amiwest we did.
Strong Genesi presence at Amiwest : Comment 201 of 327ANN.lu
Posted by Henning Nielsen Lund [Denmark] on 31-Jul-2003 11:03 GMT
In reply to Comment 200 (o1i):
I think there would be grater chance for that, if some PEOPLE wouldn't be negative all the time (no matter what)
Strong Genesi presence at Amiwest : Comment 202 of 327ANN.lu
Posted by Anonymous on 31-Jul-2003 11:35 GMT
In reply to Comment 61 (Don Cox):
>yes of course MorphOS was started a couple of years earlier,

And don't forget to mention that MOS uses a lot of AROS code, otherwise it would still be far at sea. You keep laving oput what's not convenient to you, Don. I still can't understand how people can do 180 degrees turns.
Strong Genesi presence at Amiwest : Comment 203 of 327ANN.lu
Posted by Anonymous on 31-Jul-2003 11:37 GMT
In reply to Comment 66 (Don Cox):
What programs would they be? I'm serious... what's on classic Amiga software today that is not available on other platforms? I understand the passion about this computer and why so many (?) people still want to use it, but I don't understand obsession. A computer is just a tool, a thing many people here fail to understand.
Strong Genesi presence at Amiwest : Comment 204 of 327ANN.lu
Posted by dammy on 31-Jul-2003 11:46 GMT
In reply to Comment 176 (Nate Downes):
> Hey Ben, ya forgot to come by the booth to grab a pegasos.

Why am I not suprised?

Dammy
Strong Genesi presence at Amiwest : Comment 205 of 327ANN.lu
Posted by DaveP on 31-Jul-2003 11:48 GMT
In reply to Comment 204 (dammy):
Yeah I know, still giving them away for free. Im amazed. Or maybe it was just a loaner? Still, it gets the users in, and thats whats needed to build a critical mass.

Dave.
Strong Genesi presence at Amiwest : Comment 206 of 327ANN.lu
Posted by Neko on 31-Jul-2003 12:34 GMT
In reply to Comment 199 (Anonymous):
As far as I recall, I haven't checked since 2 or 3 months ago, we are going MUI.

Envisage absolutely no Gadtools or plain BOOPSI by the time we get done, and
you wouldn't be too far from the truth. We know for a fact we can do this,
because we've done it before, what I don't think we know is how long it'll take
with all this other work to be done :)
Strong Genesi presence at Amiwest : Comment 207 of 327ANN.lu
Posted by anonymous on 31-Jul-2003 12:56 GMT
It's definitely nice to see people meeting on more conciliatory terms, but in all of this was there any hint of opportunities for technology sharing or strategic relationships?

Both camps understand their limitations and presumably appreciate the importance of branding. Yet after all the investment in resources and time, neither seem to realize that the duplication of effort is doing no one a service. Add to this the AROS effort and you have a large number of talented people working on divurgent paths to basically accomplish the same thing.

What the community wants (and has always wanted) is a robust, affordable Amiga solution that brings the system back into this century. Three operating systems running on expensive hardware with limited application support is not quite going to cut it.

Take a page from the Linux camp... there is such a thing as 'coopetition'.
Strong Genesi presence at Amiwest : Comment 208 of 327ANN.lu
Posted by Phill on 31-Jul-2003 13:16 GMT
In reply to Comment 100 (Anonymous):
> Why would MS want to compare the Xbox 2 with the PS 2? The current Xbox
> kicks the pathetic PS 2 out of the water as it is.

Only in terms of clock speed. Which means that software ported and run using a mod chip will run better. Anything thats optimised for the playstation 2 architecture is just as good as an xbox.

Phill
Strong Genesi presence at Amiwest : Comment 209 of 327ANN.lu
Posted by samface on 31-Jul-2003 13:33 GMT
In reply to Comment 207 (anonymous):
100% agreed. Probably the best post I've ever seen from mr anonymous. =)
Strong Genesi presence at Amiwest : Comment 210 of 327ANN.lu
Posted by Matt Parsons on 31-Jul-2003 13:42 GMT
In reply to Comment 207 (anonymous):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
It's definitely nice to see people meeting on more conciliatory terms, but in all of this was there any hint of opportunities for technology sharing or strategic relationships?
<<<<<<<<<<<<<<<<<<<<<<<<<<<<

www.openamiga.org anyone?
Strong Genesi presence at Amiwest : Comment 211 of 327ANN.lu
Posted by Bernie Meyer on 31-Jul-2003 13:52 GMT
In reply to Comment 181 (Ben Hermans/Hyperion):
> One e-mail to Thomas Frieden could clear this right up.But why should I bother Thomas about it? He has better things to do than to explain the workings of his stack expansion mechanism to some guy in Australia. Doing so would have no possible benefit, except maybe as part of peer review --- but as you point out, there is enough of that around already.On the other hand, I *am* obviously wondering how this stuff is done. Heck, you might have guessed already that I tossed up ideas on whether and how to do this myself in the past, and found them all unworkable.In the absence of OS4 (yes, Ben, if you won't even let ordinary people play with the OS4 machine at AmiWest, I don't consider OS4 to be an existing product, sorry), speculation is all us mere mortals not involved in the development have. Now, my guesses might be somewhat more educated than those of the average Amiga user, but that just means that the questions I still have are more complicated.There is another reason why I don't ask Thomas --- he might tell me how he does it. And he'd probably do so in confidence.... Which would prevent me from using that, or a similar mechanism, in the future (as it's Thomas's). So much better to mull this over with people like Fabio, and whoever else might come up with a reason why my arguments are crap, and how to work around the issues I can't find a way around, in public. In the worst case, we'll all have to wait for an answer until OS4 comes out. In the best case, we might end up with two competing solutions to the problem, which can inspire and compliment each other.
Strong Genesi presence at Amiwest : Comment 212 of 327ANN.lu
Posted by Bernie Meyer on 31-Jul-2003 14:00 GMT
In reply to Comment 191 (Hans-Joerg Frieden):
Thanks Hans-Joerg for the comments. Horse's mouth, great :)Silly question --- does that imply that there can never be more than 256MB of 68k code be loaded? Not much of a restriction if so, but interesting nonetheless.Also, does this imply that 68k code needs to be known to be 68k code when it is loaded? I.e. would things break if I simply (in an existing, OS4-unaware 68k program) allocated a bit of memory, dynamically created 68k code in it, and then jumped to it?Could you explain how the use of a single, vitualized address space reduces memory fragmentation? I mean, apart from the fact that you now fragment address space rather than memory, I can't quite see where the benefits are in that regard.Everything else, of course, I agree with. I love virtual memory, for all those non-swapping benefits :)
Strong Genesi presence at Amiwest : Comment 213 of 327ANN.lu
Posted by Hans-Joerg Frieden on 31-Jul-2003 14:11 GMT
In reply to Comment 200 (o1i):
> So the "Incidentally, I do believe that 2 GB is used for the PCI space and 2 GB
> is used for the virtual address space." of comment 181 was just a believe ;)?

The hardware (On the AmigaOne) devides the address space in two 2GB parts. Virtualization can move that border anywhere you like.

> It was not so important for me that I wanted to write personal mails to
> developers, I know, how annoying that can be.

I'd rather answer private mail than having people speculate.
Strong Genesi presence at Amiwest : Comment 214 of 327ANN.lu
Posted by Ben Hermans/Hyperion on 31-Jul-2003 14:16 GMT
In reply to Comment 211 (Bernie Meyer):
Bernie, you are hardly a regular user and even queries from regular users get answered by us.

So have no qualms about asking us.

And incidentally, I doubt Thomas would care if you copied his mechanism.

Incidentally, I read a report that some MorphOS supporter had been using OS 4 at Amiwest.

So I doubt that regular users were not allowed to use it.

I certainly did not give any instructions to that effect.

We have nothing to hide.
Strong Genesi presence at Amiwest : Comment 215 of 327ANN.lu
Posted by Nate Downes on 31-Jul-2003 14:25 GMT
In reply to Comment 214 (Ben Hermans/Hyperion):
Actually I have to back up Ben here, as I *was* a MOS supporter trying out AOS4 on the Mr. Hardware machine while they weren't paying attention. (tee hee)

While better than I expected, it is still behind. But still, credit where credit is due, Hyperion has done a decent job. And you still forgot to drop by the booth for the promiced Pegasos.
Strong Genesi presence at Amiwest : Comment 216 of 327ANN.lu
Posted by Hans-Joerg Frieden on 31-Jul-2003 14:29 GMT
In reply to Comment 212 (Bernie Meyer):
> Silly question --- does that imply that there can never be more than 256MB of
> 68k code be loaded? Not much of a restriction if so, but interesting
> nonetheless.

Sure there can. 68k code is data, at least from the PowerPC's point of view. Trying to execute data assumes you are trying to execute 68k Code and drops you into the emulator. If this happens to be data, well, there's something wrong there anyway, and chances are that there will be an exception soon :-)

> Also, does this imply that 68k code needs to be known to be 68k code when it
> is loaded? I.e. would things break if I simply (in an existing, OS4-unaware
> 68k program) allocated a bit of memory, dynamically created 68k code in it,
> and then jumped to it?

No, since 68k Code is really data, any old program can poke and execute 68k code from anyway. PowerPC code is really the only exception, which must be placed into MEMF_EXECUTABLE memory.

Only new programs are affected, i.e. a program wanting to write program code (like a JIT emulator, for example) will need to allocate its buffer with MEMF_EXECUTABLE set, but since this only affects new programs, it doesn't affect functionality; even if you recompile a program for OS 4 and the PowerPC code generates 68k instructions, you can still jump there, but it will end up being emulated (obviously).

> Could you explain how the use of a single, vitualized address space reduces
> memory fragmentation? I mean, apart from the fact that you now fragment
> address space rather than memory, I can't quite see where the benefits are in
> that regard.

Well, it obviously still fragments, but it fragments the address space, not the memory pages itself. At least on the old machines you will have much less memory than address space, so this is certainly a benefit to CyberStorm and Blizzard users, while it doesn't hurt you if you have a gigabyte of memory.

We're also working on more intelligent memory allocators, mainly buddy lists and boundary tags. Much room for experiments :-)

And finally, the single address space should go away at some point. We'll make a kernel available to developer that has private address spaces. It will break a lot of compatibility, and will reuquire new API's and guidelines (especially for message passing), therefore it will be developer only.

> Everything else, of course, I agree with. I love virtual memory, for all
> those non-swapping benefits :)

Well, swapping *is* an issue on Cyberstorms. The upper memory limit just isn't up to todays tasks anymore.

I also like the memory-mapped files, and the possibility to reallocate an existing memory block with a different size. Stack overflow was also a serious problem - there are other ways around this, but automatic extension code is by far the most elegant way.

Problem is really, most people think that virtual memory is swapping, but there is really so much more to it ;-)
Strong Genesi presence at Amiwest : Comment 217 of 327ANN.lu
Posted by Bernie Meyer on 31-Jul-2003 14:34 GMT
In reply to Comment 215 (Nate Downes):
Sorry, Ben --- it was the impression I got from reading the show reports and discussions on the various Amiga newsboards. If that impression was incorrect, I apologize.
Strong Genesi presence at Amiwest : Comment 218 of 327ANN.lu
Posted by redrumloa on 31-Jul-2003 14:45 GMT
In reply to Comment 214 (Ben Hermans/Hyperion):
> So I doubt that regular users were not allowed to use it.

Huh? I was told no. I would have wanted to try it:-(
Strong Genesi presence at Amiwest : Comment 219 of 327ANN.lu
Posted by Bernie Meyer on 31-Jul-2003 14:46 GMT
In reply to Comment 216 (Hans-Joerg Frieden):
OK, I'll bite --- for the stack expansion, how *do* you ensure that the area you expand into is not used by something else? Especially in the presence of mmap()ing files, which can easily gobble up large chunks of address space rather quickly?Just for kicks (and laughs, probably), here is the only way I have been able to come up with which doesn't involve pre-allocating huge amounts of address space:(a) Allocate a certain, smallish amount of address space for stack. Leave the page below that memory unmapped, as a guard page. Don't map any actual memory into that stack until needed. (b) Whenever you get a page fault on stack memory, for a page inside that original allocation, map a page of real memory to it, and continue. (c) Whenever you hit the guard page, allocate a piece of address space twice as large, with its own guard page below. Map the upper half of that new address space to the existing stack memory, *without* unmapping the old address space. Change the stack pointer to point to the new address space (and adjust the Exec task structures accordingly).(c) means that you end up with mutiple logical addresses being mapped to the same physical memory, which can lead to problems when comparing pointers.... But other than that, it should at least *work*. Of course, you end up with between 2 and 3 times more address space used for stack than the size of your stack --- but at least, there is no need to pre-set the size.*grin* Now you can make me go "Argh, how could I miss that?!?" :)
Strong Genesi presence at Amiwest : Comment 220 of 327ANN.lu
Posted by DaveP on 31-Jul-2003 14:51 GMT
In reply to Comment 218 (redrumloa):
Yeah, well you probably had "I need replacement parts for my A4000" written all over your face ;-)
Strong Genesi presence at Amiwest : Comment 221 of 327ANN.lu
Posted by redrumloa on 31-Jul-2003 14:53 GMT
In reply to Comment 220 (DaveP):
LOL yeah, I probably was too shifty looking ;-)
Strong Genesi presence at Amiwest : Comment 222 of 327ANN.lu
Posted by ehaines on 31-Jul-2003 15:12 GMT
In reply to Comment 49 (Nicolas Sallin):
> Go away.

I'd rather you did, actually. And Eva's managed to convince me never to
use MorphOS, no matter how great it is. Congrats!
Strong Genesi presence at Amiwest : Comment 223 of 327ANN.lu
Posted by Don Cox on 31-Jul-2003 15:23 GMT
In reply to Comment 203 (Anonymous):
"What programs would they be? I'm serious... what's on classic Amiga software today that is not available on other platforms?"

If you are a new user, starting from scratch, not much. But if you have bought a big pile of Amiga programs which would cost thousands to buy again for Windows or OS X, plus the cost of having to learn them all, it makes more sense to go on using what you have.

I have other things to spend my limited finances on than new programs that basically do what the programs I already own do already.

Add to that that I have been using Windows at work since version 1, and ideally I would never see it again. In practice, I use it for a few things I don't have on the Amigas, such as downloading Real Audio streams.

Why might a new user in a couple of years time find an Amiga-style computer worth buying? Hopefully because it will not phone home to report what is on your hard drive.
Strong Genesi presence at Amiwest : Comment 224 of 327ANN.lu
Posted by redrumloa on 31-Jul-2003 15:23 GMT
In reply to Comment 222 (ehaines):
I had a real jerk in a chevy van nearly run me off the road today, could have been real... However, that won't keep me from considering purchasing a Chevy in the future.
Strong Genesi presence at Amiwest : Comment 225 of 327ANN.lu
Posted by DaveP on 31-Jul-2003 15:26 GMT
In reply to Comment 224 (redrumloa):
I can think of better reasons never to by a Chevy ;)
Strong Genesi presence at Amiwest : Comment 226 of 327ANN.lu
Posted by Don Cox on 31-Jul-2003 15:28 GMT
In reply to Comment 216 (Hans-Joerg Frieden):
"Well, it obviously still fragments, but it fragments the address space, not the memory pages itself. At least on the old machines you will have much less memory than address space, so this is certainly a benefit to CyberStorm and Blizzard users, while it doesn't hurt you if you have a gigabyte of memory."

Serious users working on large images with lots of layers are now using more than 2 Gigs of RAM.
Strong Genesi presence at Amiwest : Comment 227 of 327ANN.lu
Posted by DaveP on 31-Jul-2003 15:30 GMT
In reply to Comment 226 (Don Cox):
Its a hardware limitation Don. :-) As we go to 64 bit boards and the next Articia chipset something may get done about it.
Strong Genesi presence at Amiwest : Comment 228 of 327ANN.lu
Posted by Don Cox on 31-Jul-2003 15:34 GMT
In reply to Comment 222 (ehaines):
"And Eva's managed to convince me never to
use MorphOS, no matter how great it is."

I'm sure we can find you similar people who support AOS 4, or other OSes.
Strong Genesi presence at Amiwest : Comment 229 of 327ANN.lu
Posted by Nate Downes on 31-Jul-2003 15:38 GMT
In reply to Comment 228 (Don Cox):
Like Cooksey?
Strong Genesi presence at Amiwest : Comment 230 of 327ANN.lu
Posted by Matt Parsons on 31-Jul-2003 15:41 GMT
In reply to Comment 214 (Ben Hermans/Hyperion):
>>>>>>>>>>>>>>>>>>>>>>>>>>>
We have nothing to hide.
<<<<<<<<<<<<<<<<<<<<<<<<<<<

The AROS team does... in fact AROS is just a cover project for the real OS!!! <Evil laugh>

:-D
Strong Genesi presence at Amiwest : Comment 231 of 327ANN.lu
Posted by Fabio Alemagna on 31-Jul-2003 15:45 GMT
In reply to Comment 191 (Hans-Joerg Frieden):
> - Memory-Mapped Files

In a shared address space, mmapping files is just a quicker alternative to copying it all into memory, hover it doesn't overcome the "side effects" of attemptin to load a, say, 2GB file into 512MB of available total memory: no space. For tiny files, mmapping is quite unneeded, better use a buffering mechanism.

> - Automatic stack enlargement

Again, how do you solve the issue of deallocating unused stack? Do you allow for non contiguous stack frames? If so, how? And if so, doesn't that break compatibility with everything but c-like function calls?
Strong Genesi presence at Amiwest : Comment 232 of 327ANN.lu
Posted by Hans-Joerg Frieden on 31-Jul-2003 16:22 GMT
In reply to Comment 219 (Bernie Meyer):
> how *do* you ensure that the area you expand into is not used by something
> else? Especially in the presence of mmap()ing files, which can easily gobble
> up large chunks of address space rather quickly?

Actually, you don't. The only thing you can try to do is start mapping stacks in their own memory segment far away from anything else. Eventually, you will have collisions, and in that case you cannot expand further.

Stacks allocate address space for their largest possible extents, which can be overridden by the application, and map pages into their area. Of course this doesn't work indefinitely, but that isn't a good thing anyway - endless recursion might kill off all of your pages.

As soon as private address spaces are involved, things will be a lot easier in this respect.

Actually, we're thinking about trying another method for stack enlargement which centers around the fact that SYS V stores the back pointer to the previous stack frame on the stack itself, so theoretically there can be arbitrary (even negative) gaps...). Problem is the 68k side of things... But for now, it's allocate-maximum and hope for a boing bag ;-)
Strong Genesi presence at Amiwest : Comment 233 of 327ANN.lu
Posted by Hans-Joerg Frieden on 31-Jul-2003 16:33 GMT
In reply to Comment 231 (Fabio Alemagna):
> In a shared address space, mmapping files is just a quicker alternative to
> copying it all into memory, hover it doesn't overcome the "side effects" of
> attemptin to load a, say, 2GB file into 512MB of available total memory: no
> space. For tiny files, mmapping is quite unneeded, better use a buffering
> mechanism.

A matter of taste and possibilities. Fact is that if you never start a feature it will not make it in no matter what. For the moment you have a shared address space and mmapping has certain limits, fact. However, it's not going to stay.

Mapping a 50 MB video file into memory for playback is still a possibility.

> Again, how do you solve the issue of deallocating unused stack? Do you allow > for non contiguous stack frames? If so, how? And if so, doesn't that break
> compatibility with everything but c-like function calls?

You deallocate unused stack in a low memory handler.

If you adhere to the ABI, you can have non-continous stack frames. The problem is really when this happens within the 68k part. You would need to assure that the 68k has enough stack space always, which will be rather difficult.

Obviously this is all not the final answer to all the questions, but you can only take as many steps, and some features will obviously only be fully explotable in the future. I don't see an overwhelming reason to delay them, especially if it is as fundamential as the virtual addressing.
Strong Genesi presence at Amiwest : Comment 234 of 327ANN.lu
Posted by Don Cox on 31-Jul-2003 17:04 GMT
In reply to Comment 232 (Hans-Joerg Frieden):
"As soon as private address spaces are involved, things will be a lot easier in this respect."

I hope there will be some way to mark older programs that expect a single address space so that they can still run with your future kernel. There are so few Amiga programs that we can't afford to lose any more - in fact, the aim should be to increase compatability with existing programs at the same time as adding advanced features.

One of the best things you have done is to add hooks which might be used for hardware (ie AGA) emulation.
Strong Genesi presence at Amiwest : Comment 235 of 327ANN.lu
Posted by Georg Steger on 31-Jul-2003 17:54 GMT
In reply to Comment 199 (Anonymous):
> Clumsy:
>
> Can't delete/rename files, complicated multiselect, looks awful.
>
> It should be rewritten to use MUI :)

AROS asl.library (which was ported to MorphOS, but I don't know
if they actually use it/whether it ships with it) does support
renaming/deleting files, as it basically clones all functionality
of AOS 3.9 asl.library.

And I don't think multiselect is complicated. Just hold down shift
to select more than one entry. You can also drag-select.

hold down shift
click and hold down LMB on first entry
move mouse down while still holding LMB and shift
--> selects all the entries you move over

And there is also the multiselect by pattern string requester,
as in AOS 3.9 asl.library.

"looks awful"? Well it looks better than AOS asl.library I think:

http://www.aros.org/pictures/screenshots/20010222/newfont.png

(In the MOS port I think they disabled the button images, as they
found this too windoze-like)
Strong Genesi presence at Amiwest : Comment 236 of 327ANN.lu
Posted by Don Cox on 31-Jul-2003 17:58 GMT
In reply to Comment 227 (DaveP):
"Its a hardware limitation Don. :-) As we go to 64 bit boards and the next Articia chipset something may get done about it."

Yes, I would expect so.
Strong Genesi presence at Amiwest : Comment 237 of 327ANN.lu
Posted by Don Cox on 31-Jul-2003 18:00 GMT
In reply to Comment 235 (Georg Steger):
""looks awful"? Well it looks better than AOS asl.library I think:

http://www.aros.org/pictures/screenshots/20010222/newfont.png"

It looks very nice to me. I hope there is a theme for AOS 4 that looks like this.
Strong Genesi presence at Amiwest : Comment 238 of 327ANN.lu
Posted by Matt Parsons on 31-Jul-2003 18:09 GMT
In reply to Comment 237 (Don Cox):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
""looks awful"? Well it looks better than AOS asl.library I think:

http://www.aros.org/pictures/screenshots/20010222/newfont.png"

It looks very nice to me. I hope there is a theme for AOS 4 that looks like this.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Um... and AROS theme for AOS4, anybody else feeling a sense of irony here? :-)
Strong Genesi presence at Amiwest : Comment 239 of 327ANN.lu
Posted by itix on 31-Jul-2003 18:19 GMT
In reply to Comment 235 (Georg Steger):
Hmm... my asl.library for MOS is rather old. Before MOS 1.1 release I think... Must investigate my MOS CD which I got with Pegasos some weeks ago. But I always loved those Windows stylish file requesters which are like mini file managers.
Strong Genesi presence at Amiwest : Comment 240 of 327ANN.lu
Posted by Anonymous on 31-Jul-2003 19:20 GMT
In reply to Comment 235 (Georg Steger):
>(In the MOS port I think they disabled the button images, as they
found this too windoze-like)

I doubt that, MorphOS developers seem to be very inclinded towards eye candy. And they overdo it a bit, if I may add, those transparent menus and shadows of a default MOS 1.3 installation are damn slow.

As to buttons with images in file dialogs, Windows doesn't have any (third party libs exluded, e.g. from Borland).

Btw, the images in the AROS screenshot are a bit problematic: the cancel button looks like the delete button used by almost every other (Windows-)application. And the OK button image may not exactly match the context. And the images may not match the look of the application. I think it's wise not to have images there.
Strong Genesi presence at Amiwest : Comment 241 of 327ANN.lu
Posted by Stefan Burström on 31-Jul-2003 19:22 GMT
In reply to Comment 211 (Bernie Meyer):
> But why should I bother Thomas about it?
I think the point Ben was trying to make is that speculating on these formums
quickly turn into a 'I know that this respectable developer said this in on
ANN so now we all know that AOS4 (or MOS for that matter) sucks in that aspect'
There is nothing wrong in speculating, but as soon as you are speculating
about problems, some people start to think there is a problem even if you
merely was curious about the solution to the problem.
Sad but true.

regards,
Stefan Burström
Strong Genesi presence at Amiwest : Comment 242 of 327ANN.lu
Posted by Daniel Miller on 31-Jul-2003 19:23 GMT
In reply to Comment 1 (Don Cox):
> First you say that MorphOS is so far ahead of AOS 4 that "it's not
> even funny", which is a highly pejorative comment. Then you say
> "let's leave the wars behind us". If you want to leave the wars
> behind, it would be best to be more careful with your comments.

I was in a rush, but I disagree that that the comment is pejorative. MorphOS runs on a PPC-only machine, and has for close to two years. It has been steadily refined ever since it was originally demonstrated on a Pegasos prototype in Italy in fall of 2001 IIRC. It was not my intention to criticize any other project, but the fact is that MorphOS and Pegasos are the only system that has successfully leapt that hurdle. Which after all is THE hurdle that requires leaping, to make the transition to all-new hardware while maintaining some continuity with the past. And in terms of performance? You want to set up some benchmarks between a 12 year old A4000 with Cyberstorm, and a Pegasos G3?! That is what we have to compare!

Maybe I could make my phrasing more delicate in addressing these obvious truths but it is silly for the sake of fairness to pretend that this chasm does not exist!
Strong Genesi presence at Amiwest : Comment 243 of 327ANN.lu
Posted by Ben Hermans/Hyperion on 31-Jul-2003 20:43 GMT
In reply to Comment 242 (Daniel Miller):
No offense Daniel but you do not want to retrench yourself behind the custom chipset dependencies of OS 4.

Rest assured that they will be gone before the end of the year.
Strong Genesi presence at Amiwest : Comment 244 of 327ANN.lu
Posted by André Siegel on 31-Jul-2003 21:35 GMT
In reply to Comment 240 (Anonymous):
"I doubt that, MorphOS developers seem to be very inclinded towards eye candy. And they overdo it a bit, if I may add, those transparent menus and shadows of a default MOS 1.3 installation are damn slow."

Do you run it on a BlizzardPPC? It absolutely *flies* on a Pegasos with G3/600.
Strong Genesi presence at Amiwest : Comment 245 of 327ANN.lu
Posted by Bernie Meyer on 31-Jul-2003 21:54 GMT
In reply to Comment 231 (Fabio Alemagna):
Fabio, I don't quite see the issue you have with deallocating stack. For any process, any previously used stack space now *below* the current stack pointer is considered to be subject to arbitrary changes, anyway. So any process that hands out (or uses) pointers to stack space below the current stack pointer is broken by design, and if it ever worked, it was a coincidence.As far as I can tell, stack space can be reclaimed as soon as the stack pointer gets moved above it again.Am I missing something?
Strong Genesi presence at Amiwest : Comment 246 of 327ANN.lu
Posted by Anonymous on 31-Jul-2003 22:40 GMT
In reply to Comment 79 (Fabio Alemagna):
>It's not something you can "forgive" for without the other party
>even acknowledging he was wrong, you know.

Being "wrong" is an opinion. I'm sure there are people you haven't apologized to nor ever you will because you think you're right while they think you're wrong.
Strong Genesi presence at Amiwest : Comment 247 of 327ANN.lu
Posted by Fabio Alemagna on 01-Aug-2003 07:06 GMT
In reply to Comment 233 (Hans-Joerg Frieden):
> You deallocate unused stack in a low memory handler.

The problem is, unless I'm missing something, that there's no way to know when it's safe to deallocate unused stack, because there's no way to know when the stack is unused: just think of programs implementing internally cooperative multitasking, or things like those.
Strong Genesi presence at Amiwest : Comment 248 of 327ANN.lu
Posted by Anonymous on 01-Aug-2003 07:20 GMT
In reply to Comment 244 (André Siegel):
>Do you run it on a BlizzardPPC? It absolutely *flies* on a Pegasos with G3/600.

No, using a G3/600. MOS 1.3 menus are quite a bit slower than other systems I am using (ie. Windows, emulated Amiga with OS3.5 menus, probably even classic Amigas wiht their black/white menus). Too slow for my taste. To put that into perspective: I expect menus to appear instantly, zero delay, snappy. I don't like lag at all, even if it's just some tenths of a second.

Btw, I guess it's not only the transparency/shadow issue but also the fact that they are not rendered like classic intuition menus, directly on the screen, locking out everything else (= fast), but like MagicMenu menus in system-friendly mode.
Strong Genesi presence at Amiwest : Comment 249 of 327ANN.lu
Posted by Fabio Alemagna on 01-Aug-2003 07:21 GMT
In reply to Comment 245 (Bernie Meyer):
> Fabio, I don't quite see the issue you have with deallocating stack. For any
> process, any previously used stack space now *below* the current stack pointer
> is considered to be subject to arbitrary changes, anyway. So any process that
> hands out (or uses) pointers to stack space below the current stack pointer is
> broken by design, and if it ever worked, it was a coincidence.
> As far as I can tell, stack space can be reclaimed as soon as the stack
> pointer gets moved above it again.
>
> Am I missing something?

I think you are: how about programs which implement cooperative multitasking internally? Besides, how can you detect when the stack is NOT used anymore, regardless of whether the stack pointer points to a valid stack frame or not?
Strong Genesi presence at Amiwest : Comment 250 of 327ANN.lu
Posted by Fabio Alemagna on 01-Aug-2003 07:23 GMT
In reply to Comment 246 (Anonymous):
> Being "wrong" is an opinion.

No, in this case it's a fact: it's either how Ben said it was, or it's not. If it's not, then he should apologize, and if it is as he said it was, then he should prove it or stay silent and act as if it was not.

> I'm sure there are people you haven't apologized to nor ever you will because
> you think you're right while they think you're wrong.

As said, this is not about opinions.
Anonymous, there are 327 items in your selection (but only 127 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 250] [251 - 300] [301 - 327]
Back to Top