SCOUG-Programming Mailing List Archives
Return to [ 27 |
February |
2003 ]
Content Type: text/plain
Peter,
It's probably a mistake for me to have CCed this to
scoug-programming, but your remarks get to a core issue.
Let's understand that we have at least four projects involving
Windows emulation, two commercial (Lindows and something
involving Office support) and two open source (WINE and
ODIN). Note that none of them, fee or free, offer more than a
partial solution. ODIN took off from a project headed by Timur
Tabi while at IBM. That information coincided with my
presentation at WarpStock 98 in Chicago. That's over four
years ago.
We could really ask why after all this effort of emulating
essentially a fixed target (regardless of claims about "secret"
APIs) no effort has progress to completion. Both WINE and
ODIN involve "layering" a guest OS personality above a host.
Consider also that "porting" applications while not simple at
least does go to completion.
What difference exists between an "emulation" layer of a
guest on a host and porting? One attempts to run a native
application in a non-native environment and the other doesn't.
We should ask what makes emx so effective other than its
authors recognize what is practically sustainable and what is
not?
We will cover these questions as topics within our discussion
of programming in general in the SCOUG Programming SIG.
I will offer you a personal opinion. Sometimes we attempt too
little with the result that we expend too much, i.e. more than
necessary. Don't emulate Windows. Run it natively. Take the
same effort and the same knowledge, investing it in a
Window's personality on a micro-kernel base. Do the same for
OS/2 and Linux.
In that manner you eliminate the deficiencies of VPC, WINE,
ODIN as well as the continued efforts of porting and
unfortunately re-porting, e.g. gcc. The applications run
natively. No change in one operating environment has an
effect on another.
From my perspective the techies, for whom I have
considerable respect, have not only made it difficult for the
rest of us, but for themselves as well. They keep doing
contortions on getting pieces to work without somehow
getting them to work as a system.
The answer lies in not picking a leader or a direction but to
develop an understanding of the issues and their resolutions
comprehensible to the OS/2 community at large. I haven't
heard a lament about OS/2's Single Input Queue (SIQ) for some
time now. Maybe someone has thought through that the
alternative is Multiple Input Queues (MIQ) and they can't think
that one through.
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
Return to [ 27 |
February |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
| 
