The Common Opensource Application Publishing Platform (CoApp)

Listen up folks, this stuff is big.

Today, I’m announcing the beginning of a project that intends to bring a little joy into the hearts of Open Source aficionados on the Windows Platform.

The biggest challenge to using/building/maintaining many Open Source applications on Windows, is that Windows does a lot of things differently than Linux and Unix . Different filesystems, command lines, APIs, user experiences … well, pretty much everything. Regardless of personal opinions about it being the ‘right-way’ or ‘wrong-way’, it suffices to say that it is just simply different. 

In order to build an Open Source application like PHP for Windows from scratch, I need to have a collection of libraries created from a fair number of different projects.  This creates a dependency between the code that I’m working on—PHP—and the project that supplies the library that I need.  It’s pretty important that I not simply rely upon a previously compiled version of the library (provided either by the project itself, or a third party) for a number of reasons:

  • I want to make sure that the library is compiled with the same version of the compiler and libraries as I use.
  • In order to fine-tune performance, I’m going to need to change the compiler settings.
  • As a security precaution against malicious third parties creating flawed binaries.
  • Hey!--It’s Open source. It’s pretty much a moral imperative that I compile the code for myself. Well, it is for me anyway.

Now, unfortunately, those dependencies don’t necessarily share the same development environments, practices, tools, operating systems, or even ideas as to how things should—from one’s own perspective—be done (because, as every developer knows, one’s own way is the ‘one true way’).

Interestingly, this problem really doesn’t happen on Linux (and other *NIX-like substances).  When someone builds that same application (PHP) on Unix, they do so knowing that the OS works a certain way (generally speaking), and along with the dark magic known as autoconf, you can put the source code on nearly any Unix-variant and just build it.

  Let me take a moment to talk about how this is done in the Linux/Unix world.  This isn’t nearly a problem there because nearly all libraries come with a ‘configure’ script of sorts which the developer runs prior to building the code, and the script checks the local development environment, determines the appropriate settings, compilers and dependencies, and creates a build script to match. You download the source, unpack it, run ./configure, make && make install.  If you are missing any dependencies, you download them, unpack, run ./configure && make && make install, and go back to the app.

Shared Libraries end up in a common spot (/usr/lib), header files end up in a common spot (/usr/include) and binaries can go into a common spot (/usr/bin).

There are some tools and conventions that make this all work pretty darn good, and when it doesn't, it's usually not much of a stretch to get it there.


When that same application needs to be built on Windows, it takes some effort. Finding the dependencies (like OpenSSL or zlib), and getting them to compile (which is inconsistent from library-to-library on Windows) and then building the application itself—again, inconsistent—generates a binary that you can run. Nearly all of the time, if someone posts those binaries, they bundle up their copies of the shared libraries along with the application.  The trouble is, that there is no common versioning, or really, sharing of shared libraries on Windows. If your app and my app both use the same library, they could (and often do) ship with a different version of it.

And, there is the user side of the equation…

Of course. Consumers of open source software on Windows have been relegated to manually scouring the Internet for binaries, and they are often out-of-date, compiled against older compilers and libraries, and pretty hard to get working. Clearly there is a strong need for a package management system, along the same lines as apt, rpm, synaptic (and others) but built for the Windows platform, and compatible with Windows features.

Why not adapt the Unix-way on Windows?

There are two fundamental reasons: Primarily, because it’s just not done that way on Windows.  And since Windows doesn’t “look” like Unix, it’s not very easy to use the same scripts on Windows as Unix. Sure, there are Unix-like environments for Windows (Cygwin, Mingw and Microsoft’s own SUA), but they really isolate the developer from Windows itself. While they do try to create a very Unix-like environment, you end up building Unix-style apps on Windows, and pretty much forego the platform benefits that are available.

Secondly, open source software that was originally written for Windows won’t be using Linux-style tools anyway. Since I want to unify these two groups, I’m going to want a one-size-fits-all solution.

Really, the solution is to build it right—for Windows.

So, what exactly does “Building it Right” mean anyway?

That is, in a nutshell, the sixty-four kilobyte question.

For starters, this means using the tools, methodologies and technologies on Windows, as they were meant to be used, in order to take advantage of everything that Windows has to offer. I’m not interested in simply making a knock-off of the Unix-style way of doing things. Windows doesn’t store binaries in c:\usr\bin (/usr/bin) and libraries in c:\usr\lib (/usr/lib), so we’re not going to do things like that.

CoApp will:

  • Provide a distributed, community driven package management system for open source applications on the Windows Platform
  • Handle multiple versions of binaries using WinSxS (I know, even the mention of side-by-side components evokes fear, anger and the desire to go off-diet, but bear with me, I think we’ve got a solution), including multiple copies of the same version of the same library, compiled with different compilers.
  • Support 64 bit and 32 bit systems, without hassle or collisions.
  • Place binaries, libraries and header files in a logical and consistent location.
  • Have tools and methods for handling dependencies.
  • Create reliable installer packages (MSIs) for installing open source software.
  • Facilitate sharing of components and allow multiple projects to easily both participate and consume them.
  • Allow for upgrades and patching of both libraries and applications.
  • Be Windows developer friendly. No forcing of building using ‘make’, but rather taking advantage of the nifty IDEs we already have.
  • Also be Windows admin friendly. Even if it’s open source, you shouldn’t have to be a developer to put Open Source applications on Windows.
  • Use advanced optimization techniques like Profile Guided Optimization to produce optimized binaries.
  • Support future technologies as they come along.
  • Aid in the adoption of Windows Error Reporting (WinQual) to assist in making software run better on Windows.
  • End the eternal struggle between Green and Purple. Unless of course you’re a Drazi and are conducting elections.

Tall order? You bet. Still, I believe that it’s all achievable. I’ve spent the last several months working on some proof-of-concepts, fleshing out some ideas, and talking with some open source community members. Nothing is currently set in stone, and even the specifications are very fluid at this point.

I’ve started a project on Launchpad at and the wiki at I’m just starting the specifications and tools to make this happen, and I welcome everyone’s input and contributions.

Comments (66)

  1. good luck! i spend over 5 years working on Open source apps on Windows and my end result is that it is just not worth the effort, expense of time and headache to push a square peg into a round hole.

    If you want to run open source apps on windows to screw around … that is ok but to do anything serious or to run your business you are better off running everything on Linux.

  2. Well, that’s what I’m here to change.

    Don’t get me wrong, it’s a big project, but I’m more than up to the challenge. It doesn’t hurt that I’ve already built proof-of-concepts on how to do pretty much everything.

    I’ve also recruited folks from Apache, PHP, Python and other communities to help out with this.

    I hope that you’ll be pleasantly surprised a year from now.

  3. gdmk says:

    I hope for great usability (and IDE Integration).

  4. @gdmk -> Me Too.

    Actually, it’s good to point out that IDE integration is extremely important to me. I’m both kinds of developers: the kind that works without an IDE and the kind that loves works with an IDE.

    One of my primary goals is that developers who only like to work in an IDE are kept as happy as possible. 😀

  5. Jones111 says:


    Please be aware that WIndows already has many features, Add-On software has. So instead of making a Apache-Package, you should first have a Webserver section that can install IIS, download php and configure both in a single action. Maybe additinally Wizard driven:

    I’d like to host Websites.

    X Stadard (.net)

    O php

    O java

    Finish / Continue

    I’d like to run Websites on:

    X IIS (Windows)

    O Apache

    Finish / Continue

    Specify folders / Settings / Startup / reoccurring jobs

    Highlight Software others used with the components installed. Maybe as a color gradient:

    [green] Expression Web 30 day Trial [XX% of all users that installed IIS downloaded Expression Web 30 day Trial]

    [white] ZHAHOJJS [no match]

    You’ve also mentioned Windows Admins and I think that you should allow Admins to prevent the install of packages or entire product groups or force an update, even if another user is installed. Normal users should be allowed to update or install packages for their own account without Admin rights.

    These are only a few thoughts, if I’ve got time, I’ll send in some other ideas while the project grows.

  6. Jake says:

    This announcement would’ve been bigger had you waited until you had something functional.

    How many times has Microsoft announced something like this only to let it fizzle out? How’s Interix going? SFU?

    Oh and the LAST community site you guys had for this specific purpose? Remember what it was called? I don’t. I remember the grand announcement, though.

    Actions speak louder than blogs.

  7. >> This announcement would’ve been bigger had you waited until you had something functional.

    Yeah, well, I need to be working with open source communities in order to get this accomplished. Waiting until I was done would be a bigger splash, but it would not allow the OSS community the opportunity to shape design and development.

    I’ve already got 5 non-Microsoft committers signed up.

    >>Oh and the LAST community site you guys had for this specific purpose? Remember what it was called? I don’t. I remember the grand announcement, though.

    I have no idea what you might be talking about.

    Regardless, this isn’t Microsoft’s project–it’s mine. They just happen to pay me to work on it.  

  8. Eric says:

    GarrettS you are my savior! As a Windows open source developer, this could be a dream come true! I’d love to be able to get involved too!

    I’m apparently on an exclamation point binge, but I’m just really excited!

  9. @Eric,

    If you want to get involved, the project site is at and the Wiki is at … the wiki is a static mirror today, it’s hosting being moved right now.

    However, sign up on Launchpad, join the mailing list there, and when the Wiki is read-write, register on there too.

    I’d more than welcome all the help you can provide.

  10. Jurgen says:

    Sounds like an excellent idea! In a way, Windows already has a feature along these lines "Control Panel/Programs/Turn Windows Features on or off".

    Could this be extended to "Turn OSS Features on or off"?

  11. @Jurgen

    I think that’s a bit too hard to find. And I’m pretty sure there is no public extensibility model for that.

    The CoApp installer should be pretty damn visible.

  12. Christian says:

    Microsoft’s pursuit of and willingness to prosecute software patents is a risk to all developers, OSS and otherwise.

    Why would I do anything to support their platform?

  13. SpliFF says:

    I like the sound of the package management but the concept of ‘no forcing the use of make’ in favour of ‘nifty IDEs’ sounds like pure fail. If those nifty IDE’s actually worked properly with ANSI code and didn’t fail so badly in so many ways I’d agree but for now most unix software will require a GCC toolchain to build without errors. Starting off with an openly hostile position towards the de-facto OSS toolchain isn’t going to help this project one bit.

  14. Todd M. says:

    I get where you’re coming from, and it makes sense.

    Just curious: would universal availability of PowerShell change one’s approach to OSS compilation and deployment, or is that mostly irrelevant? (Sorry, I’m not primarily a Windows person, so this kind of thing is unclear to me.)

  15. @SpliFF

    I’m not hostile to the defacto OSS toolchain… it’s just that it’s built for Linux/Unix, and not Windows.

    And, like it or not, Windows developers tend not to be comfortable with make, autoconf, configure scripts, etc.

    In order to get traction, I have to appeal to Windows developers, and get their asses off the bench to help. The way to do that is bridge the gap and bring them things they know how to use.

    And, no–most software doens’t require the GCC toolchain to build on Windows. I’ve built tons of it with VC…

  16. @Todd M.

    No, powershell doesn’t really solve anything in this regard.

  17. Krpalospo says:

    Well they know the open source way, when we know the windows way when can we use windows’ apps on open source unix, when ?????

  18. Moxi says:

    I think that you have a lot of work maybe for 5 years or maybe more, Im going to try to help to this platform.


  19. @Moxi

    It better not take me that long!

  20. Captjc says:

    Props on the awesome Idea and the Babylon 5 reference.

    Do you plan on incorporating some of the Free-as-beer offerings like Visual Studio Express and XNA Studio Express / XNA Framework into the project or repositories? It seems like this could be not only Apt-for-Windows, but a one-stop-shop for doing any type of hobbyist development on Windows.

  21. @captjc

    Re: B5 — thank you!! You are only the third person to even notice that. I thought it was the crowning acheivement of the post! ;D

    And yes. Eventually, that’s exactly where I want to be. Just don’t tell anyone.

  22. Mikko says:

    I think you are on the right track here.

    This will be extremely beneficial even with moderate success.

    There must have been thousands of times during my career (99% Unix / Linux) that I have wished something along these lines existed.

    Looking forward to this.

    I strongly feel the urge to call this a bridge.

    Because in real life, there exists a multitude of OS platforms including Windows.

    Your project is essentially about interoperability.

    Finally, the means to achieve that.

  23. Matthew Persico says:

    Before you go off totally re-inventing the wheel go look at what the Strawberry Perl folks have done with providing a toolchain. They don’t MSI, but it may provide a staring point for you to cut some development time. Or not. Just check it out.

  24. @Matthew

    I’ve looked at Strawberry Perl, the trouble is, I have a lot of scenarios to include, and I really really do need to use MSI.

    That being said, it’s not as much development work as it sounds 😀 …

  25. Sohail says:

    Err, hello! Please don’t forget other developers too. I’d love to hook into a MS sanctioned software update mechanism for my apps.

    apt-get is the biggest benefit of Linux and if you guys get it across the board… Well, I’ll have less to complain about.

  26. Adam Kennedy says:


    I’m the project leader for Strawberry Perl.

    1. We do use MSI for installation (of the main distro).

    2. We already support 3 different package formats side-by-side (source tarball, PAR packages, and ActiveState’s PPM packages).

    3. Don’t think that, just because we use what we use now, we wouldn’t switch if given the chance. And we’ve already been planning ahead should something like this project eventually appear.

    I also happen to be a CPAN admin. The CPAN and Perl toolchain teams have been dealing with this kind of source vs binary issues for over a decade now.

    We already have a build workflow that includes automated binary packaging for 5 different linux distros, two BSDs, the ActivePerl windows binary packages, and more.

    At a high level, switching Strawberry to MSI and building the "easy" 5,000-10,000 CPAN packages into CoApp packages doesn’t look like a big deal from here.

  27. @GarrettS, @"Matthew Persico"

    Actually, Strawberry Perl has an MSI installer now.

  28. This looks like great, look forward to seeing this!



  29. Andrioid says:

    Just to put this in Steve Ballmer’s terms. Isn’t this just ripping of all the "innovation" from the  open-source world?

    All joking aside, glad someone finally decided to do this for the Windows platform.

  30. PeterJC says:

    All sounds great; consistancy of build, dependancy gathering and deployment/installation is always good.

    However – how does CoApp sit with WIX – another MS sponsored open source(?) installer/build application.


  31. Paul Cowan says:

    I am the contributor of the horn project which has attempted to solve this probem:

    If you have any questions, please contct me:

    I have experience, I can share in this difficult field.

  32. Vasileios Anagnostopoulos says:

    Personally I would prefer a pkgsrc for msys/mingw with integration for codelite and/or codeblocks. More important would be a cross-platform pkgsrc around ant for java (jpackage is not for me and awfully) outdated. Since linux takes care of (1), I believe (2) is more important. Anyway, good luck.

  33. It would be nice if you started with an actual target, a large open source project which has a lot of dependencies. Bringing that real project to CoApp would make your decisions more useful than imagining a hypotetical use case.

    May I suggest you start with KDE for Windows ( ?

    – KDE already works on Windows, so no effort to port it

    – KDE has a hell of a lot of dependencies

    – KDE on Windows has its own installer, dependency-checker, installer-build tool (emerge), etc

    – It poses some interesting problems to library and application versioning, such as DBUS, autostarted daemons (kded.exe and some others), etc

    Compare what CoApp offers to what emerge from KDE on Windows offers, and make sure CoApp is 10x better than emerge. That would mean you are on the right path.

  34. Eddie Edwards says:

    This sounds like an awesome project.

    I’m interested in how you’re going to bring the "nifty IDEs" up to scratch to compete with "make" though.  A common idiom is build tool, execute tool over input data to make some C source, compile C source (think lex or yacc).  I can’t see how to do this in VS 2008 (I can do it by hand, but that doesn’t scale).  Make solves this kind of problem in its sleep, and those features are *widely* used.

    If your project creates an easier way to do this kind of thing in VS, I’ll be very happy.

  35. I wonder if the Open Build Service would be interesting for this – I know the devs would love to support building win packages as well, maybe cooperation is a good idea? You’ll have infrastructure right away, a pretty powerful buildfarm, lots of apps to be build and name recognition too…

  36. oh let me add that obs is on 😀

  37. Christophe says:

    That’s great news! There are far too many open-source programs on my Windows system that include copies of the same libraries, esp. gtk or qt.

    From a developer perspective, having to manage several library dependencies by hand is very time-consuming, especially as some libraries won’t compile with Visual Studio — most GNU libs, in fact. Compiling binutils with VS was simply not possible, it would have taken weeks to convert the configure to something saner. Having a community effort for distributing vcproj files for common libraries would be a godsend, as well as pre-built ones.

    By the way, the msi format is a slight pain but using WiX was very helpful and a rather straightforward process. I’d recommend providing both vcproj and WiX and MSI files.

  38. Wesley Parish says:

    I hope this works as specified; I just have some serious doubts about MSI.  I tried once to install some MS Windows software on Linux using Wine, and discovered, the hard way, that the problem was with MSI.  I googled hither-and-yon, and discovered that MSI had more than one "specification", if it could be called that, and MSI at one point in time was a different animal from MSI at a later stage.

    I think that’s a problem Microsoft itself has to face – is there any point in fancying up the various utilities according to whim, when the result is to piss off potential friends?

  39. John says:

    Windows is a lost cause — good luck wallowing in futility for the next year.  Get on the boat, most people have been staring down at Microsoft’s corpse since before Gates stepped down.

    Do you think no matter how well this project turns out (I expect epic fail) you can convince any real admin or developer that this is the right way to go ?

  40. dartdog says:

    Sounds great, could help the world. In the meantime I’ve been working with Python, which seems to have licked the majority of the issues mentioned and has a huge library of platform independent apps and interfaces.

  41. anotherone says:

    Nice Project but as mentioned allready..probably not all has to be reinvented…

    Are you aware of ?

    You probably just need to write the IDE for those XML Files and trigger the compile.

  42. schmeisser says:

    Have a look at CMake please. You can find it at

    It can create unix-style MakeFiles, Windows style IDE project files and using cpack it can package everything into RPM, DEB, … and NSIS windows installer programms. I’m sure they wouldn’t mind getting code for a MSI package generator.

    This could help not only windows folks but also the projects themself. Because let’s face it … nobody knows how that autoconf stuff works anyway.

  43. @PeterJC — WiX is a fundamental cornerstone of CoApp. Rob Mensching (the WiX project owner) is on our developer mailing list.

    @Adam Kennedy  — Very Cool, and encouraging. Once the CoApp developer toolset is in place, Perl is very high on my list, and I’ll be willing to spend alot of time to make sure the Strawberry Perl and CoApp are the best of Friends.

    @Pau Garcia i Quiles — KDE would be very cool. there are a lot of steps between here and there, but it’s definitely high on my radar.

    @Christophe — I’ll be providing all the stuff from source to vcproj/sln/wix scripts and everything…. eventually. 😀

    @Wesley Parish — well truth be know, I’m not using a lot of MSI… just the right parts that solve the problem.

    @John — Yes, I can expect to convince them. I’ve got a lot on board already, from developers to very large hosters, people are excited.

    @anotherone  — yes, WiX is part of this solution.

    @schmeisser — CMake would only fix part of the problem. (I’ve looked at CMake alot.) There are a quite a few steps that need to be addressed.  And, as much as autoconf sucks, alot of projects won’t go to CMake (go figure, eh?)

  44. KS says:

    Good idea, please implement an update mechanism.

  45. @KS — An update mechanism is part of the design.

  46. That certainly looks interesting, and would make Windows a much more viable platform for me in the longer term (although I’d really prefer it if Windows was more POSIX/UNIX-like).

    I’ve subscribed to the mailing list, but just wanted to say, boy, do I hate your choice of hosting/VCS. Launchpad is the worst of the big DVCS hosting trio (launchpad, github, bitbucket), and is also much worse than bzr is also the least popular of the three big DVCSes (and the slowest)…

  47. First off – I’m absolutely interested in working on this.  This has been one of my personal hells for… well, call it eight years…?

    Second, one place I’d suggest looking is at Gentoo’s Portage system – not as a solution, but as a model.

    Third, I want to put in a big vote *against* CMake.  That said, I don’t have a good alternative yet; suffice it to say that I think that the world is more than ready for a build tool which was actually *designed* from the ground up, instead of starting life as one project’s way to scratch their itch, and then "growing" like The Blob from there.  Consistent, well-designed, modern, well-documented syntax would be a great start (and IMHO CMake fails on all of those).  Out of frustration, I’ve actually started writing my own build tool – I have a list of about twelve requirements, and this was actually the impetus for my starting the build-tool blog I’ve put as my URL.

    I’m absolutely all about doing this.

    One suggestion/personal itch: I spent about three months working out a system to have a "standalone" build environment that could be quickly deployed to any machine, without having to go through eighteen installers (and the vagaries of service packs and the like).

    The first half was ripping apart a Visual Studio ("S-D-K, W-D-K, M-O-U-S-E!") installation, separating out the compiler and tools, headers, and libraries.  The second half basically reinventing Portage, running lots of grep, sed, and custom code in order to reliably build about fifteen different open-source applications with Visual Studio, including several which explicitly do not support such an environment.  This also meant doing both debug and release builds, and handling source/.PDB placement.  All in all… ugly hell.

    So I think I can fairly claim to have a good bit of experience on this front…!  🙂

  48. @Gordon Schumacher

    Welcome to my hell 😀

    Prior to my working at Microsoft, I was a die-hard Gentoo user, and I’d say that it’s a very large part of the influences to this.

    And, as for CMake, it doesn’t really solve a lot of what I’m aiming for, I’m not really interested in using it either.

  49. Good effort. Are you aware of the KitSetup package manager leveraged by the Windows Driver and Logo Kit teams?

  50. Some suggestions would be to put all of the libraries in one place (C:WindowsSystem32Libraries or something like that), and have the version and compiler information in either the name or metadata.  That way the different libraries could co-exist side by side.  And it will definitely eliminate the need for multiple copies of the exact same dll file in multiple locations.

    As for the libraries (dll files etc) I would create some type of licensing scheme to where anyone (both open and closed source) can use the same files.  That way major programs like Adobe and Symantec won’t have to store their own dll files–when the same one is there for use by GIMP or my project (and vice versa).  Of course this would require the source for all of the libraries (even those modified by closed source apps) to be open.  So anyone can decide if that library is right for them, or if they need to create their own.  Hence the licensing scheme.  It should provide that the code for the library is the only thing required to be open (and that any modifications you make need to be put in the open).

    As for the "make", don’t the IDE’s already have this as a part of their compile or build steps?  So, it would just become an update to the IDE to use the autoconf (or whatever variation of autoconf you choose).  Then it can all be seamless for the developer.

    I’m not much of a developer (as I’m only learning some code in my college courses) but I’ll help out in whatever ways I can.

    Have a great day:)


  51. asf says:

    WinSxS? so what about non admin/single user installs?

  52. John Pye says:

    Great to hear that MS is jumping in to solving this.

    I have also spent some time thinking about this problem a bit. I wrote something of a proposal over here:

    Maybe some of that is useful to you.

  53. James says:

    To the people asking for Windows to be more POSIX/Unix, perhaps they should look at SFU (Services for Unix), which provides a POSIX subsystem for Windows of the NT line (it is basically the descendant of the POSIX subsystem from Windows NT).  It comes with later versions of Windows Server and can be installed on XP (except Home).  It is a much more compliant and complete POSIX implementation than what Cygwin provides, f.e. forks are COW, threads are posix threads, etc.  This would be significant as Perl’s ithreads and forks are no longer emulated (Interix, what SFU is based on, is a supported target of Perl’s Configure script).  Also worth looking at in this regard are and

  54. Olaf says:

    Looking forward, this project contains usefull points that our project could profit from.

  55. AtomLB says:

    This sounds very interesting.  I have very little experience with programming so I"m not qualified to help but I run quite a few open source apps on windows.  I’ve thought for a while that it would be real useful to have some kind of open source app/package manager like apt in windows.  Then I could install programs I use from one place like I do with my ubuntu machines.  I like the sound of this.

  56. Vladislav Vaintroub says:

    +100 for the idea. It is big. Missing apt-get/yum/zypper is what makes Windows inferior to say Linux for OSS development.

    -100 for trying to reinvent the wheel (build system)

    I’m putting here a big PRO for CMake. Guys at Kitware did an amazing job and had invested 10 or so years into it.

    Instead, build  or distribution service should build on existing technologies. RPM and Debian did not come with new "make" tool, they did not reinvent autotools, they can play nice with both autotools and cmake or make for that reason.

    I’m saying that if CoApp would be trying to both create a build system and apt-get it does not have a chance to be ready in this decade and to be accepted by the OSS community which is looking for a single tools that works anywhere.

    If CoApp only concentrates on "apt-get" part while adding some missing pieces to CMake e.g to support MSI, than chances to be ready and get accepted are much better IMHO.

  57. @Vladislav —

    I’m not building a new build system. I’m using Visual Studio (MSBuild)

    What I am building is tools to transform *whatever* existing build process to one that Visual Studio supports.

    I spoke to Bill Hoffman (Kitware) *YESTERDAY* about this very thing.

    Now, luckily, the tool that actually generates the .vcxproj/.sln files is completely pluggable, meaning that with very little effort, it could churn out CMake scripts.

    Bill and I are going to sync up again over the next few weeks to see where we can accomplish this.

  58. Laete a.k.a Drak[X] says:


    MS Win-Get !?!?!?!?


    "win-get is an automated install system and software repository for Microsoft Windows written in pascal (for the command line client) and php for the online repository. The ideas for its creation come from apt-get and other related tools for the *nix platforms.

    The system works by connecting to a link repository. Finding an application and downloading it from the stored link using wget.exe . Then performing the installation routine (silent or standard). And finnally deleting the install file."

  59. Danny Staple says:

    Hi Garrett,

    This sounds like a great idea. Lets hope it works out!

    Got a couple of questions for you:

    Will you also make sure it is non-admin freindly? That is that software that is not say a webserver, but is more user space, will not hassle the user for admin rights unnecessarily with UAC?

    If it works with VC, can you also make sure it is VC express compatible for hobbyists? It’s one thing having an employer fork out for VS at work, but another doing so at home, especially when GCC + Eclipse is free.

    One other thing worth noting is that the usual add/remove programs dialogue in Windows, while the de-facto way of removing non system stuff, is one big flat list, which when many libraries and tools with dependencies are installed will look ugly. Perhaps one idea is to have in the dialogue a single CoApp bundle, with a "Change" button that launches a wizard that groups up packages (as do most Linux package managers), and handles dependencies. Heck – this could be used to add as well as remove packages if linked with update sources in a similar way to portage/apt/yum.


  60. Dungeon Dave says:

    Interesting article, but I think you have a number of problems to overcome, and it’s not clear to me if you’re trying to create a standardised compiling mechanism (like portage) or a way of standardising the installation of open-source apps (apt/yum).

    Either way, I feel that Windows isn’t quite ready for it – with the way directory structures exist with Windows and the challenge of getting vendors onboard.

    Good luck with it, though. The concepts themselves are sound – I’d like to see this succeed.

  61. Adriano says:

    Why should the linux community should put that large enforces to reinvent the well as square to run every free software on Windows machines? Sound like working for free for a multi billion dollars company that don’t like us.

    Some important softwares like Apache, PHP, etc must be windows compatible to gain share market and grow, but mostly nix softwares creators don’t have that will/needle.

    IMHO the Microsoft should respect and deep collaborate with the community first to gain admiration. The opensource works because we help and respect each other.

  62. Danny Staple says:

    Hmm – couldn’t stop myself. Windows will not be ready until somebody like Garrett does this – I think full steam ahead.

    I understand the distinction you are making between binary package managers like Apt/yum and source/build packaging like portage, however, for this project it looks like it will be trying to bring both things together, which I for one think is great.

    Having been a Gentoo user, as well as Suse and Ubuntu (yes also Redhat and Debian), I am familiar with them, and always would have loved to combine some of the strengths of both types of systems.

  63. David Fraser says:

    Yay, at last! I’ve been saying somebody should do this for years…

    Some of my perspective:

    * Yay for using MSI – presumably you include some kind of extra information in MSI files about their dependencies?

    * As somebody mentioned above, it would be great it you supported an opensource toolchain as well as the Microsoft one

    * Even if you’re using the Microsoft toolchain (and I understand the desire to have people using IDEs be happy), please make it so auto-building a source package is a single-step operation that doesn’t have to involve opening the IDE – this should be doable with the Microsoft make tools. Essentially you want to be able to say "get me the dependencies of this package, run the build, give me the output" without lots of clicking.

    * What’s your strategy for dependencies? Although the target platform’s totally different, apt-get and yum solve lots of finicky dependency problems – I think re-writing your own system for finding and deploying packages and resolving dependency issues is going to be more work than building on top of what’s already there

    * For people building commercial software on top of open source software, it would be great to be able to have additional repositories that can depend on libraries in the open ones

  64. Steve Walker says:

    I can’t help feeling that if this was worth doing it wouldn’t be necessary. After 10 years or so trying to get Windows admins/devs to consider open source solutions my main experience is that the prevailing culture on Windows is not the ‘do-it-yourself’ mentality that saw the creation of the OSS you’re aiming at but more a ‘I’ll-pay-someone-to-do-it-for-me’ culture. Creating a nice point and click repository of Linux ports might help get that software onto more Windows machines but would do

    nothing to promote the open-source ideal and help foster a healthy open-software community on Windows. Frankly, if the future of open-source on Windows is nothing more than a collection of ill-fitting Linux ports then Windows open source is dead and we

    may as well admit it.

    Also, I’m a little puzzled at your choice of Apache and Python – these already have excellent Windows versions which install as easily as any Windows apps I’ve used. As for PHP given its threading issues and the need to restrict it to a FastCGI host I’d say this is a good example of why some Linux apps will never work as well on Windows as on Linux and the ultimate pointlessness of looking to port them for anything other than development use.

  65. Dulob says:

    How about attacks and viruses. Windows has been the maintarget for attacks and Viruses… I think this project will open opportunity get infected with new kind of trojans and virues.

  66. Beni Paskin-Cherniavsky says:

    For Python on windows, the closest to Right Thing distro currently is – they provide independent modules as seperate installers (though EXE and not MSI), but you must install dependencies manually; if you opt to use their big install, you also get all dependencies and updates automatically.

    I guess they’d be happy to use CoApp instead for dependencies.

    Another projects that might make a lot of sense for early conversion to CoApp is Cygwin, which also currently uses its own dependency-managing installer.

    Because like it or not, software originally developed for linux will have a unixish build process, and Cygwin/Mingw provide the easiest path to replicate such build on windows.

Skip to main content