DLL loading problem
Ruediger Ihle
Hi,
I encountered a problem with DLL loading and ask myself, if
anything can be done about this. I have 3 binaries located
in different directories:
path1\A.DLL
path2\B.DLL
path3\C.EXE
B.DLL is linked against A's import library. Thus A.DLL is
required for B.DLL.
C.EXE loads A.DLL via DosLoadModule() using a fully qualified
path name. After that it tries the same for B.DLL. Unfortunately
DosLoadModule() now fails claiming that A cannot be found.
Why does this happen ? A.DLL is present in memory.
The load succeeds, when "path1" is in LIBPATH. However, for
this project it's not desirable to modify LIBPATH.
Any ideas ?
--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Marcel Müller
Ruediger Ihle wrote:
> B.DLL is linked against A's import library. Thus A.DLL is
> required for B.DLL.
>
> C.EXE loads A.DLL via DosLoadModule() using a fully qualified
> path name. After that it tries the same for B.DLL. Unfortunately
> DosLoadModule() now fails claiming that A cannot be found.
What about LIBPATHSTRICT? Is it set?
> Why does this happen ? A.DLL is present in memory.
B.DLL does not refer to A.DLL by full qualified path. Loading B.DLL by
full qualified path does not mean anything for the dependency A.DLL.
> The load succeeds, when "path1" is in LIBPATH. However, for
> this project it's not desirable to modify LIBPATH.
>
> Any ideas ?
SET BEGINLIBPATH=path1 ?
SET LIBPATHSTRICT=FALSE ?
Marcel
Lars Erdmann
>
> Hi,
>
> I encountered a problem with DLL loading and ask myself, if
> anything can be done about this. I have 3 binaries located
> in different directories:
>
> path1\A.DLL
> path2\B.DLL
> path3\C.EXE
>
> B.DLL is linked against A's import library. Thus A.DLL is
> required for B.DLL.
>
> C.EXE loads A.DLL via DosLoadModule() using a fully qualified
> path name. After that it tries the same for B.DLL. Unfortunately
> DosLoadModule() now fails claiming that A cannot be found.
>
> Why does this happen ? A.DLL is present in memory.
I guess that if DosLoadModule loads other DLLs recursively that it
only takes into account the paths in LIBPATH/BEGINLIBPATH/ENDLIBPATH
(set statically or dynamically).
That kind of makes sense as this is exactly what LIBPATH/BEGINLIBPATH/ENDLIBPATH
are there for.
As DosLoadModule increases the loading reference count, the loader
DOES need to find the DLL file (maybe it wouldn't need to if it were programmed a little smarter).
DosQueryModuleHandle on the other hand will not increase the loading reference count.
>
> The load succeeds, when "path1" is in LIBPATH. However, for
> this project it's not desirable to modify LIBPATH.
Can't you just call DosSetExtLIBPATH(path1,END_LIBPATH) and DosSetExtLIBPATH(path2,END_LIBPATH)
(or BEGIN_LIBPATH)
from C to add the DLL paths dynamically before
you invoke DosLoadModule on A and B and then WITHOUT specifying full path names ?
Lars
Ruediger Ihle
Hi,
> What about LIBPATHSTRICT? Is it set?
No.
> SET BEGINLIBPATH=path1 ?
> SET LIBPATHSTRICT=FALSE ?
That works, but it's what I wanted to avoid. First of all
I don't like the need to use a *.cmd in order to run a
GUI app. Second, the whole thing is part of an extendable
plugin system. I.e. other developers could add new modules
(usually in different pathes) which might have dependecies
on DLLs in "path2" or in a not yet existent "path4". It
would be very bad forcing the user to adjust BEGINLIBPATH
manually. However, setting it programmatically by C.EXE
looks like a workable solution...
Ruediger Ihle
> As DosLoadModule increases the loading reference count, the loader
> DOES need to find the DLL file
Why ? It doesn't write the reference counter back to the file ;-).
Or does it need addtional information from the file header in order
to identitify the module in memory ? BTW, the described approach
works flawlessly in Linux and Windows...
> Can't you just call DosSetExtLIBPATH
Yep. That is doable. Just another OS/2-specific hack in otherwise
relatively clean multi-platform code...
Marcel Müller
>> Can't you just call DosSetExtLIBPATH
>
> Yep. That is doable. Just another OS/2-specific hack in otherwise
> relatively clean multi-platform code...
Well, once WinXX closes the serious security issue with DLL loading, you
will end up in a similar problem.
Marcel
Rich Walsh
> I encountered a problem with DLL loading and ask myself, if
> anything can be done about this. I have 3 binaries located
> in different directories:
>
> path1\A.DLL
> path2\B.DLL
> path3\C.EXE
>
> B.DLL is linked against A's import library. Thus A.DLL is
> required for B.DLL.
>
> C.EXE loads A.DLL via DosLoadModule() using a fully qualified
> path name. After that it tries the same for B.DLL. Unfortunately
> DosLoadModule() now fails claiming that A cannot be found.
>
> Why does this happen ? A.DLL is present in memory.
You've encountered a problem in the v4.5 kernel that I identified
years ago. Scott Garfinkel agreed it was a bug but wouldn't fix it.
In effect, the loader maintains 2 lists of dlls: those loaded by
f/q name and those loaded by modulename using the extended libpath.
When you load a dll by modname, the loader ignores its list of dlls
already loaded by f/q path and instead searches the libpath. The
net effect is sort of a "libpathHALFstrict" condition.
There is a workaround/hack that I've had to use in several projects.
If a dll that was initially loaded by f/q name is later loaded by
modname, its entry get moved from the f/q list to the modname list.
Thereafter, it can be reloaded any number of times by either method.
In my case, the dll had already been loaded by f/q name, so I got it's
path, added it to BEGINLIBPATH, then reloaded it by modname. Since my
code was operating in a process it didn't create, it had to clean up
after itself by restoring the original BEGINLIBPATH. If you control
the process, then you can just set it, do the initial load of A.DLL
by modname, and leave things as-is.
FYI... while LIBPATHSTRICT is in effect, all newly-loaded dlls go
on the f/q name list. Because of the "libpathHALFstrict" condition
that normally prevails, none of these dlls will be found if reloaded
by modname. This is what permits you to run multiple, incompatible
versions of the Mozilla apps without having to set LIBPATHSTRICT for
all of them. Any *one* can omit it and each will still use its own
dlls.
--
== == almost usable email address: Rich AT E-vertise DOT Com == ==
Jonathan de Boyne Pollard
> only takes into account the paths in LIBPATH/BEGINLIBPATH/ENDLIBPATH
> (set statically or dynamically).
>
against the modules already loaded, one of which is named "A".
(Here's something for you to check, M. Ihle: Is the modname of "A.DLL"
actually "A"? It normally will be, but it's possible to adjust that
with linker options, so it's important to check.)
Jonathan de Boyne Pollard
> years ago. Scott Garfinkel agreed it was a bug but wouldn't fix it.
>
The real problem is that these lists are system-wide on IBM OS/2, rather
than per-process. They're per-process in other operating systems, which
is why the behaviour is different there. Even DOS-Windows 9x, for
example, will happily modname match against DLLs loaded in the same
process, but won't modname match against DLLs loaded in other
processes. But IBM OS/2's design hails from the time of DOS-Windows
2.x, when global tables were the way that DLLs were tracked.
I can understand the reluctance to fix this. It's a fairly fundamental
overhaul to the way that IBM OS/2 does its bookkeeping. (LIBPATHSTRICT
isn't really the full overhaul. The global tables are still there. The
rules for searching them simply change, with this and other undesirable
side-effects as the fall-out.) That's a lot of work to justify even in
2001.
And then you have all of the further work of explaining to people that
they can forget all about LIBPATHSTRICT, when it's taken them quite a
long time to get to grips with it in the first place ... (-:
Peter Flass
Probably won't be changed, but if I were doing it I'd allow the
application to specify loading as a global or local. If the default
were global the system behavior wouldn't change.
Rich Walsh
> > You've encountered a problem in the v4.5 kernel that I identified
> > years ago. Scott Garfinkel agreed it was a bug but wouldn't fix it.
>
> The real problem is that these lists are system-wide on IBM OS/2, rather
> than per-process. They're per-process in other operating systems
This isn't an issue of comparative OS design or intentional changes in
the loader's design. It's a bug, plain and simple.
Using any version of the kernel from 1.0 thru 4.0, Rudi would not have
encountered this problem. The loader would have looked at all dlls,
regardless of how they were loaded, and would have matched his modname
request to a dll that happened to have been loaded by f/q name.
Of all OS vendors, IBM was the least likely to change things without
telling anyone. If there was an undocumented, material change in the
base OS's operation, then this was a bug. However, by the time I
identified it, the WSEB kernel had been in use for several years.
I can only surmise that SEG figured it hadn't caused any problems
for IBM's corporate customers while returning to the status quo ante
might. Therefore he wouldn't fix it - and we have to work around it
when necessary.
Ilya Zakharevich
> This isn't an issue of comparative OS design or intentional changes in
> the loader's design. It's a bug, plain and simple.
No it is not. But we have discussed this already. (Many times?)
> Using any version of the kernel from 1.0 thru 4.0, Rudi would not have
> encountered this problem. The loader would have looked at all dlls,
> regardless of how they were loaded, and would have matched his modname
> request to a dll that happened to have been loaded by f/q name.
This would a bug.
Loading a DLL by FQN (a "private" DLL) should not interact with
loading "a publicly accessible" DLL. And it does not. Very good.
Otherwise an application which used DLL for run-time loading of chunks
of code would need to know the names of ALL publicly accessible DLL on
ALL systems it ever may be used on (to avoid using these names for
its private DLLs). Thanks, but no thanks.
Moreover, the semanic you want to achieve is TRIVIALLY accessible from
inside the private DLL (use EIPtoHANDLE, HANDLEtoFQN, temporary change
BEGINLIBPATH and load itself as a public DLL). (For fullness, I would
like to unload [to change refcount back to 1], but I do not know how this
would interact with 2 lists - [the applications I support never unload
DLLs]...)
Yours,
Ilya
Jonathan de Boyne Pollard
>> rather than per-process. They're per-process in other operating
>> systems, which is why the behaviour is different there. Even
>> DOS-Windows 9x, for example, will happily modname match against DLLs
>> loaded in the same process, but won't modname match against DLLs
>> loaded in other processes. But IBM OS/2's design hails from the time
>> of DOS-Windows 2.x, when global tables were the way that DLLs were
>> tracked.
>>
>> I can understand the reluctance to fix this. It's a fairly
>> fundamental overhaul to the way that IBM OS/2 does its bookkeeping.
>> (LIBPATHSTRICT isn't really the full overhaul. The global tables are
>> still there. The rules for searching them simply change, with this
>> and other undesirable side-effects as the fall-out.) That's a lot of
>> work to justify even in 2001.
>>
> application to specify loading as a global or local. If the default
> were global the system behavior wouldn't change.
>
The thing is: Global modname matching across all processes is almost
never what one wants. I'm hard pressed to come up with an example of a
use for it. IBM OS/2 in the late 1980s had a global DLL table, though,
just like DOS-Windows 2.x did at the same time. The problem here is
that second system effect, which gave us the behaviour of DOS-Windows 9x
and Windows NT when it was realized that per-process semantics were the
sensible ones (because they allow one to have per-process DLL search
paths that don't have crazy behaviour, for one thing), hasn't really
been fully applied to the first system. The whole
BEGINLIBPATH/ENDLIBPATH/LIBPATHSTRICT mechanism is a bodge that retains
the global tables, but changes the rules for searching them so that one
*almost*, but not quite, gets the per-process semantics that everyone
has concluded are the sensible ones. It's an easy bodge that doesn't
change the underlying bookkeeping.
So really there's no need for such an API option as you describe, nor
really a need for a compatibility mode as you describe. To most people,
the original behaviour isn't what they even designed their applications
to expect in the first place. I know that when I first read the books
on OS/2 programming, I expected DLLs to be handled per-process. Much
was made early onof the fact that OS/2 didn't load DLLs into a shared
address space with one copy across all processes like Windows 2.x/3.x
did. From that, programmers expect that the semantics of DLL searching
are, in general, per process rather than global. And there's really
only a small hint in the CP reference that things are otherwise.
I don't know what the OSFree people did, or even if they got as far as
supporting DLLs properly at all, but I would expect that anyone writing
a system like this would opt for the per-process semantics similar to
those of Win32 when it comes to modname matching. It's evident from
this incident alone that they are what programmers expect. M. Ihle
didn't expect OS/2 to have different semantics.
But that's rather the point. The likes of the OSFree crowd, cloning
OS/2, get to do what they like. Whereas someone working for IBM on the
*original* operating system has to justify the work, and there's a lot
of it to change this. Even in 2001, when the fuss was first kicked up
about this, that would have been a hard case to make. A complete
overhaul of the module table, probably several months of work and
regression testing, just to satisfy people who do (from the point of
view of people who haven't read the fine print of the CP reference)
crazy things like expect DLLs to be found and loaded even when they
aren't actually on the library path? Try getting that past a manager.
Especially a manager who would like OS/2 to go away.
Peter Flass
...
>
> The thing is: Global modname matching across all processes is almost
> never what one wants. I'm hard pressed to come up with an example of a
> use for it.
I come from more of a mainframe background, but I feel the opposite.
Global matching is the norm -- think libc, for example -- and
per-process should be the exception to handle the cases where a DLL is
not upward-compatible. Of course, for microsoft this *is* the norm.
> IBM OS/2 in the late 1980s had a global DLL table, though,
> just like DOS-Windows 2.x did at the same time. The problem here is that
> second system effect, which gave us the behaviour of DOS-Windows 9x and
> Windows NT when it was realized that per-process semantics were the
> sensible ones (because they allow one to have per-process DLL search
> paths that don't have crazy behaviour, for one thing), hasn't really
> been fully applied to the first system. The whole
> BEGINLIBPATH/ENDLIBPATH/LIBPATHSTRICT mechanism is a bodge that retains
> the global tables, but changes the rules for searching them so that one
> *almost*, but not quite, gets the per-process semantics that everyone
> has concluded are the sensible ones. It's an easy bodge that doesn't
> change the underlying bookkeeping.
Again maybe this is me, but search paths _should_ have nothing to do
with DLL name matching. The tables should match as much of the name as
the caller specifies, expanding stuff like './' in the pathname. If he
asks for 'abc' he gets the first 'abc' in the search path or the first
one in the table. If he specifies 'c:\myapp\mysubdir\abc' he gets that
one, which would only be loaded if not already present.
Two caveats -- First, I'm relatively unknowledgable about the specifics
of how OS/2 handles this; you doubtless know more. Second, as I said,
this is only an academic discussion, since the system does what it does.
...
>
> But that's rather the point. The likes of the OSFree crowd, cloning
> OS/2, get to do what they like.
I think their intention is to reproduce the behavior of OS/2 as it is.
...
> A complete
> overhaul of the module table, probably several months of work and
> regression testing, just to satisfy people who do (from the point of
> view of people who haven't read the fine print of the CP reference)
> crazy things like expect DLLs to be found and loaded even when they
> aren't actually on the library path?
Yup, that would be me. All the fine print is there for a reason, but
unless you've run into a situation you can't diagnose it often doesn't
get read.
Interesting discussion, I've learned some things.
Jonathan de Boyne Pollard
>> rather than per-process. They're per-process in other operating
>> DOS-Windows 9x, for example, will happily modname match against DLLs
>> loaded in the same process, but won't modname match against DLLs
>> loaded in other processes. But IBM OS/2's design hails from the time
>> of DOS-Windows 2.x, when global tables were the way that DLLs were
>> tracked.
>>
> the loader's design. It's a bug, plain and simple.
>
On the contrary, it is an issue of both of those. The design did
change, and quite clearly the applications programming interface
contract *now*, with LIBPATHSTRICT enabled, is "If it isn't on the
library path, it won't get found by basename alone, no matter what you
may have already loaded.", which is not an unreasonable contract to
supply, albeit that the CP reference never changed to match the new
contract, nowhere has this been properly documented, and not even this
is what Win32 does. It is not a bug. It is a *bug fix*, that simply
doesn't go far enough and is incomplete, almost certainly because it
wasn't possible to justify the work at IBM to fix things fully and properly.
> Using any version of the kernel from 1.0 thru 4.0, Rudi would not have
> encountered this problem.
>
Indeed. He would instead have encountered the original bugs that this
bugfix addresses, including the problem of any other process in the
system just happening to have loaded a DLL with that modname forcing
their choice of DLL on all other processes. This bugfix gives what is
essentially a limited subset of the interface contract that OS/2 was
thought by many to provide from the start, namely DLLs being loaded
per-process, which is:
* A DLL loaded in one process won't affect the library path searching by
another process.
* If a DLL isn't on the library path, it won't get found if one attempts
to load it by basename alone, no matter that a DLL with that modname may
already have been loaded somewhere. LIBPATHSTRICT is, as the name
suggests, *strict*. Any DLLs to be found by basename *must* be on the
process' current library path.
It's probably as far as one can get by fudging the global module table
search rules. Getting the whole of the original interface contract
really does involve doing what DOS-Windows 95 does, which is maintain
*local* module tables, one per process. That's a lot of change for an
operating system kernel that IBM wanted to go away. It's a significant
change to the kernel's bookkeeping, as opposed to the LIBPATHSTRICT
mechanism which is merely a change to some global table name matching
rules whilst still retaining the same table, that would have required a
lot of regression testing.
There's a fairly good argument to be made that it's a better interface
contract. It certainly doesn't come with any "Ah, but if a completely
different piece of code that you weren't aware was even part of this
program happened to load this other DLL, from a different file in
another directory but with the same modname, earlier on, in that same
process ..." qualifications. Interestingly, Win32 itself over the past
decade has come closer to much the same contract. Add application
manifests and "safe DLL search mode" into the mix, and one finds that
one will *not*, necessarily, be able to pre-load DLLs that aren't on the
library path in the way that M. Ihle tried to, because Win32 now tries
harder to find the *right* DLL, rather than just any old DLL hanging
around in memory with a matching modname. If anyone ever upgrades those
DLLs that you're loading to fully fledged side-by-side or private
assemblies, M. Ihle, your design is in trouble on Windows.
> However, by the time I identified it, the WSEB kernel had been in use
> for several years.
>
By the time that you identified it, the amount of manpower at IBM
allocated for maintaining the IBM OS/2 kernel was significantly
different to what it was in the 1990s.
Jonathan de Boyne Pollard
>> never what one wants. I'm hard pressed to come up with an example of
>> a use for it.
>>
> I come from more of a mainframe background, but I feel the opposite.
> Global matching is the norm -- think libc, for example -- and
> per-process should be the exception to handle the cases where a DLL is
> not upward-compatible. Of course, for microsoft this *is* the norm.
>
Not just for Microsoft. For *most people* this is the norm, Unix
included. Think libc for example. Yes, libc. You chose what is,
ironically, an exact counterexample. Have you ever looked to see how
many different versions of it there are? GNU libc has versions 2.0 to
2.13 over the past decade or so, for one. Every program needs a
particular version of libc and they aren't all binary compatible. Hence
the existence of things like Red Hat's compat-glibc package. Local
matching is the norm on Linux and on Unices just as with Microsoft and
IBM operating systems. One doesn't get any old module named "libc" that
just happens to have been loaded into some other process at some point
before. There's no global module table in the kernel that's searched.
The dynamic library loader searches the library path, finds a file (or a
symbolic link to a file) with the library, and loads it; and this
happens separately in each individual process.
>> IBM OS/2 in the late 1980s had a global DLL table, though, just like
>> DOS-Windows 2.x did at the same time. The problem here is that second
>> system effect, which gave us the behaviour of DOS-Windows 9x and
>> Windows NT when it was realized that per-process semantics were the
>> sensible ones (because they allow one to have per-process DLL search
>> paths that don't have crazy behaviour, for one thing), hasn't really
>> been fully applied to the first system. The whole
>> BEGINLIBPATH/ENDLIBPATH/LIBPATHSTRICT mechanism is a bodge that
>> retains the global tables, but changes the rules for searching them
>> so that one *almost*, but not quite, gets the per-process semantics
>> that everyone has concluded are the sensible ones. It's an easy bodge
>> that doesn't change the underlying bookkeeping.
>>
> Again maybe this is me, but search paths _should_ have nothing to do
> with DLL name matching. The tables should match as much of the name
> as the caller specifies, expanding stuff like './' in the pathname.
> If he asks for 'abc' he gets the first 'abc' in the search path or the
> first one in the table. If he specifies 'c:\myapp\mysubdir\abc' he
> gets that one, which would only be loaded if not already present.
>
The latter doesn't work in the presence of Unix-like fileystem
semantics. If the DLL image file is unlinked and replaced by a new file
with an updated DLL, then obviously even though the pathname hasn't
changed the new DLL should be found, not the old one, even if processes
still running are using the old DLL. This is a problem with the whole
idea of matching DLLs in any table, global or per-process, by name.
There's always a way in which that name can end up pointing to something
different, and "the same name" stops being equivalent to "the same
library". The only sensible way for a kernel to declare two dynamic
libraries to be "the same" is if their vnodes match.
Which brings us to the former statement of yours. It's on the right
lines, but not quite pointing in the right direction. If the only
sensible way for a kernel to declare two dynamic libraries to be "the
same" is if their vnodes match, then really there *should be no* DLL
name matching going on *anywhere*. DLLs loaded by an unqualified
basename should be *neither* matched by their modnames *nor* matched by
generated pathnames. Rather, an unqualified basename is simply passed
through the library path mechanism, to yield as its result an open file
handle (or file mapping handle) that is, effectively, the vnode of the
library; and any sort of global matching that happens in order to match
an already loaded DLL and increment its reference count happens by
comparing that vnode to the vnodes of existing loaded DLLs. So search
paths have nothing to do with DLL name matching by simple dint of the
fact that there *is no* DLL name matching *at all*. Everything funnels
through the library path searching mechanism, and there are no magic
shortcuts, where names are matched, that bring with them the
possibilities of the wrong DLL ending up being used.
Viewed from another angle, one can equally say that the idea that one
*can* match DLLs by name, modname or pathname, is one of the reasons
that the likes of OS/2 and Windows NT retain their prohibitions on
deleting the DLLs and EXEs of executing programs. If, say, one DLL is
considered to match an already loaded DLL because they both have the
name C:\Apps\JdeBP\CMD\DLL\CMDCRT.DLL, then one cannot let processes go
around deleting and replacing that file whilst it is in use; because
that would violate the matching guarantee. This can be extended to a
logical conclusion, too. If one DLL is considered to match an already
loaded DLL because they both have the modname CMDCRT, then one really
cannot permit processes to do anything that violates that guarantee,
which would include (a) deleting and replacing the loaded CMDCRT.DLL
image file, (b) adding a new CMDCRT.DLL somewhere else on the process'
library path, and even (c) changing the process' library path so that a
different CMDCRT.DLL is found. And again, by a different route, we
reach the point of realization that name matching, pathname *or*
modname, is simply a bad idea in toto because of what desirable
functionality has to be prevented in order to make it work reliably in
all circumstances.
Microsoft's current answer to this whole conundrum with Win32 is to
instruct programmers simply not to use anything but qualified pathnames
when loading DLLs, and to warn that if one does use unqualified
basenames, one won't necessarily actually end up with the DLL that one
intended. (See the documentation for LoadLibrary(), LoadLibraryEx(),
and Dynamic Link Library Security in the MSDN Library.) In other words:
Avoid the tricky parts of the whole design that really don't quite work
right.
IBM's answer with LIBPATHSTRICT enabled is a fairly reasonable
alternative: You can use unqualified basenames, but don't expect
modname matching to work all of the time or to be able to load/query
DLLs that aren't on your library path in the first place.
Lars Erdmann
>>>
>> I come from more of a mainframe background, but I feel the opposite. Global matching is the norm -- think libc, for example -- and per-process should be the exception to handle the cases where a DLL is not upward-compatible. Of course,
>> for microsoft this *is* the norm.
>>
>
> Not just for Microsoft. For *most people* this is the norm, Unix included. Think libc for example. Yes, libc. You chose what is, ironically, an exact counterexample. Have you ever looked to see how many different versions of it there are?
> GNU libc has versions 2.0 to 2.13 over the past decade or so, for one. Every program needs a particular version of libc and they aren't all binary compatible. Hence the existence of things like Red Hat's compat-glibc package. Local matching
> is the norm on Linux and on Unices just as with Microsoft and IBM operating systems. One doesn't get any old module named "libc" that just happens to have been loaded into some other process at some point before. There's no global module
> table in the kernel that's searched. The dynamic library loader searches the library path, finds a file (or a symbolic link to a file) with the library, and loads it; and this happens separately in each individual process.
>
>>> IBM OS/2 in the late 1980s had a global DLL table, though, just like DOS-Windows 2.x did at the same time. The problem here is that second system effect, which gave us the behaviour of DOS-Windows 9x and Windows NT when it was realized
>>> that per-process semantics were the sensible ones (because they allow one to have per-process DLL search paths that don't have crazy behaviour, for one thing), hasn't really been fully applied to the first system. The whole
>>> BEGINLIBPATH/ENDLIBPATH/LIBPATHSTRICT mechanism is a bodge that retains the global tables, but changes the rules for searching them so that one *almost*, but not quite, gets the per-process semantics that everyone has concluded are the
>>> sensible ones. It's an easy bodge that doesn't change the underlying bookkeeping.
>>>
>> Again maybe this is me, but search paths _should_ have nothing to do with DLL name matching. The tables should match as much of the name as the caller specifies, expanding stuff like './' in the pathname. If he asks for 'abc' he gets the
>> first 'abc' in the search path or the first one in the table. If he specifies 'c:\myapp\mysubdir\abc' he gets that one, which would only be loaded if not already present.
>>
Hm. I always thought the initial idea of DLLs was to:
1.) reduce coding effort and reuse code that already exists
2.) enforce the same behaviour/look by providing the same piece of code for everyone to use
3.) reduce memory usage by having code shared amongst multiple processes, possibly even data
That would speak for the global approach. The fact that you run into a bunch of troubles:
4.) the binary interface of a DLL changes
5.) the search algorithm that does not know any better than to look for filenames to find and load a DLL
if necessary (at least the f/q filename ensures uniqueness but then it is potentially "too much uniqueness"
from one system to the other so you will need to have configuration files for base paths etc.)
or for module names (where the uniqueness of module names is not enforced in any way)
6.) 2 DLLs with the very same name but that have nothing to do with each other
leads to all these workarounds where you effectively "roll back" what you are trying to achieve with 1.)-3.)
BEGINLIBPATH/ENDLIBPATH/LIBPATHSTRICT are trying to give the user external control over where the DLLs are to be found.
The runtime counterparts (DosSetExtLIBPATH) are trying to give the developer external control over where the DLLs are to be found.
I think this approach is a good compromise.
The bottom line is, if you don't intend to share code (or data or resources) with other applications,
the better solution would be to create a static library from it -> make it private.
Of course there are inevitable exceptions and you are back to where the trouble starts:
NLV resource DLLs, IOPL DLLs, plugins etc. ...
In any case, we have to live with what IBM has left behind for OS/2.
Lars
Lars Erdmann
> executing programs. If, say, one DLL is considered to match an already loaded DLL because they both have the name C:\Apps\JdeBP\CMD\DLL\CMDCRT.DLL, then one cannot let processes go around deleting and replacing that file whilst it is in
> use; because that would violate the matching guarantee. This can be extended to a logical conclusion, too. If one DLL is considered to match an already loaded DLL because they both have the modname CMDCRT, then one really cannot permit
> processes to do anything that violates that guarantee, which would include (a) deleting and replacing the loaded CMDCRT.DLL image file, (b) adding a new CMDCRT.DLL somewhere else on the process' library path, and even (c) changing the
> process' library path so that a different CMDCRT.DLL is found. And again, by a different route, we reach the point of realization that name matching, pathname *or* modname, is simply a bad idea in toto because of what desirable
> functionality has to be prevented in order to make it work reliably in all circumstances.
I think the reason for preventing deletion of a DLL that is in use by one or more processs is not the one you state.
It is the necessity to page in code/read-only data from the DLL in order to avoid having to load the complete DLL.
That was the point when IBM invented function "DosReplaceModule" that does exactly that:
it loads the complete DLL into memory which eventually allows the deletion of the DLL while it is
still in use. However, every subsequent process that also attempts to load the DLL via module name will get
access to the copy in memory and therefore to the code that was in existence before the DLL was deleted.
A subsequent f/q path load should obviously fail once the file is gone.
Lars
Jonathan de Boyne Pollard
>> *can* match DLLs by name, modname or pathname, is one of the reasons
>> that the likes of OS/2 and Windows NT retain their prohibitions on
>> deleting the DLLs and EXEs of executing programs. If, say, one DLL is
>> considered to match an already loaded DLL because they both have the
>> name C:\Apps\JdeBP\CMD\DLL\CMDCRT.DLL, then one cannot let processes
>> go around deleting and replacing that file whilst it is in use;
>> because that would violate the matching guarantee. This can be
>> extended to a logical conclusion, too. If one DLL is considered to
>> match an already loaded DLL because they both have the modname
>> CMDCRT, then one really cannot permit processes to do anything that
>> violates that guarantee, which would include (a) deleting and
>> replacing the loaded CMDCRT.DLL image file, (b) adding a new
>> CMDCRT.DLL somewhere else on the process' library path, and even (c)
>> changing the process' library path so that a different CMDCRT.DLL is
>> found. And again, by a different route, we reach the point of
>> realization that name matching, pathname *or* modname, is simply a
>> bad idea in toto because of what desirable functionality has to be
>> prevented in order to make it work reliably in all circumstances.
>>
> I think the reason for preventing deletion of a DLL that is in use by
> one or more processs is not the one you state. It is the necessity to
> page in code/read-only data from the DLL in order to avoid having to
> load the complete DLL.
>
You think wrong, more on which in a moment.
> That was the point when IBM invented function "DosReplaceModule" that
> does exactly that:[...]
>
No. The point of DosReplaceModule() was to give some equivalent to
functionality that is simply *there* on Unix. It exists because EXEs
and DLLs (and indeed any sort of open file) cannot be deleted. The
prohibition doesn't exist because of it. In fact the prohibition
pre-dates the existence of OS/2 and goes back to MS/PC-DOS. To think
that the function inspired the prohibition is exactly backwards.
The idea that paging necessitates this is wrong. Deleting a file
doesn't stop it from being accessible on a Unix-like operating system.
On such a system deleting an in-use DLL or EXE won't stop processes from
being able to read pages in from it, because deleting the file whilst it
is open doesn't make it actually disappear. It's still perfectly
accessible to any process that has it open, and it continues to exist
until all processes that had it open close it. The fact that one can
quite happily use deleted files from a running process on such systems
completely disproves any idea that deleting a file makes it impossible
to use it as the program image for a DLL or an EXE of a running
process. The fact that one can do exactly that on Unices says otherwise.
The reason that one cannot delete open files on IBM OS/2 is manifold,
one part of which is, as I said, that letting things be otherwise
reveals a large flaw in the whole "These two DLLs have the same name
therefore they must be the same DLL." logic of the process loader.
Other reasons include, in no particular order: application backwards
compatibility and the fact that API considers every open module to
possess a name of some kind (c.f. DosQueryModuleName()).
People really, really, want the abilities to just simply install
upgraded programs over the top of running stuff, leaving it running,
that Unix has. That's why we received DosReplaceModule(), which is a
special-purpose bodge to provide just enough, of the capabilities that
would otherwise be achieved with ordinary filesystem manipulation system
calls, to keep people, who really only want a specific subset of the
overall range of things that can be done, happy. To go further, and
actually make the ordinary filesystem manipulations work in toto for
open files and in-use executable program images, is to kick out a stone
that underpins a fair amount of this corner of the design of IBM OS/2.
The knock-on effects of it are, as I mentioned before, changes to the
guarantees provided by DosLoadModule(), which can no longer do any
matching by *any* type of name, significant changes in the
specifications of the likes of DosQueryModuleHandle() and
DosQueryModuleName(), and other stuff as well (Any form of delayed
import binding is significantly affected, for example.).
Put another way: Making IBM OS/2 work "Sensibly, like Unix works." for
all of the programmers who say that they want that, breaks the
applications of the Ruediger Ihles of this world, who design their
programs on the assumption that IBM OS/2 has the same global module
table with globally unique modnames that it and DOS-Windows 2.x had back
in the late 1980s. (-: They may not know that that's their
assumption. Often it's more the case of "Well I happen to know that if
I use that trick, it works.". But the tricks are usually predicated
upon the operating system implementation, such as a global system module
table (or a global socket handle table, or device filenames in every
directory, or maintenance of a separate current directory for every
drive ...). *That's* (one part of) why these things exist, not
unfounded hypotheses about paging to deleted files. That's why the
Win32 personality on Windows NT 6.1, right now in 2011, still has the
prohibition on deleting in-use files inherited from MS/PC-DOS, even
though Windows NT has always, from pretty much its very inception, at
the actual operating system kernel level had the ability to delete
in-use files. The Ruediger Ihles of this world want OS/2 to work
"Sensibly, like Win32 does." so that they don't have to have separate
code for OS/2 with different semantics to Win32, and Win32 programmers
in their turn want Win32 to work "Sensibly, like DOS-Windows 2.x does.".
tho...@antispam.ham
> No. The point of DosReplaceModule() was to give some equivalent to
> functionality that is simply *there* on Unix. It exists because EXEs
> and DLLs (and indeed any sort of open file) cannot be deleted.
One of the problems I've encountered is that open files cause
problems for backup programs. I really think there ought to be
a way to copy a file even while it's open. I hate to have a
backup program "successfully" complete, only to have a bunch of
files missing from the backup because they were open at the time.
Yes, I know an open file is subject to change, so the backup
may not be the same as the file could be a moment later, but
better than nothing at all.
Jonathan de Boyne Pollard
>
> 1.) reduce coding effort and reuse code that already exists
>
> 2.) enforce the same behaviour/look by providing the same piece of
> code for everyone to use
>
> 3.) reduce memory usage by having code shared amongst multiple
> processes, possibly even data
>
> That would speak for the global approach. The fact that you run into a
> bunch of troubles:
>
> 4.) the binary interface of a DLL changes
>
> 5.) the search algorithm that does not know any better than to look
> for filenames to find and load a DLL if necessary (at least the f/q
> filename ensures uniqueness but then it is potentially "too much
> uniqueness" from one system to the other so you will need to have
> configuration files for base paths etc.) or for module names (where
> the uniqueness of module names is not enforced in any way)
>
> 6.) 2 DLLs with the very same name but that have nothing to do with
> each other
>
> leads to all these workarounds where you effectively "roll back" what
> you are trying to achieve with 1.)-3.)
>
Not really, unless one doesn't learn the Unix definition of "same" which
is "same vnode". Learn that, and one still gets the ability to share
multiple instances of the "same" DLL, but one's definition of what is
the "same" now accords with the filesystem's. The same vnode means the
same program image, which means the same library.
> In any case, we have to live with what IBM has left behind for OS/2.
Not if the OSFree people get their act together. (-:
Ilya Zakharevich
> Put another way: Making IBM OS/2 work "Sensibly, like Unix works."
This is just an illustration how much "inverted" your logic is.
Nobody in their right mind would call the way Unix works "sensible"
(at least w.r.t. DLL resolution) - unless all they know is Unix, and
they know no other architecture. Especially taking into account that
there is no such thing as "Unix".
On Unix, when you call foobar(), you never know whether you got the
function you meant to call, or a function in an unrelated DLL, or -
worst of the case - a non-function (data) in another DLL. It is a
russian rulette, and the only viable solution for any program of
non-trivial size is to use a unique symbol prefix for every library.
IMO, the OS/2 (or AIX [which gives you yet more flexibility]) way is
significantly more "sensible".
Hope this helps,
Ilya
Ilya Zakharevich
> Jonathan de Boyne Pollard writes:
>
>> No. The point of DosReplaceModule() was to give some equivalent to
>> functionality that is simply *there* on Unix. It exists because EXEs
>> and DLLs (and indeed any sort of open file) cannot be deleted.
>
> One of the problems I've encountered is that open files cause
> problems for backup programs. I really think there ought to be
> a way to copy a file even while it's open.
There is no problem with copying a file which is open. Probably, you
mean a file file which read-locked? There must be a reason for
that, right?
> I hate to have a
> backup program "successfully" complete, only to have a bunch of
> files missing from the backup because they were open at the time.
> Yes, I know an open file is subject to change, so the backup
> may not be the same as the file could be a moment later, but
> better than nothing at all.
No, it is not better. It would be better if they were "stored
separately" as unreliably-copied, so restore would require a manual
intervention. Does any backup program do it?
Ilya
Ruediger Ihle
> Here's something for you to check, M. Ihle: Is the modname of "A.DLL"
> actually "A"? It normally will be, but it's possible to adjust that
> with linker options, so it's important to check.)
Yes, it is.
--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Please remove all characters left of the "R" in my email address
Ruediger Ihle
> Put another way: Making IBM OS/2 work "Sensibly, like Unix works."
> for all of the programmers who say that they want that, breaks the
> applications of the Ruediger Ihles of this world, who design their
> programs on the assumption that IBM OS/2 has the same global module
> table with globally unique modnames that it and DOS-Windows 2.x had
> back in the late 1980s. (-:
Did I mention, that I didn't design anything here ? This is a
port of an existing application that is currently available on
Windows, Linux and MacOS. Any critics on the general approach
should be directed to someone at http://developer.qt.nokia.com/
> The Ruediger Ihles of this world want OS/2 to work "Sensibly, like
> Win32 does." so that they don't have to have separate code for OS/2
> with different semantics to Win32
Of course I want to the keep OS/2-specific changes / extensions at
an absolute minimum. Especially, when it comes to code that is not
part of the lower level OS abstraction layer. OS/2 is not a major
platform and as such it can be very hard to convince the projects
maintainers to accept those type of changes...
--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Jonathan de Boyne Pollard
>>
> This is just an illustration how much "inverted" your logic is.
>
No, it's an exhibition on your part of the Usenet tendency to hit that
reply button before even getting to the end of a sentence. Here's the
*whole* sentence:
> Making IBM OS/2 work "Sensibly, like Unix works." for all of the
> programmers who say that they want that, breaks the applications of
> the Ruediger Ihles of this world, who design their programs on the
> assumption that IBM OS/2 has the same global module table with
> globally unique modnames that it and DOS-Windows 2.x had back in the
> late 1980s.
>
Indeed, there's a whole paragraph there, including various "Sensibly"s
of different stripes, providing a context to the quote that you decided
to hit reply before reading beyond. Pretty much the whole of what you
said, being based upon such Usenet nitwittery, is thus quite wrong. Go
back and read.
Jonathan de Boyne Pollard
> newsreader setting and post answers only to the right group and thread.
>
This is Usenet. Cross-posting is *proper* and the *norm*, here. And
discussions of OS/2 programming and OS/2 bugs are on-topic in newsgroups
for OS/2 programming and OS/2 bugs. It's not as though we're talking
about OS/2 programming and OS/2 bugs in alt.english.usage or something.
There are some 25 years of Frequently Asked Questions documents
explaining these, the basics of Usenet, for you. I'm too busy at the
moment to waste my time repeating such basic stuff for you. Find them
for yourself, read them, and learn.
Jonathan de Boyne Pollard
>> for all of the programmers who say that they want that, breaks the
>> applications of the Ruediger Ihles of this world, who design their
>> programs on the assumption that IBM OS/2 has the same global module
>> table with globally unique modnames that it and DOS-Windows 2.x had
>> back in the late 1980s. (-:
>>
> Did I mention, that I didn't design anything here ?
>
I actually rather took it for granted that you were working within a
framework set by someone else, given that you said that you were writing
plug-in DLLs. (-: That's why I phrased it like that, trying to make it
clear that I wasn't laying this at your door specifically, but that
rather you were an example of the desire, the motivation, the want, the
pressure. This is all about how applications programmers want and press
for the operating system to behave, which is, as I said, "Sensibly, like
Unix does", "Sensibly, like Win32 does.", or "Sensibly, like DOS-Windows
2.x.". If you're about to comment that they all conflict, then you're
getting one of the points made. (-: But another point is that it's the
people who think that the things that they grew up with on DOS and
Windows are "sensible" (including things like the side-effects of an
operating system implementation that uses global module tables, global
socket handle tables, device names in every directory, and so forth) who
are the inertia that frustrates those who say "It's been 30 years.
Can't we finally lose this CP/M-inspired rubbish and do things right, now?".
> Of course I want to the keep OS/2-specific changes / extensions at an
> absolute minimum. Especially, when it comes to code that is not part
> of the lower level OS abstraction layer. OS/2 is not a major platform
> and as such it can be very hard to convince the projects maintainers
> to accept those type of changes...
>
I suspect that a great many of us have experienced the same thing. You
are not alone. But again what this is about is the knock-on effects of
that. You want to keep platform-specific code for OS/2 to a minimum.
So you want OS/2 to work as much like Win32 as possible. So you want to
be able to use tricks like those used on Win32. But the Win32 tricks
themselves, like the OS/2 behaviour, have their roots in two and a bit
decades of backwards compatibility for the sake of applications that
expect IBM OS/2 1.0 and DOS-Windows 2.x with their global module
tables. The world learned better after a few years of experience of
that, and Second System Effect gave us DOS-Windows 9x with per-process
module tables and Windows NT. (IBM OS/2 still has the global module
table.) And the world tries hard now to give sensible semantics to
these things, that work *right* and do *not* have the problems of (say)
accidentally importing entirely the wrong DLL because it just happened
to have the same internal name as something completely unrelated. (On
this point, see Raymond Chen's Win32 programming advice never to give a
DLL the name "Security.DLL" for an example.) But the IBMs and
Microsofts of this world are constrained by the fact that if one adopts
the sensible semantics *completely*, learning from experience of the
wrong design, it breaks the applications of the Ruediger Ihles of this
world, as you've discovered.
It's perhaps only the OSFrees of the world who are in a position to say
"We're going to be this compatible, and no farther, with the bad ideas
of the past.". The IBMs and Apples and Microsofts of the world get
moaned at by the Rich Walshes of the world for ten years when they try
to stop poor design choices from 1986 causing well-known problems, as
you can observe. (-:
Allan
> > In any case, we have to live with what IBM has left behind for OS/2.
>
> Not if the OSFree people get their act together. (-:
It sure would be nice with a better implementation in OSFree,
but that would require more programmers, if it should happen
in this century.
Currently, close to nothing is going on......
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Jonathan de Boyne Pollard
> can think about if his behavior still matches the current situation.
> But I fear he has decided to stay in his corner and try to convince
> people to do it the way he thinks is the right one.
>
You're the person with the bizarre idea of what's right that's trying to
impose it on others here, not anyone else. Notice that it's *you*
telling *us* what to do, not us who came to you. Now get yourself off
to those 25 years worth of Frequently Asked Questions documents
explaining the basics, including how a good newsreader only shows a
single message once, and learn how Usenet works.
Jonathan de Boyne Pollard
>>>
>> Not if the OSFree people get their act together. (-:
>>
> It sure would be nice with a better implementation in OSFree, but that
> would require more programmers, if it should happen in this century.
> Currently, close to nothing is going on......
>
More programmers isn't necessarily the answer.
Allan
Well, since there currently is less than 1 working on osFree,
I DO believe, that more programmers are needed :-)
Peter Flass
Agreed.
Peter Flass
As I said, I come from a mainframe background. The zOS equivalent of a
DLL is a set of programs in LPA. IBMs all-language runtime library is
"Language Environment"(LE) although I believe it is possible to use a
private copy. Almost all programs run quite happily using the default
LE in LPA through numerous system upgrades or new versions of LE. It is
a rare occurrence that existing code can't use a newer version. I'm not
sure I can remember any such time thru numerous upgrades.
Jonathan de Boyne Pollard
> believe, that more programmers are needed :-)
>
How do you know the number? That's certainly not the number of people
that the Subversion change logs for the project indicate.
Allan
We do talk together every day at
irc://efnet/#osfree
so I think I have a clue :-)
Sure there might have been many people contributing something over
the last decade, but I doubt you'll find much more than one within the last
6 months.
Actually, looking at:
http://osfree.svn.sourceforge.net/viewvc/osfree/trunk/?sortby=rev&view=log
I think you can find 3 since 24 aug 2009
Jonathan de Boyne Pollard
>>> believe, that more programmers are needed :-)
>>>
>> How do you know the number? That's certainly not the number of people
>> that the Subversion change logs for the project indicate.
>>
> We do talk together every day at
> irc://efnet/#osfree
>
So the reason that nothing is happening is that they're spending all of
their time talking to you day after day on IRC instead of working on the
project? (-:
Allan
It sure looks that way, doesn't it ? ;-)
Anyway, as you can see, we really need more people to help out here,
if anything usefull from osFree project should be available in this
decade.
Trifle Menot
wrote:
>> So the reason that nothing is happening is that they're spending all of
>> their time talking to you day after day on IRC instead of working on the
>> project? (-:
>
>It sure looks that way, doesn't it ? ;-)
>
>Anyway, as you can see, we really need more people to help out here,
>if anything usefull from osFree project should be available in this
>decade.
If you could disassemble every line of OS2 code and reverse engineer it
flawlessly, what would be the point? The market for it is a ghost town
now.
--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
Peter Flass
> On 26 Mar 2011 16:09:33 +0100, "Allan"<all...@warpspeed.dyndns.dk>
> wrote:
>
>>> So the reason that nothing is happening is that they're spending all of
>>> their time talking to you day after day on IRC instead of working on the
>>> project? (-:
>>
>> It sure looks that way, doesn't it ? ;-)
>>
>> Anyway, as you can see, we really need more people to help out here,
>> if anything usefull from osFree project should be available in this
>> decade.
>
> If you could disassemble every line of OS2 code and reverse engineer it
> flawlessly, what would be the point? The market for it is a ghost town
> now.
>
>
Probably always a tiny market, but the fact that people are still using
OS/2 (and posting to the ng) indicates it's not a nonexistent market.
If you had a working source you could finally fix some of the problems
and ake needed extensions. Heck, I just paid over $100 for eCS.
A.D. Fundum
problems
> and ake needed extensions. Heck, I just paid over $100 for eCS.
I often save over $100, for one because I don't need a frequently
crashing 2THz CPU with 6GB of RAM and a harddisk larger than 10-20 GB
just to keep up with "OS requirements". I certainly don't need a free
OS as such. It may be better to stop to try to support anything and
focus on a limited (but complete, and slowly growing) choice of
hardware. E.g. 2 or 3 brands (C(heap)-brand, B-brand, I-brand) , 3 or
4 models (e.g. desktop, business notebook, notebook, netbook), and 3
or 4 types (cheap, normal, gadget). After all, even if developers try
to support much hardware configurations, I'm still not sure I can buy
a random machine at a local shop, nor do I know if anything will work
properly. With a limited number of users, there's no real need to
support "anything". And other components, like a webbrowser, are
perhaps more important than a CMD.EXE replacing the former CMD.EXE.
--
Trifle Menot
wrote:
>> If you could disassemble every line of OS2 code and reverse engineer it
>> flawlessly, what would be the point? The market for it is a ghost town
>> now.
>Probably always a tiny market, but the fact that people are still using
>OS/2 (and posting to the ng) indicates it's not a nonexistent market.
>If you had a working source you could finally fix some of the problems
>and ake needed extensions. Heck, I just paid over $100 for eCS.
OS/2 may be interesting to hard core geeks who disassemble object code
for fun. But with so many open source OS already available, how could
the effort be justified? Why not migrate to one, as the majority have
already done?
Allan
> On 26 Mar 2011 16:09:33 +0100, "Allan" <all...@warpspeed.dyndns.dk>
> wrote:
>
> >> So the reason that nothing is happening is that they're spending all of
> >> their time talking to you day after day on IRC instead of working on the
> >> project? (-:
> >
> >It sure looks that way, doesn't it ? ;-)
> >
> >Anyway, as you can see, we really need more people to help out here,
> >if anything usefull from osFree project should be available in this
> >decade.
>
> If you could disassemble every line of OS2 code and reverse engineer it
> flawlessly,
Well, there is already another group trying that approch :-)
osFree aimes at doing it a more legal way, and hopefully
in a better way too.
>....what would be the point? The market for it is a ghost town now.
Well, so is DOS, Amiga, Beos .........but plenty of people are still
interested.
According to Mensys, who sells eComStation, the number of users
(read sold licenses) are raising again.
So interest is still here...
Doug Bissett
<trifl...@beewyz.com> wrote:
> OS/2 may be interesting to hard core geeks who disassemble object code
> for fun.
That isn't true. Most users are those who don't want to deal with
windows, or Linux, viruses, and other malware. They also recognize
the superiority of the WorkPlace Shell, over all other user
interfaces.
> But with so many open source OS already available, how could
> the effort be justified? Why not migrate to one, as the majority have
> already done?
Unfortunately (perhaps fortunately, because disassembly is not the
final answer), most of the "disassemblers" have already gone to Linux.
Those of us who are left recognize that OS/2 (now known as
eComStation) is far superior to virtually all other platforms. All it
needs is a little tender loving care to work out the bugs, and add new
things that were never even thought of when OS/2 was abandoned by IBM.
The success rate is actually pretty good, but there are far too few
people capable of doing the job, and far too many who are sitting back
waiting for others to do it for them.
--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
Trifle Menot
wrote:
>> If you could disassemble every line of OS2 code and reverse engineer it
>> flawlessly,
>Well, there is already another group trying that approch :-)
Shouldn't take more than 100 years to understand it all, I suppose.
>osFree aimes at doing it a more legal way, and hopefully
>in a better way too.
Without the 100 year approach, it's guesswork. It's hard to achieve
"better" with guesswork.
>>....what would be the point? The market for it is a ghost town now.
>
>Well, so is DOS, Amiga, Beos .........but plenty of people are still
>interested.
I still play around with DOS. But source code can be found for DOS.
>According to Mensys, who sells eComStation, the number of users
>(read sold licenses) are raising again.
Unless they license the source code, it's a dead end.
Source code is the future. The dodo birds at IBM should have known that
back in 1970 when they restricted their mainframe OS to object code only
distribution. That policy helped them fight Amdahl and the other plug
compatibles, but in the long run, it hurt IBM more than it helped them.
Any entity selling software with object code only distribution is headed
for oblivion. It's only a matter of time.
Trifle Menot
<dougb007!SP...@Use-Author-Supplied-Address.invalid> wrote:
>> But with so many open source OS already available, how could
>> the effort be justified? Why not migrate to one, as the majority have
>> already done?
>Those of us who are left recognize that OS/2 (now known as
>eComStation) is far superior to virtually all other platforms.
Maybe the diehards believe that. But like Windows, it's not multiuser.
So how is that superior to linux?
>All it needs is a little tender loving care to work out the bugs, and
>add new things that were never even thought of when OS/2 was abandoned
>by IBM. The success rate is actually pretty good, but there are far too
>few people capable of doing the job, and far too many who are sitting
>back waiting for others to do it for them.
Then realistically, how is it possible? Sounds like wishful thinking to
me.
Doug Bissett
<trifl...@beewyz.com> wrote:
> On Sat, 26 Mar 2011 22:28:01 +0000 (UTC), "Doug Bissett"
> <dougb007!SP...@Use-Author-Supplied-Address.invalid> wrote:
>
> >> But with so many open source OS already available, how could
> >> the effort be justified? Why not migrate to one, as the majority have
> >> already done?
>
> >Those of us who are left recognize that OS/2 (now known as
> >eComStation) is far superior to virtually all other platforms.
>
> Maybe the diehards believe that. But like Windows, it's not multiuser.
> So how is that superior to linux?
No, but it is true multitasking. No other OS comes close to performing
like OS/2. Even Windows 7 has no hope of ever keeping up. Multi user
means nothing on a home computer,where one person uses it at any one
time. That is pure hype, from those who think it is actually useful.
>
> >All it needs is a little tender loving care to work out the bugs, and
> >add new things that were never even thought of when OS/2 was abandoned
> >by IBM. The success rate is actually pretty good, but there are far too
> >few people capable of doing the job, and far too many who are sitting
> >back waiting for others to do it for them.
>
> Then realistically, how is it possible? Sounds like wishful thinking to
> me.
Perhaps it is, but we will try to keep it going, simply because it is
better.
Doug Bissett
<trifl...@beewyz.com> wrote:
> On 26 Mar 2011 21:50:06 +0100, "Allan" <all...@warpspeed.dyndns.dk>
> wrote:
>
> >> If you could disassemble every line of OS2 code and reverse engineer it
> >> flawlessly,
>
> >Well, there is already another group trying that approch :-)
>
> Shouldn't take more than 100 years to understand it all, I suppose.
It is understood. The probelm is to convert understanding into code.
>
> >osFree aimes at doing it a more legal way, and hopefully
> >in a better way too.
>
> Without the 100 year approach, it's guesswork. It's hard to achieve
> "better" with guesswork.
"Guesswork" has nothing to do with it.
>
> >>....what would be the point? The market for it is a ghost town now.
> >
> >Well, so is DOS, Amiga, Beos .........but plenty of people are still
> >interested.
>
> I still play around with DOS. But source code can be found for DOS.
FreeDOS maybe. MS DOS, or IBM DOS, not likely...
>
> >According to Mensys, who sells eComStation, the number of users
> >(read sold licenses) are raising again.
>
> Unless they license the source code, it's a dead end.
Is it? Object oriented programming can be expanded. Programs can be
replaced. The problem is the kernel, and that is being analyzed.
> Source code is the future. The dodo birds at IBM should have known that
> back in 1970 when they restricted their mainframe OS to object code only
> distribution. That policy helped them fight Amdahl and the other plug
> compatibles, but in the long run, it hurt IBM more than it helped them.
IBM made a lot of very foolish moves in those days (and nothing much
has changed since then, IMO).
> Any entity selling software with object code only distribution is headed
> for oblivion. It's only a matter of time.
Any software, open source, or not, is headed for oblivion. It is only
a matter of time. So far, windows is winning with their underhanded
approach to marketing. The product certainly can't support the number
of sales. Linux has some hope of winning, eventually, but the user
interface is far behind windows and OS/2. OS/2 has the underlying
solid code base, that still outperforms either one of them. The
problem with OS/2 is that some parts need to be updated to run on new
hardware. That is happening, but it is slow going. My personal view
is:
-Windows is the only way to go for serious gamers.
-Mac is the only way to go for serious artistic work.
-Linux is for those who like to play around with software.
-eComStation (OS/2) is the only way to go for those who need to get
some work done.
We could argue for years about whether I am right, or wrong. I don't
intend to do that. If you wish to use some other platform, by all
means do so. I will stay with eComStation until I drop dead, or
something better comes along. So far, it looks like I will drop dead
first, and I don't plan to do that any time soon.
Andy
<trifl...@beewyz.com> wrote:
> On Sat, 26 Mar 2011 22:28:01 +0000 (UTC), "Doug Bissett"
> <dougb007!SP...@Use-Author-Supplied-Address.invalid> wrote:
>
> >> But with so many open source OS already available, how could
> >> the effort be justified? Why not migrate to one, as the majority have
> >> already done?
Because those who have not migrated generally either have something
that does not work on another OS or find the other OS's lacking. If
IBM had opened sourced SOM (they have OS/2, Windows, and AIX versions)
then a decent desktop could have been developed for Linux for
instance.
>
> >Those of us who are left recognize that OS/2 (now known as
> >eComStation) is far superior to virtually all other platforms.
>
> Maybe the diehards believe that. But like Windows, it's not multiuser.
> So how is that superior to linux?
Depends on your needs... I don't need, nor even care for multiuser for
personal use and in corporate environments I haven't found it to be
commonly used either for personal computers. For mainframe use of
course you would need multiuser. One way that it is superior is in
its Desktop. I use OS/2 (eCS really) for personal use and Linux
(instead of Windows) at work. I find the Desktop situation on Linux
almost appalling. It is arguable if even Windows doesn't have a
better Desktop than Linux.
>
> >All it needs is a little tender loving care to work out the bugs, and
> >add new things that were never even thought of when OS/2 was abandoned
> >by IBM. The success rate is actually pretty good, but there are far too
> >few people capable of doing the job, and far too many who are sitting
> >back waiting for others to do it for them.
>
> Then realistically, how is it possible? Sounds like wishful thinking to
> me.
Possible vs. likely I would grant you... however, just because the
current situation looks unlikely doesn't mean the situation cannot
change.
Andy
--
Trifle Menot
<dougb007!SP...@Use-Author-Supplied-Address.invalid> wrote:
>> I still play around with DOS. But source code can be found for DOS.
>FreeDOS maybe. MS DOS, or IBM DOS, not likely...
It's out there, if you know where to look. There's a lot of illegal
material floating around.
Or so I've heard. 8-)
Marty
> On Sat, 26 Mar 2011 22:28:01 +0000 (UTC), "Doug Bissett"
> <dougb007!SP...@Use-Author-Supplied-Address.invalid> wrote:
>
>>> But with so many open source OS already available, how could
>>> the effort be justified? Why not migrate to one, as the majority have
>>> already done?
>
>> Those of us who are left recognize that OS/2 (now known as
>> eComStation) is far superior to virtually all other platforms.
>
> Maybe the diehards believe that. But like Windows, it's not multiuser.
That's not an issue with the OS core. It's a shell implementation
issue. Filesystems exist with user permissions on OS/2. And an
alternative PMShell and console login have been created that allow
multi-user login to OS/2. These have existed for some time and are
quite mature on OS/2. If that's still no good, then we have a native
port of X.Org, which can run in place of PMShell or alongside it.
> So how is that superior to linux?
Unified multimedia API and programmer-friendly threading models jump to
mind without much thought.
>> All it needs is a little tender loving care to work out the bugs, and
>> add new things that were never even thought of when OS/2 was abandoned
>> by IBM. The success rate is actually pretty good, but there are far too
>> few people capable of doing the job, and far too many who are sitting
>> back waiting for others to do it for them.
>
> Then realistically, how is it possible? Sounds like wishful thinking to
> me.
Reverse-engineering seems to far-fetched for me too. But a work-alike
is not out of the question. One with backward binary compatibility
should even be possible. We have enough documentation and experience to
know what the expected behavior of most API calls should be. We don't
need their code to reimplement that behavior. And if this is
infeasible, then what is Wine?
--
Reverse the parts of the e-mail address to reply by mail.
Trifle Menot
wrote:
>Reverse-engineering seems to far-fetched for me too. But a work-alike
>is not out of the question. One with backward binary compatibility
>should even be possible. We have enough documentation and experience to
>know what the expected behavior of most API calls should be. We don't
>need their code to reimplement that behavior. And if this is
>infeasible, then what is Wine?
A project with enough workers to make it happen.
Paul Ratcliffe
<nospam-abwil...@nospam-gmail.com> wrote:
> Depends on your needs... I don't need, nor even care for multiuser for
> personal use and in corporate environments I haven't found it to be
> commonly used either for personal computers.
I'm amazed. Multiuser is used extensively in corporate networks.
Peter Flass
Gnome is now a pretty good GUI, but PM/WPS are still tops.
Peter Flass
> On Sat, 26 Mar 2011 17:54:42 UTC, Trifle Menot<trifl...@beewyz.com> wrote:
>
>> On 26 Mar 2011 16:09:33 +0100, "Allan"<all...@warpspeed.dyndns.dk>
>> wrote:
>>
>>>> So the reason that nothing is happening is that they're spending all of
>>>> their time talking to you day after day on IRC instead of working on the
>>>> project? (-:
>>>
>>> It sure looks that way, doesn't it ? ;-)
>>>
>>> Anyway, as you can see, we really need more people to help out here,
>>> if anything usefull from osFree project should be available in this
>>> decade.
>>
>> If you could disassemble every line of OS2 code and reverse engineer it
>> flawlessly,
>
> Well, there is already another group trying that approch :-)
> osFree aimes at doing it a more legal way, and hopefully
> in a better way too.
I don't think the OSFree project aims to disassemble and
reverse-engineer OS/2, though I have no connection with them. As I read
their web page, they're attempting to duplicate the OS/2 kernel
functionality on top of a microkernel and adapt FOSS software to do a
lot of the rest.
Peter Flass
> On 03/26/2011 03:52 PM, Trifle Menot wrote:
>
>> So how is that superior to linux?
>
> Unified multimedia API and programmer-friendly threading models jump to
> mind without much thought.
"Programmer-friendly" is a good point. I've recently been working on
porting some software to Linux and it's interesting how much work I have
had to do to duplicate functionality that's available off-the-shelf in
OS/2. It's taken a lot longer than I had anticipated.
Peter Flass
Yes, but not on corporate desktops (or any desktops). How often are
more than one person logged on to your home computer(s) at the same
time? - not file-sharing, print-sharing, etc., but actually logged on
and doing work. Actually I've used OS/2 as a multi-user system using
telnet.
Andy
Mutliuser systems I have seen it mostly in server environments such as
Citrix. But for desktops, and more commonly nowadays laptops, there
is commonly only one user per machine. Not that there are no other
arrangements but it certainly doesn't seem to be widespread. We are
looking into using thinclients and even then, on the server it will
have virtual machines running a single user instance of Windows.
Andy
--
Allan
> On Sun, 27 Mar 2011 01:44:04 +0000 (UTC), "Doug Bissett"
> <dougb007!SP...@Use-Author-Supplied-Address.invalid> wrote:
>
> >> I still play around with DOS. But source code can be found for DOS.
>
> >FreeDOS maybe. MS DOS, or IBM DOS, not likely...
>
> It's out there, if you know where to look. There's a lot of illegal
> material floating around.
>
> Or so I've heard. 8-)
Well, you can most likely find the sources for OS/2 in same places ;-)
Allan
> On 3/26/2011 4:50 PM, Allan wrote:
> > On Sat, 26 Mar 2011 17:54:42 UTC, Trifle Menot<trifl...@beewyz.com> wrote:
> >
> >> On 26 Mar 2011 16:09:33 +0100, "Allan"<all...@warpspeed.dyndns.dk>
> >> wrote:
> >>
> >>>> So the reason that nothing is happening is that they're spending all of
> >>>> their time talking to you day after day on IRC instead of working on the
> >>>> project? (-:
> >>>
> >>> It sure looks that way, doesn't it ? ;-)
> >>>
> >>> Anyway, as you can see, we really need more people to help out here,
> >>> if anything usefull from osFree project should be available in this
> >>> decade.
> >>
> >> If you could disassemble every line of OS2 code and reverse engineer it
> >> flawlessly,
> >
> > Well, there is already another group trying that approch :-)
> > osFree aimes at doing it a more legal way, and hopefully
> > in a better way too.
>
> I don't think the OSFree project aims to disassemble and
> reverse-engineer OS/2, though I have no connection with them.
You are right, and that is what I just wrote :-)
Peter Flass
Yes, I see; I misread what you wrote.
Alex Taylor
> >Probably always a tiny market, but the fact that people are still using
> >OS/2 (and posting to the ng) indicates it's not a nonexistent market.
> >If you had a working source you could finally fix some of the problems
> >and ake needed extensions. Heck, I just paid over $100 for eCS.
>
> OS/2 may be interesting to hard core geeks who disassemble object code
> for fun. But with so many open source OS already available, how could
> the effort be justified? Why not migrate to one, as the majority have
> already done?
Presumably, because none of them fit our needs as well as OS/2.
The best platform, for any given user, is whatever platform works best
FOR that user.
--
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00
Please take off hat when replying.
Jonathan de Boyne Pollard
>
People, you're being trolled. Witness the hiding behind the "Trifle Me
Not" pseudonym. The multiple basic errors of fact across several posts
are clearly deliberate and provocative. As are labels like "diehards".
Let's get back to the subject of OS/2 programming and ignore this
trolling, shall we?
Jonathan de Boyne Pollard
>>> for personal use and in corporate environments I haven't found it to
>>> be commonly used either for personal computers.
>>>
>> I'm amazed. Multiuser is used extensively in corporate networks.
>>
> Mutliuser systems I have seen it mostly in server environments such as
> Citrix. But for desktops, and more commonly nowadays laptops, there is
> commonly only one user per machine.
>
Ratcliffe's point. Although the laptops may be single *seat* (or single
*head*) they need to be multi-*user* in order to integrate within a
system where multiple user accounts exist. Usually there is some
corporate-wide user database and structure.
There's a confusion of terminology when it comes to the "multis". Being
multi-user means having the mechanisms for supporting multiple users, in
particular mechanisms for associating individual processes with
individual user account credentials. It doesn't require that that
support be *simultaneous* with multiple people physically sitting in
front of individual monitors with individual keyboards and mice. That's
usually termed multi-*head* or multi-*seat*. Your single-headed laptops
will often use multi-user operating systems, like Windows NT, that
associate the (user) processes running on the laptop with the
corporate-wide (network) account credentials of the (single) employee
logged into the machine.
Jonathan de Boyne Pollard
>
replacement for Workplace Shell that doesn't have all of the daft
Session Manager stuff in it? That would be good to have.
Lars Erdmann
>> Gnome is now a pretty good GUI, but PM/WPS are still tops.
>>
> On that subject, here's another "Whither". Is anyone working on a replacement for Workplace Shell that doesn't have all of the daft Session Manager stuff in it? That would be good to have.
>
Jonathan de Boyne Pollard
I take it from your useless post that you don't actually know the answer
to my question. I find it humourously ironic that you speak of wasting
bandwidth in a post that does nothing but. I continue to await a reply
from someone who actually does know the answer.
Trifle Menot
<J.deBoynePoll...@NTLWorld.COM> wrote:
>> Yes, you. Or stop wasting bandwidth.
>I take it from your useless post that you don't actually know the answer
>to my question. I find it humourously ironic that you speak of wasting
>bandwidth in a post that does nothing but.
People complaining about Usenet bandwidth like they're still using a
1200 baud modem.
I upgraded to 33.6 a long time ago. It's better than 640k of memory!
:-D
Andy
This is the only project I know about for replacing WPS (though choice
of platform was not chosen the last I knew of but as far as I know
there were builds being done for OS/2 by the developers). As far as I
know the project stalled out several years ago when the focus of the
project changed and took on infinite scope.
http://voyager.netlabs.org/en/site/index.xml
There is svn access but it is not open to the public so I can't see if
there has been any work done but there was a basically functional SOM
replacement from my understanding.
http://nom.netlabs.org/en/site/index.xml is merely a place holder on
the site.
You'd have to ask Adrian about getting access if you are interested.
His contact info can be found at
http://www.netlabs.org/en/site/index.xml
Andy
--
Peter Flass
> On Mon, 28 Mar 2011 20:31:48 UTC, Jonathan de Boyne Pollard
> <J.deBoynePoll...@NTLWorld.COM> wrote:
>
>>> Gnome is now a pretty good GUI, but PM/WPS are still tops.
>>>
>> On that subject, here's another "Whither". Is anyone working on a
>> replacement for Workplace Shell that doesn't have all of the daft
>> Session Manager stuff in it? That would be good to have.
>>
> This is the only project I know about for replacing WPS (though choice
> of platform was not chosen the last I knew of but as far as I know
> there were builds being done for OS/2 by the developers). As far as I
> know the project stalled out several years ago when the focus of the
> project changed and took on infinite scope.
> http://voyager.netlabs.org/en/site/index.xml
The quickest way I know to ensure nothing gets accomplished.
Jonathan de Boyne Pollard
> of platform was not chosen the last I knew of but as far as I know
> there were builds being done for OS/2 by the developers). As far as I
> know the project stalled out several years ago when the focus of the
> project changed and took on infinite scope.
>
That's one of the problems that one encounters. (-: Thank you. I'll
have a look.
> There is svn access but it is not open to the public so I can't see if
> there has been any work done but there was a basically functional SOM
> replacement from my understanding.
>
That's NOM. I've read about that. By all reports it isn't binary
compatible. That's not very useful for what I want.
Jonathan de Boyne Pollard
>> focus of the project changed and took on infinite scope.
>>
>
Closely followed by setting up a public bug tracking database? (-: