@Tetisoft

i see users getting happy about being able to run finalwriter since last OS4 update.. i understand that.
but that's not the point.
my point was, if backward compatibility was achieved through sandboxes , emulation or virtualization,
compatibility would 99% ..well see uae, for example..
a linux machine running uae is having better backward compatibility than os4.

and uae is far from being the only solution.
the original morphos idea for exemple was quite interesting, except that in the process qbox felt into oblivion and abox is the only thing users gets to use..
the concept was interesting, but abox should have become like "classic" on macintosh.. a sandbox you run only when you want to run old software. most of the time native osx is used.

i'm not saying "classic" on mac is perfect.. for instance,
i would have liked to see it seemlessly embeded into native
osx windows.. not starting the whole macos9 desktop inside
macosx. but well i think that approach of sandbox or
emulation etc is better.

look at what mac gained .. better stability, less virus,
security .. this could be done on amiga too.. the amiga way..

so to come back with answering to your reply, with a sandbox approach users could run 99% of the old sofware and would be even more happy.

there's other approach, like sandboxes, emulation, or virtualization..

it's not opensource

and btw, hyperion doesn't seems to agree with your "view" of amigaos

so basicaly you're saying that amigaos to stay amigaos,
it shouldn't evolve and stay on the same bases it was 20 years ago ?
wow .. that's an interesting point of view..

how can we call that ? ultra conservative ? anti-progress ?

but for me evolution is important, the needs of 20 years
ago and the needs now in 2007 aren't the same, you gotta
keep up with your time, or you'll get called old fart or
things like this eventually..

but i'm saying amigaos can be crashed anytime by a bad app.

when will amigaos get unicode support?

con-handler is the wrong place to put UTF-8 support into.
This would have to be done in the place that actually deals
with putting control sequences, and sequences of characters
on the screen, and that's console.device, not con-handler.

Okay, that could explain things. Strange thing is that
U-Boot did find the Stelladaptor during boot, it is the
only thing connected permanently to USB ports, and 1 USB
device is reported found in the first U-Boot screen.

USB works fine here, finally my front ports are recognised
and Amigainput seems far more stable. Opening my sdcards
also seems a hell of a lot faster but warm reboot seems to
take alittle longer.

You should consider taking up this offer;
that's less work for you and the rest of the OS4 dev team.

My IRC client defaults to latin0 (or whatever I set as
default charset), but recognises utf8 as well when it sees
it. Ofcourse it can be tricked, but I've never seen that
happen unintentionally.

And yes, the need for mixing old charsets is there,
I frequently mix latin0 and cyrillic for example,
writing both russian and norwegian at once.
"8bit-apps" and codeset translation is not very usefull
since you're not able to, for example, transcode utf8 to
both latin0 and koi8-r at once.

Quote:

OS4 uses explicit charset tags for charsets since years and you suggest we should drop that and try to use UTF-8

Yes becose then you can copy any mixture of language in the
string textbox gadget whit caring what is what.

it bit useless is it not, but lets say you have some text
in UTF8 format, the old crappy program doesn't know its
UTF-8, but uses a old class tag for string gadget, the
SetAttrsA() won't make the accident converting the UTF-8
string to UTF-8 string corrupted.

Well I was reading the sdk:documentations/Autodocs /#?.gc
or some thing like that before computer stopped working,
did not notice any tags for UTF8 support for reading / setting
string attributes the gadgets.

Yes and No, we can't drop legacy can we, but its not
possible to persevere Unicode's in ASCII, the UTF8 most be
default format, any program that request ASCII using old
tags will get a converted ASCII string from the UTF8
original string, all buffers are freed when classes are
disposed off, ASCII buffer is provided when need, a simple
zero pointer until UTF8 most converted in ASCII and buffer
most be created.

In no way is it appropriate to add UTF-8 support as hack
that conflicts whit major parts of the OS, there for UTF-8
most be extended as optional feature that can be added to
supported components one by one, some thing that can be
used by any thing that supports it, but can not be used by
some thing that don't support it, there for support of
UTF-8 starting whit displaying UTF-8 text in simple way,
we are not taking about bullet API.

Well in that process you're losing lost of information,
better convert 64 bit UTF-8 display the chars directly.

Your option is some what hack if ask me, if like display
the text in the right format, first need analyze the UTF-8
data, to detect what language it typed, the switch code
page to correct format, as well as convert it 8bit, then
you can render the data and switch code page back to your
where using, from developers point of view does it?

Well one of your excuse I believe,

because you know UTF-8 will need to be extended system wide,
and you know it big job to add it.

It's not like can't convert UTF-8 back to 8bit using the
codepage before sending it over the serial port.

Again I don't se how this is relevant,
SSH and other shells can be supported,
simply char conversions from UTF-8.

UTF8 is not magic

it's easy detectable because of the way it encoded,
you can check if's valid format or not, if not is ASCII,
for storage it only required a zero terminated text string,
but problem is program requires ASCII (8 bit) and need to
read attributes from UTF-8 supported gadget class, the you
can't do that whit existing TAGS, there for explicit UTF-8
support tags most be added.

UTF8 support can be extended one class at time.

As for when i need UTF8, most notably when chatting via IRC.
It's irritating that it gets more and more common to get garbage
chars when friend type swedish characters.

I guess it would help to display some webpages better too.

If wookie and ibrowse would support UTF8.

-or- Added preliminary support for pages using UTF-8 encoding, mapping
back to windows-1252 for now

I think it's better to use UTF-7 because UTF-8 conflicts
whit ESC code sequences in AmigaDOS.

I think the funny part is tetisoft asking why would you need utf8 at all ;)

Same as memory protection right? who needs it anyway ?!

If I have downloaded a file from Sweden or Finland or some
other country, it should use original symbols in its file
name, not the symbols from CHARSET I'm currently using.

I was saying the con-handler, needs UTF-8 support ESC[ should be the same as CSI

Or else a deeper integration most be done where the ESC
code sequences becomes embedded in side UTF-8,
but then the shell system most be completely updated.