[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Future of cross compiling for Win32 (was: "Cross-compiling for Win32" script vs. rosBE? Debian Win32 port alive?)

On Sat, Jun 23, 2007 at 08:40:31PM +0930, Ron wrote:
> > We know this, but libtool doesn't. So you either leave the *.dll.a
> > in you package, or you have yet another thing to patch in all packages
> > that depend on that lib.
> Ahh.  Yet another reason I'll never use or recommend libtool. ;-)
> I really like autoconf, but some of the helpers built on top of it
> leave a lot to be desired in the real world.

This is not what I wanted to say. I think that libtool is a very nice
and non-intrusive tool. It's not libtool's fault. Many packages that
don't use libtool will have the same problem, but hard coded in their

Libtool may be updated in the future, thus most of the libtool-using
packages. The ones that don't use libtool will probably never follow
until one sends a patch to upstream.

I don't think this speaks against libtool in any way.

> > > that can help a little, making *.so
> > > and *.dll more similar in the way they are used in build scripts.
> > 
> > Unless you rename the *.dll files into *.so, you'll have to patch the
> > "*.files" anyway, thus having no chance to convince the package
> > maintainers.
> Yeah, and then that will cause its own problems with other things too.

Yes, and that's only one of the problems.

> I guess the fundamental problem is that we are pushing the bounds of
> 'traditional' portability.  Instead of just being portable between
> POSIX variants this adds several dimensions of additional incompatibility
> that need to be mapped somehow.

That's the point. I completely agree.

And this is maybe the main difference between those who cross compile
single apps (like me) and those who want build a free win32
distribution (like GnuWin32 and ReactOS).

> On some level I think that's going to be intractable to deal with unless
> upstream authors are directly engaged (or their work forked) to handle
> systems they don't already support.  With proper upstream support, the
> level of patching required for packaging should usually be minimal.
> Without it, not only the packaging, but the source itself may need to
> be patched.  If not now, then perhaps with some later release.
> OTOH, I suspect it is only a matter of time now before we see full
> POSIX support in future MS operating systems.

I don't think so. They already created their abstraction layer called .NET.
With Mono (and some other projects) we have a free implementation of
that layer.

Similar to NextStep/Cocoa (MacOS) and GnuStep.

Native support will become less and less important. Also, the
portability problems when creating a Mono-.EXE and running it in .NET
are surprisingly low, compared to all MinGW cross compiling issues.

> I'm personally growing
> in the opinion that until then, users of that system are best and most
> painlessly served by treating it as a dumb terminal that gives them
> a web browser interface to things running on a Real OS.
> That wasn't a practical solution when I first got serious about cross
> platform application development, but currently it seems to be maturing
> as a viable solution faster than some of the other options.

Yes, web applications are a very good way to free an organization from
Windows. First, move all apps to Web apps. If there are cross-browser
problems, just install Firefox or Seamonkey everywhere. In the last
step, replace all Windows boxes by cheap hardware running something
like DamnSmallLinux. ;-)

However, it's still the case that porting an application to Unix is
less work than transforming it into a web application. And if the
web application is not Apache but IIS based, you've won very little.
But as the server world is still dominated by Unix systems, maybe it's
more "politically correct" or more "developer friedly" to switch to a
web application than to port an application to Unix.

> That still doesn't work for everyone, or everything yet, but its been
> quite a while since it hasn't Worked For Me with my real life needs,
> and I suspect I'm far from alone in that.

I personally know the developer of TwoBirds, a very good AJAX framework
that does things "the other way", i.e. doing things explicitly instead
of building huge stacks of abstraction layers. My script is in some
respect based on the same design principles. TwoBirds allows you to
create very fast web applications in a clean way.

I work with and for some web developers, and I agree that you can do
very much "classic Desktop stuff" with web applications. This is
especially the case for organizations that "misuse" Office tools to
do CMS or Groupware stuff.

> As the user demographics shake out on a scale that might look something
> like: Win32 -> MacOS -> Lindows -> Ubuntu -> Debian, this certainly
> seems like an appealing solution for developers of EMDebian platforms
> that want to support all of these with their products.  Things like
> Google's office suite are certainly going to add to the measure of
> whether there really is much of a future for 'native' win32 apps.

For a long time the Unix world offers alternatives to every win32 office
tool. The great success of OpenOffice and Firefox manifest that. But
nevertheless, the market hasn't changes very much. People are slowly
switching to OpenOffice, Thunderbird and Firefox, but they don't switch
to Unix which would be very easy. (The hard step was to switch to
OpenOffice)  Life CDs and LUGs are doing a great job to change this,
but they still haven't been able to create an euphory of switching
to Unix.

Same with web applications: Even when everyone uses only a browser,
hardly anyone will switch to Unix.

For organizations, the reason might be that they have a lot of Windows
admins that cannot be easily "switched" to Unix admins.

For private users, the resons are the games, which will still run
mostly as native applications and still only a minority of games
runs on Linux. Well, that's not entirely true, but it's the prevailing

And exactly for games an other realtime applications, especially 3D
rendering an the like, native applications will still be feasible.
The future browsers might support OpenGL, but I don't think they
can speed up the JavaScript interpreter as necessary. So either a
much cleaner, standardized, less-with-HTML-mangled browser programming
language arises, or the really appealing games and simulation
applications will still be native ones.

> It's going to be interesting to see how the balance of these approaches
> evolves over time.  Especially if rather than going down the POSIX road
> MS really do continue to make their browser an inseparable primary
> interface to everything the user does on the machine.  Even if all some
> people use it for is to launch a 3rd party secure renderer of http
> streams ;-)

That component may be .NET. And who knows? Maybe C# will be that
new browser language I was talking about. IE will support it via
some ActiveX stuff, Firefox via Mono.



Volker Grabsch
NotJustHosting GbR

Reply to: