coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

Hey Laura!

>> I'm coming in on the tail end of the conversation and haven't had time to
>> keep up with the list of late, so please bear with me.

Heh-heh... You've taken some threads and turned it into a tapestry! I gotta
split this up to address it all!

>> From what I know of the original MinGW project Mumit Khan set it up to use
>> the CRTDLL library commonly available on all Windows machines as the
>> runtime.  MinGW later switched to the MSVCRT library.  These are Microsoft
>> dlls distributed on all Windows machines.  

Yes, we use the bind to the same library in the CoApp bootstrapper.  The .lib
files for this are distributed with the WDK.

>> The idea was for MinGW compiled
>> programs to be able to run on any Windows machine without having to
>> distribute runtime libraries that might be under licenses that could make
>> them difficult to distribute.  For instance, a GNU GPL license would mean
>> you'd need to distribute your source code as well (which is what happens
>> when you use Cygwin as your build environment and compiler suite).

This is really not a problem for us--we're trying to build and package software 
that already exists.  Whether they link to GNU licensed libraries or not 
isn't really much of a concern.  (not that I'm a fan of the GPL, but for 
the purposes of what we're doing, it's not much of an issue).

>> First, unless you have a need for gzip specifically, I'd have a look at
>> porting bsdtar.  There's a Windows port in the mingw files and it's been
>> ported from a BSD version.  So, it's cross-platform and it's not so tied
>> into the GNU libraries. 

So, it's not so much about gzip specifically--I'm not worried about one tool
more or less, I'm much more concerned with actually taking projects and 
adapting them to Windows. If it was just a pure "can I get a version of gzip
on Windows", there's a gnuwin32 port that's only a couple versions old that 
is actually pretty trivial to compile with VC10. Unfortunately, the version 
following has an extremely large amount of changes to it, and that's where 
the real fun starts.

The challenge here, is to find projects, and do the work to adapt them. 
Yes, I want gzip. And bsdtar, and thousands of other open source projects
working on Windows. If there is something blocking us, we need to fix that.
And, fix it in the right way--not by providing a POSIX layer on top of 
Windows, but by doing the work to port, patch and maintain the project.


>> It also provides the functionality to unarchive
>> (and I believe archive as well) gzip files.  7za from the 7zip project
>> also handles gzip files if you just need a tool to access them and I think
>> it'll build with Visual C/C++.  I personally use these two instead of gzip
>> all the time anyway.

Yeaaaaah. If all I needed was the tool, I'd likely use something that's 
already compiled too... 

>> Second, I haven't looked at the gnulib code, but there must be a way to
>> get it to port to other Windows compilers.  You may just have to provide
>> the missing functionality.  

Uh, yeah. That's exactly what we're doing. Philip and Rafael both spent a 
some time looking into it. Generally, it boils down to a few things:

1. Compiler incompatabilities (Rare, but there are a few)
Fixable, usually by #ifdef 'ing your way around to replicating the behavior.

2. Missing APIs/Libraries 
This is happens either when there is a dependent library not yet ported, or
some underlying functionality of the OS is missing. In the case of the 
library being not ported, our philosophy is walk up the stack and port
that to Windows. The second case is where Node.js actually ran 
into trouble, their Asynchronous IO library was fundementally unportable 
to Windows without completely tanking performance.  The net result is 
that the project lead on Node was willing to make architectual changes
to the project to work around it. (Really, this is pretty rare too)
   
3. More often than not, it's lacking a good config.h file that will 
allow the project to compile, given enough effort to squeeze the c files
thru the compiler.

>> That's exactly what projects like gnuwin32
>> did.  That project even goes as far as to provide its own glibc. 
>> Although, I find the gnuwin32 glibc rather buggy when included directly in
>> projects, using pieces from it when licensing is compatible in order to
>> support missing functionality works really well with some projects.

I'm pretty sure that glibc shouldn't be neccesary for porting anything.
glibc doesn't provide anything we don't already have in some way elsewhere.

It's possible that it would provide a "more-seamless" (less-seamful?) layer
but it's just sugar and fat. :p

[End of part1]

Garrett