Windows porting
Karsten M. Self
kmself@ix.netcom.com
Sun, 13 Jan 2002 13:28:00 -0800
--P+33d92oIH25kiaB
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Responding to both Rick & Robin's posts (I guess that makes this an R&R
post....)
on Sun, Jan 13, 2002 at 09:44:18AM -0800, Robin Rowe (rower@movieeditor.com=
) wrote:
> > Judging from what I heard of the discussion, from where I was at the
> > end of the table, it sounded like one person repeatedly trying to
> > advocate such ports, and others surrounding him replying with
> > non-technical personal opinions of an OS-advocacy nature --
> > tantamount to a troller / trollee session. If there was any
> > substantial discussion of porting issues, I missed it.
Third repeat. Those who will do it will. Those who won't won't. Those
who'll attempt bludgeoning those from one camp into the other are being
nonproductive and should be ignored.
> I tried to have a substantial discussion of Windows porting issues,
> but that wasn't feasible with one person vocally opposed to the very
> idea of porting open source to Windows, who didn't want Windows users
> becoming accustomed to Linux applications running on Windows, didn't
> want to welcome Windows programmers to open source, and was against
> attempting to bring Windows programmers and users into Linux via the
> route of open source.=20
I hate fomenting gossip[1], but who was this? Free software is firmly
ensconced on legacy MS Windows. Might as well stop the tides.
Again, the legacy MS Windows franchise is reliant on providing a solid,
uniform, inviolate front of applications and protocols which lock the
user into the franchise. Small cracks out provide the means to an
incremental escape strategy. A combined strategy of replacing back-end
services _and_ providing alternative desktop applications -- OpenOffice,
AbiWord, Gnumeric (getting damned nice, pulled it out for the first time
in ages), Mozilla, Galeon (or K-Meleon), Perl, Python, etc. KDE's
already been ported to legacy MS Windows, and I take no small pleasure
in letting my legacy MS Windows friends^Wsufferers that they can run
such programs if they wish. Dropping the entry barriers is a Good
Thing=AE.
> I did mention the key points to porting C++ GUI apps to Windows, but
> that would have been easy to miss from the other end of the table.
>=20
> 1. Don't use fork(). Use threads instead.
> 2. Use a portable GUI library, such as GTK+ or Qt -- not Xlib or Xt.
> 3. There is no unistd.h. However, when Windows implemented Berkeley socke=
ts
> a lot of functionality found in unistd.h was needed. Look in
> winsock.h, stdlib.h, stdio.h, and io.h. You have to search.
> 4. If you support Win9x and not just WinNT/2k/XP there are extra gotchas
> because some Windows NT API calls in Win9x don't actually do
> anything or are incompletely implemented. For instance, named pipes
> don't work in Win9x even though the calls are there. (No, the VC++
> docs don't warn you that named pipes won't work in Win9x.)
Good, technical, issues.
Incidentally, is it possible to allow the emulation layer to run the
translations on the sly. Say, fork() to threads translations? I've no
idea, but it might make emulo easier.
> It is cleaner to anticipate a Windows port, rather than kludge one
> later. =20
<...>
> Motion picture studios such as DreamWorks now design their code to
> build on Linux, Irix, and Windows. They report that building and
> testing on multiple platforms helps them eliminate obscure bugs and
> requires little extra effort provided there was prior planning.
Agreed. This is the consistent theme coming from anyone who's done
anything multiple ways. The first way you do something always seems
"native", but after you've tried a few different variants -- whether
it's programming languages, spoken languages, or ethnic foods -- you
start getting an idea of the ur concepts underlying the discipline.
Many Unix app vendors went through the 32 =3D> 64 translation with Tru64
(then Digital Unix). The first time caused some pain and agony, but the
result was much cleaner code that ported far better among other
environments. According to Oracle, their GNU/Linux port was just a
matter of "typing make"[2]. _That's_ cross-platform leverage.
> My article in this month's Linux Journal is about porting the GTK+ Linux
> application Gothello (Othello) to Windows. It wasn't very hard.
Saw that, nice piece.
----------------------------------------
Notes:
1. A blatent lie. Of course I do.
2. Extensively noted at the time.
--=20
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? Home of the brave
http://gestalt-system.sourceforge.net/ Land of the free
We freed Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org
Geek for Hire http://kmself.home.netcom.com/resume.html
--P+33d92oIH25kiaB
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8QfvfOEeIn1XyubARAgR2AJ9nasOBKYAesycBhE70FWJU9xjrCgCfcE45
AS2hTmIJDcCVX3d1KFySa8w=
=A3ry
-----END PGP SIGNATURE-----
--P+33d92oIH25kiaB--