From: "Yuri Prokushev" <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Date sent: Tue, 30 Jul 2002 13:44:02 -0400 (EDT)
Priority: Normal
Subject: Re: [Sibyl] NLS
Send reply to: [EMAIL PROTECTED]
> >admittedly, I don't really know if they're somehow different from
> >normal strings currently).
> As I know, resourcesrting is real resource string, but placed to
> pascal source (like interface of classes for COM/CORBA, interface not
> really needed, just for easy writing)
See e.g. source of unit math - the resourcestring is directly placed
in the object file if compiled for the OS/2 target, no .res whatever.
> >> >> Disadvantages:
> >> >> 1) msg compiler required to make locales
> >> > Not really good, IMHO.
> >> But for your approach required linker and resource compiler.
> > Linker is needed anyway.
> For MSG files - no.
Of course, but for the rest yes.
> > Regarding resource compiler - well, this
> >one is _not_ really needed, at least not in the beginning (for this,
> >at least). However, we'll need resource compiler later anyway as well
> > - how would you store e.g. icons, bitmaps, etc., otherwise? OTOH,
> >creating a resource compiler shouldn't be that hard hopefully.
> You are looking from developers point of view. But for user esely
> don't think about developer's tools, like linker & rescompiler. For us
> resource compiler is required, of couse. If we'll use DLL then _each_
> program _must_be_ use DLLs for national language support. Bad. Very
> bad.
OK. You could link the resourcestrings to the executable just like
you want to do with .msg, so this isn't very different, in fact.
> >> I prefer to have english (international)
> >> messages stored into executable and, as optional, external message
> >> files. Native msg files allows to use as external as binded message
> >> files (refer to os2tk).
> > The same is true for resourcestrings, in fact.
> Right. But for DLL aproach linker & rescompiler (and may be
> pascompiler) are required. For MSG aproach only msg compiler is
> required.
As I already told, both resource compiler and linker will be needed
anyway, so this doesn't really count. OTOH, msg compiler wouldn't be
needed otherwise. See my other e-mail regarding this as well.
> BTW, we (I and Alex Smirnov) have a question. Currently
> system(sysos2)/syscalls units uses EMX's syscall interface. This is
> for EMX target only? For upcoming native OS/2 (without EMX) target
> EMXism will be removed? We prefer rewrite system/syscalls via OS/2
> API, not via EMX things.
Yes, of course. There'll be a new RTL directory. Fortunately, it can
be done successively (EMX.DLL is regular OS/2 DLL, so we can have
some parts native and still use some EMX functions temporarily for
the rest even after getting direct LX output). In fact, should
anybody want with creating the native RTL, I'll be very glad, because
I could concentrate on other things. Note, that there are already
native functions used sometimes when running under real OS/2, so it
only needs to remove if conditions with the branch used when running
under an extender in some cases.
Tomas
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe sibyl
end
