Loading LX (OS/2) binaries on Linux?
Timur Tabi
Linux? I want to work on a project that would allow Linux to load OS/2
programs, and the first task is to get the Linux loader to understand the LX
file format. Since I don't want to reinvent the wheel, I was wondering if
anyone is already working on it.
--
Timur Tabi, ti...@tabi.org
I am looking for a job as a device driver or BIOS developer in Austin, TX
Please read my resume at http://tabi.org/timur/resume.html
Andrew Graham
Some of the very early messages in the FreeOS egroup dealt with this idea.
You can find what there is on the topic at
http://groups.yahoo.com/group/freeos/messages/1
I'm not sure anyone planned out anything, or wrote any code.
BTW thanks for Watcom C++ the device driver tutorial you gave at Warpstock
Toronto.
Andrew Graham
Toronto
"Timur Tabi" <nospam...@tabi.org> wrote in message
news:gvzhegnovbet.g...@news-server.austin.rr.com...
John Reiser
> Linux?
It can already be done, assuming your system has binfmt_misc compiled-in
or as a kernel module. See /usr/src/linux/Documentation/binfmt_misc.txt .
Most recent Linux distributions have this as a module. Do "/sbin/insmod
binfmt_misc" (as root) to turn it on.
Basically, if you can get /usr/bin/file to identify LX files, then you can
arrange for binfmt_misc to execve() them as if they were invoked inside a
"#! my_LX_shell\n..." script, and you get to write `my_LX_shell'. So you
write an emulation of execve() for an LX file (using mmap, mprotect, etc.),
load your emulation using "-T my_LS_loader_script.lds" [do "/bin/ld --verbose"
to get the current default] to place your emulator at otherwise-unused
virtual addresses, and you're in business.
--
John Reiser, jre...@BitWagon.com
Timur Tabi
>Basically, if you can get /usr/bin/file to identify LX files, then you can
>arrange for binfmt_misc to execve() them as if they were invoked inside a
>"#! my_LX_shell\n..." script, and you get to write `my_LX_shell'. So you
>write an emulation of execve() for an LX file (using mmap, mprotect, etc.),
Thanks for the synopsis, but you're making it sound deceptively easy. The
part of "an emulation of execve() for an LX file" basically means I need to
write a program to parse the entire LX file format and load it into memory,
resolving all the
externals, etc. That's a lot of work, and that's why I asked. Has anyone
already done this work?
>load your emulation using "-T my_LS_loader_script.lds" [do "/bin/ld --verbose"
>to get the current default] to place your emulator at otherwise-unused
>virtual addresses, and you're in business.
Could you reword this part. I know I have a lot to learn to get this going,
but I understand the part about "-T my_LS_loader_script.lds".
Lew Pitcher
wrote:
>Does anyone know of any work done to load LX (OS/2 executable) binaries under
>Linux? I want to work on a project that would allow Linux to load OS/2
>programs, and the first task is to get the Linux loader to understand the LX
>file format. Since I don't want to reinvent the wheel, I was wondering if
>anyone is already working on it.
FWIW, OS/2 (up to and including v2.1) .EXE files were/are loadable and
executable in MSWindows. This might seem to be a non-sequitur, but it
does imply that "Wine" might be able to assist you. Since Wine's goal
is to reproduce MSWindows APIs and behaviour, they _might_ have
implemented MSWindows' OS/2 compatability logic.
Take a look at http://www.winehq.org/
Lew Pitcher, Information Technology Consultant, Toronto Dominion Bank Financial Group
(Lew_P...@td.com)
(Opinions expressed are my own, not my employer's.)
Simon Bowring
>Thanks for the synopsis, but you're making it sound deceptively easy. The
>part of "an emulation of execve() for an LX file" basically means I need to
>write a program to parse the entire LX file format and load it into memory,
>resolving all the
>externals, etc. That's a lot of work, and that's why I asked. Has anyone
>already done this work?
Timur,
I'd not be surprised if there's a hellava lot of work in here!
I'd try to find and talk to Mike Ruddy who wrote LXOPT. I spoke to
him about this once at some UK OS/2 user group p*ss-up, and he said
he had a *lot* of difficulty with this excellent program, due to
the poor documentation (quality and accuracy) of the IBM EXE file
format(s).
(Mike also complained that although the licensees of this program
read like a who's who of the industry, he never made much from it;
ISTR he said both MS and IBM licensed one whole copy of it, and IBM
optimised almost the whole of OS/2 with that single copy!)
What are you up to btw? ;-)
Simon
John Reiser
> into memory, resolving all the externals, etc. That's a lot of work ...
Some. But ELF ET_EXEC is not much different from LX, at least in concept.
Use the kernel's own fs/binfmt_elf.c as a guide. See also my user-mode
virtualization of ELF exec() in l_lx_elf.c at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/upx/cvsroot-upx/src/stub/ .
Investigate whether you can convert on-the-fly the LX runtime symbol table
into something that /lib/ld-linux.so.2 (the usual ELF PT_INTERP runtime
dynamic linker which supports ELF shared libraries) can use to do all the
"dirty work" for you. Checkout the utility programs readelf, objdump,
and objcopy which are part of the GNU binutils package. And of course
use a debugger such as gdb, with "set stop-on-solib-event 1".
> >load your emulation using "-T my_LS_loader_script.lds" [do "/bin/ld --verbose"
> >to get the current default] to place your emulator at otherwise-unused
> >virtual addresses, and you're in business.
>
> Could you reword this part. I know I have a lot to learn to get this going,
> but I [don't] understand the part about "-T my_LS_loader_script.lds".
In one obvious configuration, my_LX_shell will be another "program
interpreter" co-resident in the same address space with the LX executable
and other modules (LX libraries, ELF libraries, ld-linux.so.2, etc).
So you have to keep my_LX_shell out of the address ranges used by those
other modules. If my_LX_shell is an ET_EXEC file, then the default base
address of 0x08048000 may very well conflict with address space allocations
assumed by LX modules, or other ELF modules. If my_LX_shell is an ET_DYN
file, then the Linux kernel will choose an address to map it (frequently
0x40000000, 0x80000000, or 0x2aaab000) and you may not like what the
kernel chooses. It is possible to write a self-relocating program, but
usually it is easier just to pick a different region that will be
[nearly] always otherwise unused. The default base address 0x08048000
for an ET_EXEC file is set by the
. = 0x08048000 + SIZEOF_HEADERS;
statement in the default static bind script revealed by "ld --verbose".
To change the default, you must specify a different script, which is
done with "gcc -T my_script ...".
--
John Reiser, jre...@BitWagon.com
John Reiser
> and load it into memory, resolving all the externals, etc.
So I trust that you have looked to see if there already is a good enough
(or better) equivalent application available on Linux, or if the source
to the LX app could be recompiled or ported, etc. Consider also doing
an offline LX ==> ELF translation, then execve() the ELF file.
Offline translation benefits from having `readelf' to debug file format,
and makes it easier to use a debugger such as gdb. Of course,
watch out for things such as running the LX version of Presentation Manager
called from EMX; perhaps glibc + Xlib can do the work of both.
--
John Reiser, jre...@BitWagon.com
Timur Tabi
> FWIW, OS/2 (up to and including v2.1) .EXE files were/are loadable and
> executable in MSWindows. This might seem to be a non-sequitur, but it
> does imply that "Wine" might be able to assist you.
Thanks for the tip. I'll check it out, but I doubt it will help,
since OS/2 uses the LX format and Win32 uses the PE format. That's
why Project Odin (basically Wine for OS/2) comes with a PE->LX
converter.
ctr2...@yahoo.com
> > FWIW, OS/2 (up to and including v2.1) .EXE files were/are loadable and
> > executable in MSWindows. This might seem to be a non-sequitur, but it
> > does imply that "Wine" might be able to assist you.
> Thanks for the tip. I'll check it out, but I doubt it will help,
> since OS/2 uses the LX format and Win32 uses the PE format. That's
> why Project Odin (basically Wine for OS/2) comes with a PE->LX
> converter.
Wow, Timur, been a while since I've seen your name. I do think that
Wine is where you want to look. The PE and LX formats are virtually
identical once you get past the different headers; while I seem to
remember that the two could in theory differ hugely, in practice they
never do.
I did write an LX->ELF converter, but it was 3 or 4 years ago. It's
possible that some of the questions I asked are archived on Google and
will be of use to you. I made it to the point where I'd need to start
making an OS/2 compatability library, at which point the task became
too daunting for me. But considering that Win32 is more or less a
superset of OS/2's API, you should be able to save yourself from too
much wheel-reinvention.
--
Eric McCoy <ctr2...@yahoo.com>
"I woke up this morning and realized what the game needed: pirates,
pimps, and gay furries." - Rich "Lowtax" Kyanka
Michal Necasek
ctr2...@yahoo.com wrote:
>
> Wow, Timur, been a while since I've seen your name. I do think that
> Wine is where you want to look. The PE and LX formats are virtually
> identical once you get past the different headers; while I seem to
> remember that the two could in theory differ hugely, in practice they
> never do.
>
LX is tuned for i386 style machines. It is page oriented and it
has all those features like page compression... plus LX also
supports 16-bit segments.
- Mike
Michal Necasek
Simon Bowring wrote:
>
> I'd not be surprised if there's a hellava lot of work in here!
> I'd try to find and talk to Mike Ruddy who wrote LXOPT. I spoke to
> him about this once at some UK OS/2 user group p*ss-up, and he said
> he had a *lot* of difficulty with this excellent program, due to
> the poor documentation (quality and accuracy) of the IBM EXE file
> format(s).
>
floating around and some are rather outdated, not documenting all
fields.
However the LX format is now fairly well understood. Another tool
that digs deep into LX is the LxLite compressor.
Whatever the LX spec doesn't say can be determined through
experimentation :-)
> (Mike also complained that although the licensees of this program
> read like a who's who of the industry, he never made much from it;
> ISTR he said both MS and IBM licensed one whole copy of it, and IBM
> optimised almost the whole of OS/2 with that single copy!)
>
:-)
- Mike
ctr2...@yahoo.com
Well, this is what I meant by "in practice." An overwhelming majority
of executables I tested at the time had identical or nearly identical
settings. The only consistent exceptions were programs from IBM, in
particular those which came with OS/2. I remember this well because
it was a great relief to me at the time.
The special features LX has are, in my experience, rarely used.
Perhaps I just had an uneven cross-section of OS/2 apps for my
sample.
Timur Tabi
> However the LX format is now fairly well understood. Another tool
> that digs deep into LX is the LxLite compressor.
Mike, in your opinion, where can I find the best documentation of the
LX file format?
Michal Necasek
are several revisions of the LX spec floating around so one has to
pay attention. The latest I have seems to be this:
10-25-94 12:45 44,226 0 LXSPEC.INF
I also have:
LXEXE.DOC - really outdated, doesn't document the STACKSIZE header
field for instance
OMF.INF - newer, also documents OMF structure. Dated 4-26-93,
appears almost identical to LXSPEC.INF (as far as LX
format is concerned) but not quite.
There are some features such as page compression added in Warp 3 or
modified fixup table format new in Warp 4 that I have not seen
officially documented anywhere. LxLite source and its author(s)
might be the best source of information there.
- Mike
Achim Hasenmueller
I think there are other issues you would have to look into first before
trying
to design/implement an LX loader on Linux. Doing the loader is quite some
work
but it is definitely possible.
There are more fundamental issues. One is the requirement to load shared
data
and code at the same addresses in each address space. That is something that
Linux/Unix
do not provide. Unless you can guarantee this, it won't work.
Needless to say, I do believe much more in virtual machines :-)
Best regards,
Achim
Holger Veit
> Timur,
>
> I think there are other issues you would have to look into first before
> trying to design/implement an LX loader on Linux. Doing the loader is
> quite some work but it is definitely possible.
The loader itself is rather harmless, however, you'll also have to do the
LDT<->Flat mapping as in OS/2 for each process, even if you intend to
only load 32 bit executables - there is quite a lot leaking-through of
internal OS/2 kernel tables and module structures in the process.
> There are more fundamental issues. One is the requirement to load shared
> data and code at the same addresses in each address space. That is
> something that Linux/Unix do not provide. Unless you can guarantee
> this, it won't work.
This is pretty simple, because the former a.out shared libraries
loaded at fixed addresses. Clever use of mmap(2) is your friend there.
The problem is that you'll have to interact with current system libraries
(typically libc.so) to get access to system calls which you need for an
appropriate OS/2 kernel emulation. Difficulty is that these shared libs
are PIC libraries which are relocatable but have an incompatible interface
(you need some sort of thunks to call them). You don't have to reverse
engineer OS/2 GDT callgates, but you better look at the API you have to
provide before thinking about an LX loader. It is easier to emulate
Linux in OS/2 than vice versa with a Unix system that has rather ridiculous
process and thread management facilities.
Holger
--
Please update your tables to my new e-mail address:
holger.veit$ais.fhg.de (replace the '$' with '@' -- spam-protection)
Timur Tabi
>The problem is that you'll have to interact with current system libraries
>(typically libc.so) to get access to system calls which you need for an
>appropriate OS/2 kernel emulation. Difficulty is that these shared libs
>are PIC libraries which are relocatable but have an incompatible interface
>(you need some sort of thunks to call them).
I"m a a little confused now. I was planning on re-implementing all the
DosXxxx calls in Linux, so that when I load the LX EXE, the externals are
mapped to these Linux libraries. Is that what Odin does? I don't see where
the thunking needs to come in.
--
Timur Tabi
Remove "nospam_" from my email address when replying
Holger Veit
> On 30 Jan 2002 13:58:03 GMT, Holger Veit wrote:
>
>>The problem is that you'll have to interact with current system libraries
>>(typically libc.so) to get access to system calls which you need for an
>>appropriate OS/2 kernel emulation. Difficulty is that these shared libs
>>are PIC libraries which are relocatable but have an incompatible interface
>>(you need some sort of thunks to call them).
>
> I"m a a little confused now. I was planning on re-implementing all the
> DosXxxx calls in Linux, so that when I load the LX EXE, the externals are
Yes, the method is obvious: provide a shared library with all the Dos*
calls, get the OS/2 LX exe into memory, preferably with its native ELF
memory layout, and then fit the externals to the Dos* library. Besides
that the Dos* API is a rather tricky API which, beyond some trivial
File open/read/write/seek/delete/close operations, has some very obscure
properties that are hard to emulate correctly, the idea is pretty
straight forward. As said by Achim already, you have to remap the
variable memory layout of Linux processes to the fixed layout of OS/2
processes unless you want to deal with quite obscure bugs. This is
doable with a.out style shared libraries, but these are obsolete now.
If you don't consider the memory layout, your plain 10 line file copy
(DosOpen/DosRead/DosWrite/DosClose) binary may work, but a more
complex software might surprisingly fail due to lack of stack or lack
of heap or for other annoying effect. Since many apps also contain 16
bit code, you have to build the LDT<->Flat mapping, even if you don't
like it (Kbd/Vio/Mou/SessMgt doesn't work without).
> mapped to these Linux libraries. Is that what Odin does? I don't see where
> the thunking needs to come in.
PIC code uses a special calling convention to resolve externals on the fly;
the ld.so is involved in this. Although the %EBX register which is involved
in this is also a saved register in OS/2 for many compilers, don't expect
calling a PIC library from non-PIC code (this is what OS/2 binaries will
turn up to be in Linux process memory) will work straight. When Linux ld
links to a shared library, it will add a small adapter (which is not
much more than a load of %EBX and a indirect JMP to the actual shared lib
routine). Unfortunately, your loaded OS/2 binary does not have such a
stub, as PIC is not necessary by concept under OS/2. I called this
adapter code, similarly to OS/2's naming convention a thunk; actually
though it doesn't convert between 16 and 32 bit, but rather between
32 and 32 bit code. Your loader will also have to resolve this issue
somehow. Calling 16bit shared lib code is BTW another tricky issue;
you have to play with some assembler code there: not a trivial issue,
because the native GNU as doesn't know 16 bit segments; you might be
successful with Watcom wasm to generate ELF output, though, I haven't
tried that. IIRC, Wine attempts to resolve this problem by replacing
the external 16 bit references by own emulator calls, if they still
support 16bit code at all.
John Reiser
> ...
> PIC code uses a special calling convention to resolve externals on the fly;
> the ld.so is involved in this. Although the %EBX register which is involved
> in this is also a saved register in OS/2 for many compilers, don't expect
> calling a PIC library from non-PIC code (this is what OS/2 binaries will
> turn up to be in Linux process memory) will work straight. When Linux ld
> links to a shared library, it will add a small adapter (which is not
> much more than a load of %EBX and a indirect JMP to the actual shared lib
Um, no. "calling a PIC library from non-PIC code" is what a "main" a.elf
(ET_EXEC) executable does every time it calls any routine in libc.so.6
(which is an ET_DYN file), and it works just fine. The Program Linkage
Table (PLT) code does not alter %ebx. (If the PLT is in an ET_DYN file,
then the PLT code uses %ebx to address a location containing a pointer.)
Each PIC subroutine which references non-stack memory (globals or statics)
is responsible for establishing its own %ebx. If the PIC subroutine
is not externally callable (C 'static', and its address is not taken, neither
explicitly via '&' nor implicitly by appearing as an initializing element
in a table), then that subroutine can use the existing %ebx value from
its caller, which will be in the same ET_DYN file. But if a purely PIC
subroutine is externally callable (not C 'static', or its address was taken),
then it must use code such as:
pushl %ebx
call L10
L10: pop %ebx
add $ _GLOBAL_OFFSET_TABLE_ - L10, %ebx
or (better on i586 and up):
pushl %ebx
call [L20: movl (%esp),%ebx; ret] ## here "[...]" designates a literal
L10: addl $ _GLOBAL_OFFSET_TABLE_ - L10, %ebx
or (even better):
pushl %ebx
movl $ _GLOBAL_OFFSET_TABLE_ - L10, %ebx
call [L20: addl (%esp),%ebx; ret]
L10:
to establish addressability of non-stack memory. Alternately,
there is a "half-PIC" mode in which pointed-to code and data are
position independent, but the _GLOBAL_OFFSET_TABLE_ itself is at a
fixed address.
--
John Reiser, jre...@BitWagon.com
Achim Hasenmueller
I'm still not convinced that you can satisfy the requirements for a fixed
address space with memory areanas in Linux. Even if the a.out libraries
will be loaded at fixed address, how do you want to implement something
like this:
Process A:
PVOID sharedMem;
DosAllocSharedMem(.. &sharedMem,...)
DosGiveSharedMem(Process2...)
structure.field = sharedMem; // structure also shared mem but different
object
WinSendMsg(hwndOfProcess2, WM_CUSTOM_MESSAGE, (MPARAM)structure, 0);
Process B:
PVOID sharedMem = ((structure_type)mp1).field;
memcpy(sharedMem, ....)
Basically this sample shows that you need a shared arena and identical
virtual (linear)
addresses in all processes. Of course, you also need the proper LDT mappings
in order
to support 16bit. As you already stated, almost any program contains some
16bit stuff
because of some subsystems being 16bit and compilers generating thunks
automatically
under the covers.
One possibility would be to use a huge data object in an a.out library and
take this one
as a pool for your shared arena. Don't know if that is a feasable approach.
Regards,
Achim
Holger Veit
> Holger,
>
> I'm still not convinced that you can satisfy the requirements for a fixed
> address space with memory areanas in Linux. Even if the a.out libraries
> will be loaded at fixed address, how do you want to implement something
> like this:
>
> Process A:
>
> PVOID sharedMem;
> DosAllocSharedMem(.. &sharedMem,...)
>
> DosGiveSharedMem(Process2...)
>
> structure.field = sharedMem; // structure also shared mem but different
> object
>
> WinSendMsg(hwndOfProcess2, WM_CUSTOM_MESSAGE, (MPARAM)structure, 0);
>
> Process B:
>
> PVOID sharedMem = ((structure_type)mp1).field;
>
> memcpy(sharedMem, ....)
>
The main point on this is that you have to stay within the same process
domain, i.e. you can ensure unified memory arenas for all loaded OS/2
processes loaded on Linux, but you cannot (and won't) guarantee them
for non-OS/2 processes. The above AllocSharedMem/GiveSharedMem code
can be emulated by a middleman daemon which manages shared memory in
the shared arena for all involved OS/2 processes. This daemon knows
that process A has allocated some memory in the shared region, and will
map (maybe with the help of some IPC code in process B) it to the correct
location in process B. I don't say it is impossible - the OS2KRNL can also
maintain this - it is probably just ugly.
But as said: this won't work with non-OS/2 processes. This means that
OS/2 processes under Linux will (because of that kind of runtime system
involved) establish a subsystem (as the intended UnixOS2 system will
be under OS/2); this means the loaded OS/2 processes will require and
have certain properties that ordinary Linux processes don't have. Or,
in other words, don't believe that you just add some library with
Dos* calls to Linux, and then any Linux code could call DosCreateThread(),
for instance, and have proper multithreading.
That shared library will not be general purpose.
> Basically this sample shows that you need a shared arena and identical
> virtual (linear)
> addresses in all processes. Of course, you also need the proper LDT mappings
In the processes that are loaded by the Linux LX loader, yes.
> One possibility would be to use a huge data object in an a.out library and
> take this one
> as a pool for your shared arena. Don't know if that is a feasable approach.
This has to be enforced to be mapped to the address space below 512MB
(LDT requirement), so it already involves some sort of runtime support
which you could hide in the LX loader, or in a special ld.so; this will
push ordinary Linux apps out of the game.
Holger Veit
Thanks for the explanation. I have read a book about ELF PIC loading quite
some time ago, and apparently messed up the details a bit. So %EBX won't
be a problem.
However, when reading about the distinction between stack and non-stack
data, to me it comes to mind that (32bit) OS/2 processes have a flat
address space, but there is no real guarantee for DS/ES/SS (and definitely
not FS/GS which have a specific use in OS/2) are always flat. Mainly for
kernel drivers, but also under certain circumstances (usually, of course,
with 16 bit code), routines have to explicitly reload flat DS/ES. With
32 bit kernel drivers, you also specifically need to add an offset to DS/ES
addresses (called _TKSSBase) to access SS-based addresses through DS/ES.
OS/2 compilers either produce code with DS/ES fixed (EMX/gcc), or have
a pragma "_loadds" to ensure correct segment settings (proprietary
compilers). By default, OS/2 relies on CS=0x53 and DS/ES/SS=0x5B. Does
Linux code allow other GDT CS/DS/ES/SS selectors than its default ones
without kernel modifications, and doesn't touch the segment registers once
the process is launched in memory? And further question: how would the
above PIC logic work with 16:16 pointers (I am now becoming really curious
what the Wine programmers did to execute NE executables)?
John Reiser
> Linux code allow other GDT CS/DS/ES/SS selectors than its default ones
> without kernel modifications, and doesn't touch the segment registers once
> the process is launched in memory? And further question: how would the
> above PIC logic work with 16:16 pointers (I am now becoming really curious
> what the Wine programmers did to execute NE executables)?
On x86, the Linux kernel initializes the segment registers at execve()
[from "info reg" in gdb]:
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
The kernel never changes user-mode cs,ss,ds,es, and preserves whatever
values the user sets via lds/les/intersegment jump, etc. However,
at the time of a system call or delivery of a signal, the stack segment
probably must be a normal "32-bit" segment. In theory the kernel
never changes user-mode gs either [used by linuxthreads to support
thread-local storage], although in the last year there once was a
kernel bug which scribbled on gs. I'm not sure about the user-visible
behaviour of fs, which the kernel uses extensively to implement
memory access from inside the kernel, but with user-mode permissions.
To get "16-bit" segments, a process must use the modify_ldt() system
call, and is restricted to local segments only (bit 2, value 0x4, must
be set in the descriptor), and [of course] the [virtual] memory described
by the segment descriptor is just another view of [part of] the linear
address space of the process. Also there is vm86(), used by the 'dosemu'
application, which happily runs DOS executables, and can be used
to debug the x86 real-mode execution which occurs when booting Linux.
--
John Reiser, jre...@BitWagon.com
Sander van Leeuwen
> The main point on this is that you have to stay within the same process
> domain, i.e. you can ensure unified memory arenas for all loaded OS/2
> processes loaded on Linux, but you cannot (and won't) guarantee them
> for non-OS/2 processes. The above AllocSharedMem/GiveSharedMem code
> can be emulated by a middleman daemon which manages shared memory in
> the shared arena for all involved OS/2 processes. This daemon knows
> that process A has allocated some memory in the shared region, and will
> map (maybe with the help of some IPC code in process B) it to the correct
> location in process B. I don't say it is impossible - the OS2KRNL can also
> maintain this - it is probably just ugly.
But how can you emulate DosAllocThreadLocalMemory in Linux?
I'm not sure if this api is used often, but it is a rather unique
feature that I haven't
seen in any other OS yet.
Sander
Holger Veit
> On Wed, 30 Jan 2002 16:15:16, ve...@borneo.gmd.de (Holger Veit) wrote:
> But how can you emulate DosAllocThreadLocalMemory in Linux?
>
> I'm not sure if this api is used often, but it is a rather unique
> feature that I haven't
> seen in any other OS yet.
The question is rather: how do you get OS/2 style threading in Linux -
whole Unixish POSIX threading is a joke, and it won't improve by clone()
and other gimmicks. To the Linux readers: OS/2 and Linux/Unix differ
fundamentally in concept on process handling: in Linux, the scheduled
entity is a process (or a kernel thread), and you might find some way
to substructure a process to get the impression that it is threaded,
whereas in OS/2 the schedulable entity is a thread, and you might combine
several threads to a process. This difference has quite important
impacts on the scheduling and context switching mechanisms of both
systems. I know there is some effort to improve the shortcomings of
userland threads by kernel support, but there is still quite a lot of
work to do to get serious threading (without somehow falling back to
process scheduling) in Linux. Unix appears elegant with fork()/exec(),
but it was just conceptually not designed for post-substructuring.
Already post-superstructureing (process groups, sessions) as invented
later turns out to be a shot through the foot into the head, more
hack than design.
I suspect that Linux will only allow user threading like with portable
pthreads easily. In this case, you can have your fingers on the
thread structure; and thus you will also be able to do
DosAllocThreadLocalMemory in user mode. Going to kernel-based threads
will likely need some new system call.
A more interesting question is though how to manage per-thread
exception handling. OS/2's handling of signals and exceptions is
on one hand weaker as Unix signals (there are not many of them, and
the commonly used DosFlagProcess to emulate more of them is a
16bit-only API), and OTOH, exception handling per-thread is much
stronger than under Unix (besides signals, Unix does not have real
exception handling - C++ or Ada extensions are a weak excuse that
furthermore won't help to get this property implemented). There
I have no good idea, even not through userland threading, how to
implement this properly. It might be hacked somehow, maybe, but will
nested exceptions be dealt with correctly then - DosUnwindException,
particularly from 16 bit ring 2 code - a very nasty thing that is
not too well understood. Here comes John's comment elsewhere in
the thread: hopefully Linux does not too much rely on segment
registers to point to flat addresses; in exception handling they
could point anywhere (and FS is there surely a source for conflict:
in OS/2 FS:0 points to the per-process data table (something like
struct proc in Linux)).
Timur Tabi
> The question is rather: how do you get OS/2 style threading in Linux -
> whole Unixish POSIX threading is a joke, and it won't improve by clone()
> and other gimmicks. To the Linux readers: OS/2 and Linux/Unix differ
> fundamentally in concept on process handling: in Linux, the scheduled
> entity is a process (or a kernel thread), and you might find some way
> to substructure a process to get the impression that it is threaded,
> whereas in OS/2 the schedulable entity is a thread, and you might combine
> several threads to a process.
Holger, can you give an example of something that OS/2 can do that
Linux can't? I'm familiar with OS/2 threading, but I don't know Linux
threading enough to understand what makes it inferior. I've heard a
lot of people talk about this, but so far no one has been able to make
me understand it.
I'm also interested in hearing from the Linux camp about any threading
improvements that are coming.
ctr2...@yahoo.com
> Holger, can you give an example of something that OS/2 can do that
> Linux can't? I'm familiar with OS/2 threading, but I don't know Linux
> threading enough to understand what makes it inferior. I've heard a
> lot of people talk about this, but so far no one has been able to make
> me understand it.
The short version is that Linux emulates threads using cloned
processes (which share memory space). One consequence of this is that
signal handling is screwy, both in terms of "what you would expect"
and what the pthreads standard specifies. There are a ton of
generally-minor irregularities in the Linux implementation as well.
If I read Holger correctly, he was being very careful to talk about
"LinuxThreads" and not "POSIX threads;" that is, the Linux
implementation of POSIX threads. While there are obviously
differences between OS/2 (and Windows) threads and POSIX threads, the
bigger differences appear primarily in LinuxThreads.
> I'm also interested in hearing from the Linux camp about any threading
> improvements that are coming.
Last I'd heard, the official word from the LinuxThreads developers was
that none of the serious issues, like signal handling, are going to be
fixed. This has a lot of Unix developers really angry, but apparently
the structure of the kernel is such that it would be a _lot_ of work
to do POSIX threading correctly.
Holger Veit
> ve...@borneo.gmd.de (Holger Veit) wrote in message news:<slrna5ghf...@borneo.gmd.de>...
>> The question is rather: how do you get OS/2 style threading in Linux -
>> whole Unixish POSIX threading is a joke, and it won't improve by clone()
> Holger, can you give an example of something that OS/2 can do that
> Linux can't? I'm familiar with OS/2 threading, but I don't know Linux
> threading enough to understand what makes it inferior. I've heard a
> lot of people talk about this, but so far no one has been able to make
> me understand it.
The point signal and exception handling has already been mentioned
elsewhere; the difficulty is that some of the required properties
for both Linux and POSIX threads to work correctly are doable, but
require several severe changes in the Linux kernel (as said, Unix
in general was not designed with threads being the schedulable units
in mind.
Another weak area of the Unix API is file and record locking. That
it is problem is already indicated by the various incompatible
calls that have evolved over time in Unixes: lockf, flock, fcntl
(leave alone the effects you have when trying to do locking over NFS);
none of them are doing really stable file/record locking. Now that is
probably not the essential feature you need right from the beginning,
but you might in advance plan what can be done.
OS/2 has a wide range of semaphore (Event/Mutex/Mux) and IPC facilities;
Unix has the rather weak sem/msg/ipc set of functions. The sem/msg
functions are, because of being a former quick SYSV hack, not very
often used - I haven't encountered them more than perhaps a dozen time
at all in Unix programs; in OS/2 almost every kind of process
synchronization is done with semaphores. You need very good and stable
semaphore functions in threading as well; POSIX condvars and mutexes
are a low level compromise at best.
Think about DosEnter/ExitMustComplete (for Linux: critical regions);
and in particular when doing SMP. Unless Linux meanwhile will
be able to distribute threads among processors (it should at least and
at most for clone() threads), you'll be easily able to lockup the system
with well-written critical region handlers. It might need some easy
kernel support - but you don't want to solve this too well, for exactly
the lockup reason.
There are some other APIs that export kernel knowledge on processes,
like DosQueryProcType/Addr, DosQuerySysState, DosQueryModFromEIP,
DosGetInfoBlocks and the set of APIs dealing with process resources;
they can be rather intractable to do, but again, these are not essential
to have for each process right from the beginning.
Summary: Efectively, there is nothing that Linux can't do what OS/2 can
do, in principle, provided you add enough of the missing things to
the kernel (there are good reasons why certain things are in the OS/2
kernel - except these reasons to apply for Linux as well) - the question
is though, how much you will be allowed to fiddle with essential Linux
kernel structures (at least, since it is open source, in contrast to the
OS/2 kernel code, you would be able to modify the kernel for your own
purposes - whether it will then become common code is a different
question - see the ongoing discussion on Linux threading).
Lars Erdmann
should definitely use LXSPEC.INF, for example OMF.INF still defines a
resident/non-resident table string entry restriction of 128 bytes where
LXSPEC.INF now states its 255 bytes per string.
Through away omf.inf, use lxspec.inf.
Lars
Michal Necasek schrieb:
Alessandro Cantatore
nospam...@tabi.org (Timur Tabi) wrote:
>Holger, can you give an example of something that OS/2 can do that
>Linux can't? I'm familiar with OS/2 threading, but I don't know Linux
>threading enough to understand what makes it inferior. I've heard a
>lot of people talk about this, but so far no one has been able to make
>me understand it.
Are you planning to start writing a sort of open source clone
of OS/2 ?
Why linux then ? What about the other open source OS ? Are their
threading capabilities as bad as the linux ones ?
--
bye
Alessandro Cantatore
ctr2...@yahoo.com
> Are you planning to start writing a sort of open source clone
> of OS/2 ?
> Why linux then ? What about the other open source OS ? Are their
> threading capabilities as bad as the linux ones ?
"The" other open source OS? Are you lumping all the *BSDs together as
a single operating system?
Holger Veit
> @tin.it (Alessandro Cantatore) writes:
>
>> Are you planning to start writing a sort of open source clone
>> of OS/2 ?
>> Why linux then ? What about the other open source OS ? Are their
>> threading capabilities as bad as the linux ones ?
>
> "The" other open source OS? Are you lumping all the *BSDs together as
> a single operating system?
Effectively, they are the same. Concerning user mode apps, the relation
is similar to different Linux distributions: pure packaging issues.
Concerning kernel: if one group finds a serious problem, then the others
will fix it in their kernel variant as well. If you know the kernel source
of one *BSD, you don't have too much problems to understand the other
ones. This is different between for instance Linux and FreeBSD, although
both call themselves Unix clones.
Holger Veit
Unix was not built for multithreading from the ground up. This makes
it complicated to emulate this property. This holds for any dialect.
In contrast, OS/2 does not understand the fork()/exec() mechanism by
default. To emulate this on OS/2, is a problem of comparable complexity.
Richard Steiner
@tin.it (Alessandro Cantatore) spake unto us, saying:
>Are you planning to start writing a sort of open source clone
>of OS/2 ?
This would be interesting. :-)
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + BeOS + Linux + Solaris + Win95 + WinNT4 + FreeBSD + DOS + PC/GEOS
+ Fusion + vMac + Executor = PC Hobbyist Heaven! :-)
Buy Stacker? Why not just delete Windows?
Richard Steiner
spake unto us, saying:
>"The" other open source OS? Are you lumping all the *BSDs together as
>a single operating system?
Don't forget Hurd, guys. It's still out there, albeit in larval form.
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + BeOS + Linux + Solaris + Win95 + WinNT4 + FreeBSD + DOS + PC/GEOS
+ Fusion + vMac + Executor = PC Hobbyist Heaven! :-)
Dead Puppies aren't much fun...No, no, no...
Holger Veit
> Here in comp.os.os2.programmer.misc, ctr2...@yahoo.com
> spake unto us, saying:
>
>>"The" other open source OS? Are you lumping all the *BSDs together as
>>a single operating system?
>
> Don't forget Hurd, guys. It's still out there, albeit in larval form.
Forget Hurd. It is at least 10 years too late, and when it will be
finally finished, it will be technology that is not only 10 years old,
but outdated for 10 years.
Bob Eager
> ones. This is different between for instance Linux and FreeBSD, although
> both call themselves Unix clones.
Being pedantic, I'd say that Linux is a UNIX clone. BSD is UNIX!
(OK, strictly speaking it's not AT&T, but BSD was developed closely with
AT&T with a lot of cross-fertilisation over the years)
--
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2,
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..
Holger Veit
> On Fri, 1 Feb 2002 08:12:24, ve...@borneo.gmd.de (Holger Veit) wrote:
>
>> ones. This is different between for instance Linux and FreeBSD, although
>> both call themselves Unix clones.
>
> Being pedantic, I'd say that Linux is a UNIX clone. BSD is UNIX!
>
> (OK, strictly speaking it's not AT&T, but BSD was developed closely with
> AT&T with a lot of cross-fertilisation over the years)
BSD is BSD, not UNIX. The time of SYSV compatibility wars is long over,
but I am happy that BSD has not shared most of the major SYSV defects
in concept. POSIX is still suffering from the mess that followed the
AT&T "improvements" after the BSD/SysV schism.
Christopher Browne
> @tin.it (Alessandro Cantatore) writes:
>> Are you planning to start writing a sort of open source clone of
>> OS/2 ? Why linux then ? What about the other open source OS ? Are
>> their threading capabilities as bad as the linux ones ?
> "The" other open source OS? Are you lumping all the *BSDs together
> as a single operating system?
They all were based on the same BSD 4.4 Lite distribution, and there
has been a history of things patched in one turning out to need to be
patched in the others...
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/spreadsheets.html
BDOS ERROR ON A:
Timur Tabi
> Are you planning to start writing a sort of open source clone
> of OS/2 ?
In a word, yes. Of course, I won't be able to do it alone, but
someone has to start somewhere. I'm going to start with source-code
compatibility first, and then move to binary compatibility.
> Why linux then ? What about the other open source OS ? Are their
> threading capabilities as bad as the linux ones ?
I decided on Linux because it's the most "alive" of all non-MS
operating systems.
Alex Taylor
>> ones. This is different between for instance Linux and FreeBSD, although
>> both call themselves Unix clones.
>
>Being pedantic, I'd say that Linux is a UNIX clone. BSD is UNIX!
>
>(OK, strictly speaking it's not AT&T, but BSD was developed closely with
>AT&T with a lot of cross-fertilisation over the years)
But FreeBSD, NetBSD, OpenBSD etc. are not BSD UNIX(R).
FreeBSD is a ground-up clone of 4.4BSD, completely reimplemented
precisely because BSD was subject to the AT&T legal quagmire.
NetBSD and OpenBSD are, I believe, both project forks of FreeBSD.
--
--------------------------
Alex Taylor
al...@eddie.cis.uoguelph.ca
--------------------------
Christopher Browne
> On 01 Feb 2002 10:37:05 GMT, Bob Eager <rd...@spamcop.net> wrote:
>>> ones. This is different between for instance Linux and FreeBSD, although
>>> both call themselves Unix clones.
>>Being pedantic, I'd say that Linux is a UNIX clone. BSD is UNIX!
>>(OK, strictly speaking it's not AT&T, but BSD was developed closely
>>with AT&T with a lot of cross-fertilisation over the years)
> But FreeBSD, NetBSD, OpenBSD etc. are not BSD UNIX(R).
> FreeBSD is a ground-up clone of 4.4BSD, completely reimplemented
> precisely because BSD was subject to the AT&T legal quagmire.
> NetBSD and OpenBSD are, I believe, both project forks of FreeBSD.
Not quite.
- BSD386 was a version (for guess which architecture?) of BSD 4.4
"Lite."
- When AT&T got nasty about claiming there were infringements of their
code, two projects started, to make "quagmire-free" versions of
this:
-> One group took the 80386 path, and created FreeBSD;
-> Another group wanted to make it portable, and went down the
NetBSD path.
As a result, the fork you're implying was one that created BOTH
NetBSD and FreeBSD.
- Later on, Theo de Raadt was working on security fixes to NetBSD, but
the group determined that they couldn't all work together
successfully. Theo is wont to flame people Rather Vigorously,
doesn't suffer fools at all, and some of the NetBSD folks concluded
they couldn't work with him, and pushed him out. And so OpenBSD
came into being...
Quite entertainingly, I suspect the new Linux Standard Base
specification will allow (at the very least) FreeBSD, SCO Unix, and
likely Solaris to, without too much difficulty, claim conformance.
If that doesn't seem to make sense, then maybe you're stuck in the
mental rut of thinking that Linux has something to do with some
operating system kernel written by some Finnish fellow. Based on the
LSB, _it ain't so_.
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/linux.html
How much deeper would the ocean be if sponges didn't live there?
ctr2...@yahoo.com
> > Are you planning to start writing a sort of open source clone
> > of OS/2 ?
> In a word, yes. Of course, I won't be able to do it alone, but
> someone has to start somewhere. I'm going to start with source-code
> compatibility first, and then move to binary compatibility.
Not to be a pessimist, but why? There isn't much commercial
development on OS/2 any more, and there are open source equivalents of
nearly everything OS/2 has/had to offer. I think you would have much
more success by getting (former) OS/2 developers to release the source
for their OS/2-only programs, then porting them to Linux.
I dearly loved WPS, don't get me wrong; I'd love to see a non-bloated
equivalent for Linux. But it's got so much OS/2-specific API behind
it that I don't foresee you having much success with it.
You might be better-served by working to remedy some of the problems
Holger (and to a lesser extent I) have been mentioning. Fix some of
Linux's shortcomings, and add some functionality OS/2 has that Linux
doesn't. There are some OS/2-and-Windowsisms the kernel people won't
let you develop ("WaitForMultipleObjects()" or whatever it's called)
but for the most part I think they'll agree that more flexibility and
power is a good thing, no matter the original source.
John Poltorak
It's certainly 'alive' because of all the development which is going on in it. Yet, as
Holger pointed out the Linux kernel is not as mature as OS/2's. In fact major changes
as still being made to it which is a sure sign of instability for the next few years.
Now if you consider what Holger is designing - a Unix-like kernel for OS/2, then all
that development taking place on apps for Linux would also benefit us running OS/2
since we would have a good chance of being able to run the same apps.
Most people running Linux would not be interested in running OS/2 apps, so I doubt
whether there would be much interest in what you are trying to do. However if you got
involved in trying to develop OS/2 as a host for Open Source Software many more
people would appreciate your efforts. I'm sure you would be able to port ALSA to OS/2
so that we could benefit from any sound drivers written for Linux..
--
John
Holger Veit
[...]
>> FreeBSD is a ground-up clone of 4.4BSD, completely reimplemented
>> precisely because BSD was subject to the AT&T legal quagmire.
>
>> NetBSD and OpenBSD are, I believe, both project forks of FreeBSD.
>
> Not quite.
>
> - BSD386 was a version (for guess which architecture?) of BSD 4.4
> "Lite."
No, this was called 386bsd, offered by the person who developed the
initial 386 port on 4.4BSD. This has been Bill Jolitz. The port came
up and public the time when the CSRG at Berkeley lost funding and threw
an almost AT&T free version of 4.4BSD on the "market". Unfortunately
that 4.4BSD lite was incomplete, in that essential code fragments
that belonged to AT&T were missing. Bill, with intimate knowledge
of the original system rewrote the missing parts to get a running
system (386bsd 0.0, then 0.1, which was almost usable). Then the first
schism in the BSD community happened: Bill wasn't really interested
in a stable and improved BSD, but more in continuing research and
educational work - more a competitor to Minix than a real world
system. Also several design issues were regarded by some people as
ugly hacks, and Bill was reluctant to remove them. Based on the open
source and public code of 386bsd (nota bene: BSD is really free
for anyone), a group formed to make a better BSD than 386bsd and
called it FreeBSD (implying not only "free of AT&T code", but IMHO more
"free of Jolitz hacks").
Other people from the former CSRG planned not only to continue the
popular 386 thread of BSD, but actually all platforms that existed
in 4.4BSDlite, which were as crippled as the original 4.4BSD (due to
removal of "tainted" AT&T code). This was the beginning of NetBSD.
A third group tried to commercialize BSD and founded BSDI, Inc. in
Falls Church, VA.
Later in the time, one prominent member of BSD, Theo de Raadt, spawned
off, after heavy disputes, an own variant of FreeBSD, named OpenBSD,
targeted at high security and reliability which he thought would not
be represented appropriately in FreeBSD.
> - When AT&T got nasty about claiming there were infringements of their
> code, two projects started, to make "quagmire-free" versions of
> this:
>
> -> One group took the 80386 path, and created FreeBSD;
> -> Another group wanted to make it portable, and went down the
> NetBSD path.
>
> As a result, the fork you're implying was one that created BOTH
> NetBSD and FreeBSD.
>
> - Later on, Theo de Raadt was working on security fixes to NetBSD, but
> the group determined that they couldn't all work together
> successfully. Theo is wont to flame people Rather Vigorously,
> doesn't suffer fools at all, and some of the NetBSD folks concluded
> they couldn't work with him, and pushed him out. And so OpenBSD
> came into being...
> Quite entertainingly, I suspect the new Linux Standard Base
> specification will allow (at the very least) FreeBSD, SCO Unix, and
> likely Solaris to, without too much difficulty, claim conformance.
The result of an attempt to serve too many masters will IMHO rather
lead to the problem that the system will become stale and unmaintainable
in the sense that you can no longer change or add features because
that is going to break legacy software of some big players; and
if IBM, Oracle, or SAP will push Linux as a commercial platform,
chances are that experiments like the various cursed 2.4.x kernels
won't be possible any longer in the future. This has happened to
the OS/2 kernel before - it is full of compatibility hacks for software
which normal users have never seen, but which enterprises insist on
still using - you can't get rid of such garbage. Anything will
break anywhere.
> If that doesn't seem to make sense, then maybe you're stuck in the
> mental rut of thinking that Linux has something to do with some
> operating system kernel written by some Finnish fellow. Based on the
> LSB, _it ain't so_.
The Finnish fellow should better have kept control of that system.
Timur Tabi
> Not to be a pessimist, but why? There isn't much commercial
> development on OS/2 any more, and there are open source equivalents of
> nearly everything OS/2 has/had to offer.
I'm not going to discuss OS advocacy issues, especially on this
newsgroup. My project is for current OS/2 users. If you're not a
current OS/2 user, then I'll never be able to explain to you why I'm
doing this.
Will Honea
wrote:
> Unix was not built for multithreading from the ground up. This makes
> it complicated to emulate this property. This holds for any dialect.
> In contrast, OS/2 does not understand the fork()/exec() mechanism by
> default. To emulate this on OS/2, is a problem of comparable complexity.
Holger, the threading model has been one of the major drawbacks of
Linux for me. I thought I saw considerable discussion a while back -
year or more - about the development of a new native threading model
for Linux. Did this fall in a hole, was it just a pretty-up work, or
did they just clean up the poor model that already existed?
--
Will Honea <who...@codenet.net>
Richard Steiner
ve...@borneo.gmd.de (Holger Veit) spake unto us, saying:
>Richard Steiner <rste...@visi.com> wrote:
>> Don't forget Hurd, guys. It's still out there, albeit in larval form.
>
>Forget Hurd. It is at least 10 years too late, and when it will be
>finally finished, it will be technology that is not only 10 years old,
>but outdated for 10 years.
You're probably right. Too damn ssssllllooooowwww. :-(
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + BeOS + Linux + Solaris + Win95 + WinNT4 + FreeBSD + DOS + PC/GEOS
+ Fusion + vMac + Executor = PC Hobbyist Heaven! :-)
All those updates, and still imperfect!!!
Holger Veit
Seconded. Your work is complementary to what I am attempting. Both
areas have IMHO their specific "markets". Likewise to XFree86/OS2 which
is not of general use for any OS/2 user, neither OS/2 on Linux nor
Unix on OS/2 are discussable concerning their usability by people
who are not "inside".
Holger Veit
I don't see real considerable progress there. Threading in general
has a very hard position under Unix - there are few to no applications
that take advantage of it (GUI design which could be one issue is
already done well through the X11 event callback model); client/server
programming is better done by fork() which is meanwhile highly performant
compared to original UNIX implementations. Besides the degree of
parallelism in a process is very low under Unix - it is a vicious
circle: noone is accustomed to this because there is no rock solid
implementation, and it won't get stable as long as there are sufficient
alternatives to work around that.
Alessandro Cantatore
>Most people running Linux would not be interested in running OS/2 apps, so I doubt
>whether there would be much interest in what you are trying to do. However if you got
>involved in trying to develop OS/2 as a host for Open Source Software many more
>people would appreciate your efforts. I'm sure you would be able to port ALSA to OS/2
>so that we could benefit from any sound drivers written for Linux..
The problem is that in few years you won't be able to run OS/2 on new PCs
USB 2.0 is already here, serial ATA will follow soon and many new hardware
standards will come in the near future...
I don't think there is any great hope to get any real support from IBM...
I still have some hope that Serenity Systems can get something from them, but
I'm quite pessimistic... (no offence is intended for the Serenity guys, I
appreciate their effort)
Although I appreciate all the work of those people who are trying to make OS/2
support alien software (linux/win32), I think that at this stage this doesn't
make so much sense... not any longer...
Since I have to switch to another OS, sooner or later, if I needed linux or
win32 (or mac OS X) applications, I would just stop using OS/2 right now
rather than running them on OS/2 (if and when it would be possible to do that)
for no longer than a couple of years
OS/2 has a lot of defects, still I find it much more usable than linux or
windows... while I find that Windows 2000 (but I run it just for few hours in
a not networked machine) is more stable than OS/2, I still prefer OS/2 and
I would really be very disappointed if, in a couple of years, I won't any longer
be allowed to run OS/2 on my next PC and had to switch to windows or another OS
I know that, while there is a lot of interest regarding linux, there is no interest
regarding OS/2, but that is mainly because OS/2 is not an open source OS...
(and it is quite expensive too)... probably if a free OS/2 clone were available
it might reach as good consense as linux (or even more since linux is not exactly
the best for the desktop)
I don't know if that would ever be possible, but I'd like if we were able to
join our forces to develop an open source OS/2 like (less current OS/2 limitations)
clone...
--
bye
Alessandro Cantatore
Alessandro Cantatore
nospam...@tabi.org (Timur Tabi) wrote:
>> Are you planning to start writing a sort of open source clone
>> of OS/2 ?
>
>In a word, yes. Of course, I won't be able to do it alone, but
>someone has to start somewhere. I'm going to start with source-code
>compatibility first, and then move to binary compatibility.
I'd like to contribute, but I know nothing about kernels or device
drivers... probably might do something about an open PM clone...
>> Why linux then ? What about the other open source OS ? Are their
>> threading capabilities as bad as the linux ones ?
>
>I decided on Linux because it's the most "alive" of all non-MS
>operating systems.
That's a good reason expecially if you take into account hardware
support...
Would it be possible to modify the linux kernel, even at the cost
of losing some linux comptability, to add real multithreading,
while still keeping compatability at a driver level?
What about wine (Or lindows)? Don't win32 programs use multithreading
as OS/2?
--
bye
Alessandro Cantatore
Alessandro Cantatore
>> Why linux then ? What about the other open source OS ? Are their
>> threading capabilities as bad as the linux ones ?
>
>"The" other open source OS? Are you lumping all the *BSDs together as
>a single operating system?
I meant the other open source OSs - i.e. plural... just forgot the s,
but later I wrote "their threading capabilities" so it should have been
clear...
BTW I know that there are various other open source OSs besides darwin
and the BSDs I just know nothing about them (it wasn't a rhetorical question,
but a real question!)
--
bye
Alessandro Cantatore
Holger Veit
> In article <3C5AFD3B...@eyup.org>, John Poltorak <j...@eyup.org> wrote:
>
> >Most people running Linux would not be interested in running OS/2 apps, so I doubt
> >whether there would be much interest in what you are trying to do. However if you got
> >involved in trying to develop OS/2 as a host for Open Source Software many more
> >people would appreciate your efforts. I'm sure you would be able to port ALSA to OS/2
> >so that we could benefit from any sound drivers written for Linux..
>
> The problem is that in few years you won't be able to run OS/2 on new PCs
> USB 2.0 is already here, serial ATA will follow soon and many new hardware
> standards will come in the near future...
USB2.0 support is on the way in OS/2, and serial ATA is crap, but
nevertheless *supportable*. So where is there any point? If some other
open source system demonstrates how to talk to a device, then it is
possible to write drivers for OS/2, if there is interest from the
community. I simply won't buy junk like X-Boxes for professional
computing, even if the whole world thinks it were the best like
sliced bread.
Besides, there were/are long periods when even Linux didn't support
(unless you grab some obscure unstable patched kernel from the net)
essential hardware found in modern systems: ATA100 comes to mind,
certain non-standard PCMCIA devices, digital cameras, several new video
adapters - there are hacks somewhere now, but if you want to unpack&run
from some distribution CD, you are typically SOL.
> I don't think there is any great hope to get any real support from IBM...
Who still cares about IBM?
> Although I appreciate all the work of those people who are trying to make OS/2
> support alien software (linux/win32), I think that at this stage this doesn't
> make so much sense... not any longer...
Who cares about your opinion? What timur on one side, and I on some other
front try to accomplish, is not targeted at your personal benefit. Some
others might think different.
Martin Kiewitz
wrote:
> community. I simply won't buy junk like X-Boxes for professional
> computing, even if the whole world thinks it were the best like
> sliced bread.
X-Box is going bad.
The first time that Mickeysoft came into a marketplace, where better
products are already available and other companies have much more
experience in marketing and selling them. They can't force users to
buy their product this time. People know Mickeysoft quality products
already and M$ can't make up anything using their great marketing.
Even their commercials are flopping. I mean look at that console. Big
fat ugly black box (like Windoze ;). No USB-support for mice nor
keyboard.
And I believe Sony is not as dumb as IBM were in 1994-95.
Imho they don't have any chance. Eurpean price is much too high,
Japanese won't buy an american console and the X-Box already flopped
in USA. Games are far from being great and it's restricted PC
architecture anyway.
PlayStation for example is backward-compatible and the next-gen will
be backward-compatible as well. That's something Mickeysoft will never
accomplish (just look at Windoze <g>).
cu, Kiewitz
--
-> reply to mar...@kiewitz.de, if you are not spamming =)
Alessandro Cantatore
ve...@borneo.gmd.de (Holger Veit) wrote:
>> Although I appreciate all the work of those people who are trying to make OS/2
>> support alien software (linux/win32), I think that at this stage this doesn't
>> make so much sense... not any longer...
>
>Who cares about your opinion? What timur on one side, and I on some other
>front try to accomplish, is not targeted at your personal benefit. Some
>others might think different.
I didn't intend to offend you or anybody else. You may completely disagree
with my opinions, but I don't see any reason for such a reply.
--
bye
Alessandro Cantatore
ctr2...@yahoo.com
> >> Although I appreciate all the work of those people who are trying to make OS/2
> >> support alien software (linux/win32), I think that at this stage this doesn't
> >> make so much sense... not any longer...
> >
> >Who cares about your opinion? What timur on one side, and I on some other
> >front try to accomplish, is not targeted at your personal benefit. Some
> >others might think different.
> I didn't intend to offend you or anybody else. You may completely disagree
> with my opinions, but I don't see any reason for such a reply.
I don't think he was trying to convey the tone he ultimately did.
Based on his email address, English might not be his native language
(and based on your email address, it might not be yours either).
It's good policy not to read anything into posts unless you are really
familiar with the author's writing. Just imagine HAL reading it in a
soft monotone; that should smooth over any perceived offensiveness.
Holger Veit
> @tin.it (Alessandro Cantatore) writes:
>
>> >> Although I appreciate all the work of those people who are trying to make OS/2
>> >> support alien software (linux/win32), I think that at this stage this doesn't
>> >> make so much sense... not any longer...
>> >
>> >Who cares about your opinion? What timur on one side, and I on some other
>> >front try to accomplish, is not targeted at your personal benefit. Some
>> >others might think different.
>
>> I didn't intend to offend you or anybody else. You may completely disagree
>> with my opinions, but I don't see any reason for such a reply.
>
> I don't think he was trying to convey the tone he ultimately did.
> Based on his email address, English might not be his native language
> (and based on your email address, it might not be yours either).
To follow up on this: you are right that English is not my native language,
but I do reply intentionally harsh on *this particular kind of critics*
because I know this type and tone for more than a decade (it is in the
line of "OS/2 is dead"). It is not a simple opinion, but destructive
critics, usually soon later followed by a "well meant recommendation"
what I am supposed to do according to the commenter. Timur has the
idea to run OS/2 apps on Linux. We can debate on whether this is
technically possible or not, or how difficult this might turn out to
be; and maybe he then concludes that it would be not worth the effort
or, contrary, regards it as a personal challenge. But it remains his
decision how he wants to spend his lifetime.
But besides technical concerns, noone is interested what Alessandro
or others think about the success of such a project. They can
contribute if they like, otherwise it is not their game or their
project, and they don't have any right to judge about it. Noone here
is forced to use neither OS/2 nor OS/2 apps under Linux or anything
else.
A community model of work assignment does not function: the community
discusses what an individual is supposed to program for them, and the
individual then executes the task. Such a model is hidden behind some
request (or opinion) "it does not make any sense any longer to port
OS/2 to Linux", with the unspoken sentence "I'd rather like you to
write XYZ because that is what I want to have from you". The model
rather is: I produce something I consider worthwhile for me - maybe
you would like to try it out; this is how Linux was created and did
evolve. Might well be that OS/2 for Linux will be a failure or mistake
but who can know that by now?
To repeat: don't attempt to control what the active developers (which
are in this way more artists than engineers) are trying to accomplish;
you'll rather destroy a potential future artwork than profit from it.
If you like a personal artwork for your living (room), go buy one,
or better become an artist yourself.
Timur Tabi
> I don't know if that would ever be possible, but I'd like if we were able to
> join our forces to develop an open source OS/2 like (less current OS/2 limitations)
> clone...
Well, that's what I'm trying to do. The goal is to get Linux to load
OS/2 binaries, so that we could make a "new" OS/2 by replacing the
OS/2 kernel with the Linux kernel. I can imagine Serenity, for
instance, shipping a product like this. It would still require an
OS/2 license, but at least it would support A LOT more hardware. With
this new hybrid OS, there would be no need to port Linux apps to OS/2
any more. OS/2 programmers could then either work on original, native
OS/2 apps, or help me rewrite the OS/2 API as open source.
Eventually, the entire OS would be open source, and IBM would be
completely out of the loop, but OS/2 users would still be able to use
their OS/2 apps on an OS that may not technically be OS/2, but would
look and act (hopefully) just like it.
John Poltorak
> @tin.it (Alessandro Cantatore) writes:
>
> > >> Although I appreciate all the work of those people who are trying to make OS/2
> > >> support alien software (linux/win32), I think that at this stage this doesn't
> > >> make so much sense... not any longer...
> > >
> > >Who cares about your opinion? What timur on one side, and I on some other
> > >front try to accomplish, is not targeted at your personal benefit. Some
> > >others might think different.
>
> > I didn't intend to offend you or anybody else. You may completely disagree
> > with my opinions, but I don't see any reason for such a reply.
>
> I don't think he was trying to convey the tone he ultimately did.
> Based on his email address, English might not be his native language
English is *my* native language, but I wish I had as good a command over it as Holger.
Basically he doesn't have that much time for people who criticise the work of others
especially when it is freely offered to anyone who cares to use it.
> --
> Eric McCoy <ctr2...@yahoo.com>
>
> "I woke up this morning and realized what the game needed: pirates,
> pimps, and gay furries." - Rich "Lowtax" Kyanka
--
John
Alessandro Cantatore
ve...@borneo.gmd.de (Holger Veit) wrote:
>To follow up on this: you are right that English is not my native language,
>but I do reply intentionally harsh on *this particular kind of critics*
>because I know this type and tone for more than a decade (it is in the
>line of "OS/2 is dead"). It is not a simple opinion, but destructive
>critics, usually soon later followed by a "well meant recommendation"
>what I am supposed to do according to the commenter. Timur has the
I was just suggesting that we should better join our forces to
create a free open source OS/2 ...
Is this "destructive critics" ???
--
bye
Alessandro Cantatore
Alessandro Cantatore
This would be great... and was exactly what I meant when I wrote that
message that made Holger Veit so angry (but again, no offence or destructive
critics was and is intended)
--
bye
Alessandro Cantatore
Timur Tabi
> I'd like to contribute, but I know nothing about kernels or device
> drivers... probably might do something about an open PM clone...
PM is way down the road. I would need help rewriting the core DosXxxx
API first. However, my first task will be to write an LX parser for
Linux.
> Would it be possible to modify the linux kernel, even at the cost
> of losing some linux comptability, to add real multithreading,
> while still keeping compatability at a driver level?
Anything is possible, provided there are enough knowledgeable people
who will do the work.
> What about wine (Or lindows)? Don't win32 programs use multithreading
> as OS/2?
Yes, they do, which is why I'm confident that this idea will work.
Nix
> To follow up on this: you are right that English is not my native language,
> but I do reply intentionally harsh on *this particular kind of critics*
> because I know this type and tone for more than a decade (it is in the
> line of "OS/2 is dead").
A rephrasing which might fit better what you and Timur are trying to
accomplish:
`OS/2 is dead; long live OS/2!'
This thread's giving me quite a lift, I must say; the thought of
something like the WPS arriving on Linux, even if in the far future, is
definitely uplifting. And all that OS/2 software I used to be able to
run very slowly, brought back to life on a faster machine...
I applaud.
> or better become an artist yourself.
That's what this is, oh yes; like the Hercules project, only more;
artistry.
--
`However, if you want to detect whether (say, 1 in 1000) cars are being
abducted by bunnies along their route, you've got a whole new problem.'
- Scott James Remnant on network problems
Eric P. McCoy
> This thread's giving me quite a lift, I must say; the thought of
> something like the WPS arriving on Linux, even if in the far future, is
> definitely uplifting.
Same here. In the interests of meeting ongoing development efforts
halfway, I would probably rather see the WPS ported to GNOME. This
thread happened about a month too late; I believe GNOME 2.0 is already
in the code freeze (and will be for the next 3 months), but who knows?
OK, I admit it. A large part of my desire is to see _something_
replace Nautilus as the de facto standard GNOME desktop manager.
Nautilus is trash. It's inferior even to gmc, and I wish I could
figure out why gmc won't even run on my computer any more.
> And all that OS/2 software I used to be able to run very slowly,
> brought back to life on a faster machine...
Most of the OS/2 software I ran either sucked or was a port of
something from Unix, sadly. Actually, that email client that shipped
with OS/2 was way ahead of its time: it only sucked because it needed
twice the resources that were standard at the time.
John Poltorak
> On 5 Feb 2002, Holger Veit stated:
> > To follow up on this: you are right that English is not my native language,
> > but I do reply intentionally harsh on *this particular kind of critics*
> > because I know this type and tone for more than a decade (it is in the
> > line of "OS/2 is dead").
>
> A rephrasing which might fit better what you and Timur are trying to
> accomplish:
>
> `OS/2 is dead; long live OS/2!'
>
> This thread's giving me quite a lift, I must say; the thought of
> something like the WPS arriving on Linux, even if in the far future, is
> definitely uplifting. And all that OS/2 software I used to be able to
> run very slowly, brought back to life on a faster machine...
Why not put OS/2 on a faster machine and then you will have WPS now!
My guess is that Unix on OS/2 will be here quicker than WPS on Linux.
>
> I applaud.
>
> > or better become an artist yourself.
>
> That's what this is, oh yes; like the Hercules project, only more;
> artistry.
>
> --
> `However, if you want to detect whether (say, 1 in 1000) cars are being
> abducted by bunnies along their route, you've got a whole new problem.'
> - Scott James Remnant on network problems
--
John
Alessandro Cantatore
>> I'd like to contribute, but I know nothing about kernels or device
>> drivers... probably might do something about an open PM clone...
>
>PM is way down the road. I would need help rewriting the core DosXxxx
>API first. However, my first task will be to write an LX parser for
>Linux.
I know... unfortunately I can't do much to help on the low level stuff...
I was planning to write some open source replacement for some OS/2
PM controls to add some more features and to write some new controls...
This might be useful in future...
>> Would it be possible to modify the linux kernel, even at the cost
>> of losing some linux comptability, to add real multithreading,
>> while still keeping compatability at a driver level?
>
>Anything is possible, provided there are enough knowledgeable people
>who will do the work.
I wonder if there are any former OS/2 developers in the linux community...
may be you might ask for help there as well...
>> What about wine (Or lindows)? Don't win32 programs use multithreading
>> as OS/2?
>
>Yes, they do, which is why I'm confident that this idea will work.
I really hope so...
--
bye
Alessandro Cantatore
ctr2...@yahoo.com
> I wonder if there are any former OS/2 developers in the linux community...
> may be you might ask for help there as well...
Timur wrote the real-time MIDI drivers for OS/2, didn't he?
geo...@xspamx.amtechdisc.com
>> and I wish I could
>figure out why gmc won't even run on my computer any more.
This is the problem with linux... Since dumping linux I miss
some features, like real multi-user, but it was too complex
getting things to work. And I was never able to get any
readable fonts when using Netscape, so reading sites like
groups.google.com for bug fixes was painful.
george
ctr2...@yahoo.com
> >> and I wish I could
> >figure out why gmc won't even run on my computer any more.
> This is the problem with linux... Since dumping linux I miss
> some features, like real multi-user, but it was too complex
> getting things to work. And I was never able to get any
> readable fonts when using Netscape, so reading sites like
> groups.google.com for bug fixes was painful.
Mozilla and derivatives (like Galeon) have excellent font rendering.
With antialiasing if you've got that patch installed.
Timur Tabi
> @tin.it (Alessandro Cantatore) writes:
>
> > I wonder if there are any former OS/2 developers in the linux community...
> > may be you might ask for help there as well...
>
> Timur wrote the real-time MIDI drivers for OS/2, didn't he?
Yes, but I am NOT a former OS/2 developer. I am a CURRENT OS/2 developer.
ctr2...@yahoo.com
> > > I wonder if there are any former OS/2 developers in the linux community...
> > > may be you might ask for help there as well...
> > Timur wrote the real-time MIDI drivers for OS/2, didn't he?
> Yes, but I am NOT a former OS/2 developer. I am a CURRENT OS/2 developer.
1. I think he meant "person who is developing OS/2," not "person who
is developing applications for OS/2."
2. Quit being so defensive, please.
Michel TALON
: In <87zo2l5...@yahoo.com>, on 02/07/2002
This degree of lammeness is amazing. Since ages it is possible to use TrueType
fonts under X and get them in Netscape. You then have an excellent display
exactly as good as under Windows. There are numerous HOWTOS on the Web to do
that. This works not only under Linux but also on all free OS's i know.
More recently the usual desktop managers under Linux, notably KDE have
been able to antialias fonts and produce very nice and clean display.
So try other arguments if you want to convince people, like
Win XP is easier to configure and works enough for me.
: george
--
Michel TALON
gregor...@verizon.net
Yeah ... Font rendering in general sucks/sucked under Linux ...
I was surprised at how truly horrible it is ... Worse than OS/2 ...
I know that now anti-aliasing is starting to get into the two window
managers - KDE & GNOME ...
Has anyone used the latest releases of KDE or GNOME ???
Is font-smoothing now system-wide ??? And most important, easy to
enable ???
Having it on a app-by-app basis doesn't work for me ... I want it
system-wide ...
Greg
ctr2...@yahoo.com
at least is better than coop.misc.
gregor...@verizon.net writes:
> Yeah ... Font rendering in general sucks/sucked under Linux ...
> I was surprised at how truly horrible it is ... Worse than OS/2 ...
Now that's just unfair!
But let's be clear about something: it's not Linux that's at fault
here, it's KDE/GNOME/whatever (to a certain extent) and X (to a
greater extent). I don't believe XFree86 supported antialiasing at
all until the 4.0 series, and I doubt that non-XFree86 implementations
support them even now.
Second, XF86 has quite good TrueType support. IMO, XF86 renders
non-antialiased fonts significantly better than Windows does. Many of
the newer fonts that come with XF86 (or with the Debian packages, not
sure about the exact origin) look great _without_ antialiasing.
> Has anyone used the latest releases of KDE or GNOME ???
GNOME will not have antialiased fonts until 2.0, which is slated for
release in a few months. There will probably be reasonably stable
betas available in a few weeks.
> Is font-smoothing now system-wide ???
It will be.
> And most important, easy to enable ???
And control, apparently: a feature I find absolutely critical. You
will supposedly be able to decide which fonts get antialiased, when
the effect kicks in (e.g. only fonts above 12pt), and so on.
I hope that GNOME ultimately goes for the Windows-style minimalist
antialiasing. Rather than the kind used in MacOS and graphics
programs, which overdo it (again, IMO). I want only enough smoothing
to get rid of the jagged edges, no more than that.
It would be great if you could control that too, though it'd probably
be too difficult to implement for the programmers.
> Having it on a app-by-app basis doesn't work for me ... I want it
> system-wide ...
Well, "system-wide" will mean "for GNOME applications." Ditto for
KDE.
Roger Leigh
> And control, apparently: a feature I find absolutely critical. You
> will supposedly be able to decide which fonts get antialiased, when
> the effect kicks in (e.g. only fonts above 12pt), and so on.
>
> I hope that GNOME ultimately goes for the Windows-style minimalist
> antialiasing. Rather than the kind used in MacOS and graphics
> programs, which overdo it (again, IMO). I want only enough smoothing
> to get rid of the jagged edges, no more than that.
>
> It would be great if you could control that too, though it'd probably
> be too difficult to implement for the programmers.
All this is available. Check /etc/X11/XftConfig.
An excerpt:
,----[ XftConfig ]
| #
| # Check users config file
| #
| includeif "~/.xftconfig"
|
| #
| # Alias between XLFD families and font file family name, prefer local
| # fonts
| #
| match any family == "charter" edit family += "bitstream charter";
| match any family == "bitstream charter" edit family =+ "charter";
|
| match
| any size < 14
| any size > 8
| edit antialias = false;
`----
So at the top is the opportunity for users to customise this
individually, and at the bottom we enable for just certain families
and then not for 9-13 point sizes, just like on Windows.
IIRC this is not yet used by Gnome, but is by KDE. It seems sane
enough, and I think does all that you required.
Regards,
Roger
--
Roger Leigh
** Registration Number: 151826, http://counter.li.org **
Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers
Alessandro Cantatore
>> > > I wonder if there are any former OS/2 developers in the linux community...
>> > > may be you might ask for help there as well...
>
>> > Timur wrote the real-time MIDI drivers for OS/2, didn't he?
>
>> Yes, but I am NOT a former OS/2 developer. I am a CURRENT OS/2 developer.
>
>1. I think he meant "person who is developing OS/2," not "person who
> is developing applications for OS/2."
>2. Quit being so defensive, please.
I meant that developers now using linux, but which were formerly
using and developing OS/2 applications, might be of great help since
would know both the worlds.
I don't know if Timur is using OS/2 or linux... I just assumed he's
using and developing OS/2 applications... (i.e. I wasn't referring
to Timur)
There was no hidden meaning...
--
bye
Alessandro Cantatore
gregor...@verizon.net
<snip>
> But let's be clear about something: it's not Linux that's at fault
> here, it's KDE/GNOME/whatever (to a certain extent) and X (to a
> greater extent). I don't believe XFree86 supported antialiasing at
> all until the 4.0 series, and I doubt that non-XFree86 implementations
> support them even now.
>
> Second, XF86 has quite good TrueType support. IMO, XF86 renders
> non-antialiased fonts significantly better than Windows does. Many of
> the newer fonts that come with XF86 (or with the Debian packages, not
> sure about the exact origin) look great _without_ antialiasing.
Thanks for the info ...