10 ms·

Having seen the source for a non-Bazaar OS (Windows), I can say that they are not built like cathedrals: Most of the original developers have long since moved

by RachelF 10y ago

Having seen the source for a non-Bazaar OS (Windows), I can say that they are not built like cathedrals: Most of the original developers have long since moved on, there are design problems, various teams and managers rebuild or duplicate work, and management sometimes imposes big changes just before release. Software quality is hard to judge from the outside, and takes longer to build.

flukus 10y ago
This is a good point, I wonder if cathedrals really exist in the real world? I suspect they are all just isolated bazaar's.
dfox 10y ago
Windows (at least for userspace components) has significantly less self-contained modules (which thus contain larger amounts of functionality) than any modern unix-based system and there are almost no modules that are widely used and not supplied by Microsoft (excluding stuff that is ported from unix and various third-party hardware APIs). One of reasons for that is probably that before .NET, there was essentially no support in VS for building applications as anything other than big self-contained .EXEs and the current solution/project mechanism leaves much to be desired.
- asveikau 10y ago
  What the hell are you talking about? Just take your Unix mentality and make a few substitutions: * gcc -> cl.exe * ar -> lib.exe * ld -> link.exe * make -> nmake.exe * libfoo.so -> foo.dll And there you have it, the world that "didn't exist before .NET" ... This is crazy amounts of ironic because Windows had DLLs at a time when shared libraries were not so much a thing on Unix. Not to mention things like COM which are all about creating de-coupled components.
  - douche 10y ago
    Do you remember DLL hell? Pepperidge Farms remembers /s
    - asveikau 10y ago
      Library ABIs are hard. Same is true with shared libraries if you're not careful. I don't think it's necessarily the fault of the tooling.
      - mcguire 10y ago
        The tooling didn't include version numbers.
        asveikau 10y ago
        On Unix there is nothing to stop you from creating libfoo.so without a version number in the filename. Conventions for doing the latter part came about over time. As they did on Windows too (see msvcrtxxx.dll, where xxx is a version number). These days there is also WinSXS on Windows which I don't really expect HN users to know about and is probably not relevant to the historical context. Microsoft did really fuck it up historically (IE overwriting shell32 comes to mind) but the mechanism didn't have problems when applied by the right hands (sometimes a first party is the wrong hands :P) If you want to talk problems in the mechansim, ask me sometime how it's possible for a Win32 process to host multiple incompatible malloc implementations in the same address space.
        mcguire 10y ago
        "As they did on Windows too (see msvcrtxxx.dll, where xxx is a version number)." I didn't use Windows enough to know more about it than that let you have multiple copies of the libraries. Did it let you upgrade a compatible library? "If you want to talk problems in the mechansim, ask me sometime how it's possible for a Win32 process to host multiple incompatible malloc implementations in the same address space." I think I'll pass, thanks. :-)
  - marcus_holmes 10y ago
    I still miss COM. It had its problems, sure, but it worked really well. I haven't seen anything since that allowed such decoupled development
    - flukus 10y ago
      It came back with a vengeance in windows 10.
      - marcus_holmes 10y ago
        really? I must have missed that... I stopped doing windows dev around Vista, because Vista. Any details?
        pjmlp 10y ago
        The UWP programming model, which was introduced in Windows 8 as WinRT is COM. Basically it is the original idea of .NET, which as called COM+ Runtime, before they decided to create the CLR. WinRT is nothing more than COM+ Runtime, but with .NET metadata instead of COM type libraries. Also since Vista, the majority of new Windows native APIs are COM based, not plain C like ones.
    - mike_hearn 10y ago
      I think you have rose tinted classes on. COM is/was a rats nest of confusing and frequently duplicated APIs with insanely complicated rules that by the end really only Don Box understood. CoMarshalInterThreadInterfaceInStream was one of the simpler ones, iirc. COM attempted to abstract object language, location, thread safety, types, and then the layers on top tried to add serialisation and documented embedding too, except that the separation wasn't really clean because document embedding had come first. Even just implementing IUnknown was riddled with sharp edges and the total lack of any kind of tooling meant people frequently screwed it up: https://blogs.msdn.microsoft.com/oldnewthing/20040326-00/?p=40033 https://blogs.msdn.microsoft.com/oldnewthing/20040326-00/?p=... The modern equivalent of COM is the JVM and it works wildly better, even if you look at the messy neglected bits (like serialisation and RPC).
  - dfox 10y ago
    I'm not saying that it wasn't possible, but that it wasn't exposed in Visual Studio in usable way. As for COM, it seems to me that most common reason why something developed by some ISV is separate DLL is that it's COM component.
    - asveikau 10y ago
      Firstly, I always remember VS having click through wizards for creating libraries. So I think you are even wrong on that. Moreover, what a sad world for our profession when an IDE doesn't do something for you and people start to doubt it exists. Reminds me of kids on here saying a programming language without a package manager might as well not exist at all.
    - soundwave106 10y ago
      Er... Prior to .NET, the previous "enterprise targeted" language for Windows was Visual Basic. Visual Basic absolutely supported creating COM DLLs. On 6.0 (and perhaps earlier) there's even some nice templates for "ActiveX DLLs" (ActiveX being the Microsoft buzzword for certain COM objects at the time).
- pacaro 10y ago
  At my first job (94-97) we were writing a (16bit) Windows application that was a relatively slim EXE and several hundred DLLs. This wasn't necessarily the mainstream approach, but it was supported just fine by the tools. What didn't really exist was a mechanism to safely use DLLs from 3rd parties, and sometimes even from MS. DLL hell was very real, but shared objects in any system will always have the same challenge. You are at the mercy of the module writer not breaking binary compatibility without bumping a version number (or part thereof)
Clubber 10y ago
Well, in all fairness, that's a 30+ year old codebase. There have been a lot of fingers in there and a lot of hard deadlines.
aidenn0 10y ago
That still sounds like a Cathedral. The whole point of a Bazaar is that there is nobody to impose big changes. Also, in the original essay the Cathedral wasn't Microsoft, it was GNU.

by RachelF 10y ago

flukus 10y ago

This is a good point, I wonder if cathedrals really exist in the real world? I suspect they are all just isolated bazaar's.

dfox 10y ago

Windows (at least for userspace components) has significantly less self-contained modules (which thus contain larger amounts of functionality) than any modern unix-based system and there are almost no modules that are widely used and not supplied by Microsoft (excluding stuff that is ported from unix and various third-party hardware APIs). One of reasons for that is probably that before .NET, there was essentially no support in VS for building applications as anything other than big self-contained .EXEs and the current solution/project mechanism leaves much to be desired.

asveikau 10y ago
What the hell are you talking about? Just take your Unix mentality and make a few substitutions: * gcc -> cl.exe * ar -> lib.exe * ld -> link.exe * make -> nmake.exe * libfoo.so -> foo.dll And there you have it, the world that "didn't exist before .NET" ... This is crazy amounts of ironic because Windows had DLLs at a time when shared libraries were not so much a thing on Unix. Not to mention things like COM which are all about creating de-coupled components.
- douche 10y ago
  Do you remember DLL hell? Pepperidge Farms remembers /s
  - asveikau 10y ago
    Library ABIs are hard. Same is true with shared libraries if you're not careful. I don't think it's necessarily the fault of the tooling.
    - mcguire 10y ago
      The tooling didn't include version numbers.
      - asveikau 10y ago
        On Unix there is nothing to stop you from creating libfoo.so without a version number in the filename. Conventions for doing the latter part came about over time. As they did on Windows too (see msvcrtxxx.dll, where xxx is a version number). These days there is also WinSXS on Windows which I don't really expect HN users to know about and is probably not relevant to the historical context. Microsoft did really fuck it up historically (IE overwriting shell32 comes to mind) but the mechanism didn't have problems when applied by the right hands (sometimes a first party is the wrong hands :P) If you want to talk problems in the mechansim, ask me sometime how it's possible for a Win32 process to host multiple incompatible malloc implementations in the same address space.
        mcguire 10y ago
        "As they did on Windows too (see msvcrtxxx.dll, where xxx is a version number)." I didn't use Windows enough to know more about it than that let you have multiple copies of the libraries. Did it let you upgrade a compatible library? "If you want to talk problems in the mechansim, ask me sometime how it's possible for a Win32 process to host multiple incompatible malloc implementations in the same address space." I think I'll pass, thanks. :-)
- marcus_holmes 10y ago
  I still miss COM. It had its problems, sure, but it worked really well. I haven't seen anything since that allowed such decoupled development
  - flukus 10y ago
    It came back with a vengeance in windows 10.
    - marcus_holmes 10y ago
      really? I must have missed that... I stopped doing windows dev around Vista, because Vista. Any details?
      - pjmlp 10y ago
        The UWP programming model, which was introduced in Windows 8 as WinRT is COM. Basically it is the original idea of .NET, which as called COM+ Runtime, before they decided to create the CLR. WinRT is nothing more than COM+ Runtime, but with .NET metadata instead of COM type libraries. Also since Vista, the majority of new Windows native APIs are COM based, not plain C like ones.
  - mike_hearn 10y ago
    I think you have rose tinted classes on. COM is/was a rats nest of confusing and frequently duplicated APIs with insanely complicated rules that by the end really only Don Box understood. CoMarshalInterThreadInterfaceInStream was one of the simpler ones, iirc. COM attempted to abstract object language, location, thread safety, types, and then the layers on top tried to add serialisation and documented embedding too, except that the separation wasn't really clean because document embedding had come first. Even just implementing IUnknown was riddled with sharp edges and the total lack of any kind of tooling meant people frequently screwed it up: https://blogs.msdn.microsoft.com/oldnewthing/20040326-00/?p=40033 https://blogs.msdn.microsoft.com/oldnewthing/20040326-00/?p=... The modern equivalent of COM is the JVM and it works wildly better, even if you look at the messy neglected bits (like serialisation and RPC).
- dfox 10y ago
  I'm not saying that it wasn't possible, but that it wasn't exposed in Visual Studio in usable way. As for COM, it seems to me that most common reason why something developed by some ISV is separate DLL is that it's COM component.
  - asveikau 10y ago
    Firstly, I always remember VS having click through wizards for creating libraries. So I think you are even wrong on that. Moreover, what a sad world for our profession when an IDE doesn't do something for you and people start to doubt it exists. Reminds me of kids on here saying a programming language without a package manager might as well not exist at all.
  - soundwave106 10y ago
    Er... Prior to .NET, the previous "enterprise targeted" language for Windows was Visual Basic. Visual Basic absolutely supported creating COM DLLs. On 6.0 (and perhaps earlier) there's even some nice templates for "ActiveX DLLs" (ActiveX being the Microsoft buzzword for certain COM objects at the time).
pacaro 10y ago
At my first job (94-97) we were writing a (16bit) Windows application that was a relatively slim EXE and several hundred DLLs. This wasn't necessarily the mainstream approach, but it was supported just fine by the tools. What didn't really exist was a mechanism to safely use DLLs from 3rd parties, and sometimes even from MS. DLL hell was very real, but shared objects in any system will always have the same challenge. You are at the mercy of the module writer not breaking binary compatibility without bumping a version number (or part thereof)

Clubber 10y ago

Well, in all fairness, that's a 30+ year old codebase. There have been a lot of fingers in there and a lot of hard deadlines.

aidenn0 10y ago

That still sounds like a Cathedral. The whole point of a Bazaar is that there is nobody to impose big changes. Also, in the original essay the Cathedral wasn't Microsoft, it was GNU.