Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software IBM Linux

Should IBM's SOM/DSOM Be Open Sourced? 157

Posted by kdawson from the what-made-it-great dept.
Esther Schindler sends a note about two journalists for very different publications (herself one of them) urging IBM to open-source, not all of OS/2 — they've consistently refused to do that — but instead one of its most powerful features: SOM, the System Object Model. Steven J. Vaughan-Nichols writes at desktoplinux.com, "IBM, I'm told by developers who should know, still has all of SOM's source code and it all belongs to IBM. It's because IBM doesn't have all the code for OS/2 and some of it belongs to Microsoft that IBM open-sourcing OS/2 has proven to be a futile hope." And Esther Schindler takes the developer angle in a blog post at CIO.com: "Could the open-source community use a library packaging technology that enables languages to share class libraries regardless of the language an application was written in? I dare say it could, especially since the code to accomplish that goal was written (and shelved) more than ten years ago. All it takes to make that code available is to ask IBM to release SOM and DSOM as open-source." What are the business issues that would convince IBM to assent?
This discussion has been archived. No new comments can be posted.

Should IBM's SOM/DSOM Be Open Sourced? More

Should IBM's SOM/DSOM Be Open Sourced?

Comments Filter:
  • While SOM is very powerful and would of made a great addition to the Linux desktop I think it may be to late now as the common Linux desktop environments are quite entrenched. If only IBM had done this 10 years ago Linux could of had something to set itself apart.

  • Who needs the code? (Score:3, Interesting)

    by DoofusOfDeath ( 636671 ) on Sunday February 10, 2008 @12:52AM (#22366756)
    If the great innovation offered by SOM is basically a design pattern or interface technique, do we really need IBM's source code? It seems to me that the great thing about SOM is the idea of how something is done, and that we could pretty quickly write our own implementation of that idea. No?

    • Re:Who needs the code? (Score:5, Interesting)

      by RobertM1968 ( 951074 ) on Sunday February 10, 2008 @01:11AM (#22366886) Homepage Journal

      If the great innovation offered by SOM is basically a design pattern or interface technique, do we really need IBM's source code? It seems to me that the great thing about SOM is the idea of how something is done, and that we could pretty quickly write our own implementation of that idea. No?

      Sadly no - on all counts. In over a decade and a half, no one (but maybe Apple) came close. DSOM/SOM hasn't been worked on in many years, and still, with kludge after kludge, MS cant come close. (some of) The Linux community wanted the WPS open sourced just because of how powerful it was - even though I dont think they even realized that it meant also open sourcing SOM/DSOM. With many attempts at numerous windowing environments, though the Linux community has made both some pretty and some pretty useful windowing environments, they still haven't come close...

      And of course, SOM/DSOM is far more than the WPS... (just a requirement for the WPS to work).

      Also, saying SOM/DSOM is just "the idea of how something is done" is like looking at cars, bicycles, sneakers and skateboards and calling the car engine "an idea of how something moves" - it is far more than that. It is a technology that allows anyone on almost any language, to interact with and integrate with any other device, network resource, app, GUI or OS that is SOM/DSOM enabled. Almost 8? 10? years of little to no development on SOM/DSOM and there is still nothing half as powerful for any PC based operating system. Yeah, MS can keep writing inelegant, bloated (which is a massive understatement when compared to SOMObjects of better capabilities) kludges to achieve some of the functionality on a limited scale...

      SOM/DSOM is truly what most OO programmers truly want - even if they dont know it (which would simply be because they dont understand it, or love VB that much).

      • Linux doesn't need it. It has D-BUS (Score:5, Interesting)

        by Cyberax ( 705495 ) on Sunday February 10, 2008 @04:14AM (#22367800)
        Linux already has more more powerful D-BUS system (http://en.wikipedia.org/wiki/DBUS). It's already a base for PolicyKit, HAL daemons, soon it will be used in Upstart and so on.

        It's MUCH MUCH easier to use than COM or SOM. And I still remember working with OpenDoc, so I don't really share good feelings toward SOM.

        • Re: (Score:3, Informative)

          by DrXym ( 126579 )
          D-Bus is an interprocess communication layer. It doesn't do you any good if you want to embed one visual component inside another, or save a compound document etc. So while it might be great and all, it's only part of the puzzle.

          Anyway, COM isn't hard to learn - it's actually incredibly simple. It's all the OLE2 related stuff that makes a mess of programming visual components. Steer clear of automation, OLE and it's pretty easy to knock up stuff in COM.

        • Re: (Score:3, Interesting)

          by sjvn ( 11568 )
          D-BUS is great. D-BUS is wonderful. But, DBUS and SOM do entirely different things. DBUS is meant to be a universal IPC (interprocess communication) mechanism for the Linux desktop. See http://www.desktoplinux.com/news/NS4449390454.html [desktoplinux.com] for more details. SOM's a set of object libraries. You would use them together. In fact, D-BUS, since both the GNOME and KDE communities have embraced its use, would make an ideal interface for SOM. Or, in other words, DBUS would enable applications to more easily access th

          • Re: (Score:2)

            by Cyberax ( 705495 )
            What use is SOM then? You can write D-BUS services directly in your native language (most D-BUS language bindings have their own IDL and proxy compilers).

            SOM is more comparable with KParts and Bonobo. KParts have already evolved quite a bit ahead of SOM and Bonobo is slowly evolving too.

      • Not ever having used SOM I can't compare it directly but it seems to me that the basic idea is to have an object model with a hard to break ABI (i.e. you can add methods without breaking it) and interoperability with other languages.

        Apple has distilled various Objective-C bridging efforts into a common bridge library that is now used by PyObjC (which predates the Apple/NeXT merger) and RubyCocoa and is slated for use with .NET. By virtue of being able to mix Objective-C into a C or C++ file (more or less

      • there are already a lot of object models out there.

        There's various incarnations of CORBA on linux, COM on windows, XPCOM which is used for firefox components, DBUS on Gnome and now KDE.

        Component software is a Good Thing(tm), but all the various implementations essentially do the same thing, which is to allow a cross language interface to be specified in a way that doesn't require wrapper libraries to be written. Also, it is common to include some kind of remote procedure call specification.

        >>In over a

      • Re: (Score:2, Informative)

        by Simulacrus ( 1003107 )

        It is a technology that allows anyone on almost any language, to interact with and integrate with any other device, network resource, app, GUI or OS that is SOM/DSOM enabled. Almost 8? 10? years of little to no development on SOM/DSOM and there is still nothing half as powerful for any PC based operating system.

        Smalltalk / Squeak has been doing something similar for years. Anything in the system can message anything else. System components / GUI elements can be freely inspected, subclassed, modified - and a

        • Smalltalk / Squeak has been doing something similar for years. Anything in the system can message anything else. System components / GUI elements can be freely inspected, subclassed, modified - and all on the fly while the system is running. Of course, this means that all source is very literally open (other than virtual machine primitives).

          That's very interesting... can you superclass the stuff as well? And does it work with a GUI, thus making everything on the GUI an object (that can be both subclassed and superclassed)? And are objects created using it interoperable with other objects? And are you limited to using SmallTalk, or can you use any almost language with the relevant code to do all the above? Does it support full inheritance? Are the resulting DLLs as small - and as fast?

          Not picking on your statement... I have a copy of SmallT

  • Comment removed based on user account deletion

    • Re: (Score:3, Insightful)

      by FooAtWFU ( 699187 )
      I dunno. IBM isn't really in the OS market anymore, at least, not the regular mass-produced OS market - the big-machine Z/OS UNIX mainframe stuff and the like is an entirely different matter altogether (and probably wouldn't be substantially affected by such an offering anyway). Giving something like this to Linux+friends, if it helped, could boost Linux and be seriously annoying to Microsoft. And IBM likes Linux - certainly a lot more than they like Microsoft. It could happen. Maybe.

  • IBM Open-sourcing Experience (Score:3, Insightful)

    by fsckr ( 965056 ) on Sunday February 10, 2008 @01:01AM (#22366814) Homepage
    IBM has been pretty good at taking sucessful closed source technologies and open sourcing them (think eclipse, webspere community ed, jikes and all the patents they've made available to the os community). I think IBM's genius has been in fostering communities to ensure that the technologies are well supported.

    That said, SOM & DSOM are old tech from the dinosaur mainframe days. With so many distributed apps using more flexible interoperating technologies (SOAP, XMP-RPC etc) I don't really think open sourcing D/SOM will make that big of a difference to most new application developers.
    • think eclipse

      I used to work within IBM, and here is the story I got from a senior developer...

      Eclipse was a rogue project within IBM whose purpose was to take down MS Visual Studio 97. When it became obvious that there was absolutely no way that Windows developers who were used to the speed, ease of use, and rather decent integration with Windows of VS97 would shell out money for a Java-based IDE with its own oddball help system, poor integration with the Win32 toolchain, and most importantly was slow as m

      • Re: (Score:2)

        by Locutus ( 9039 )
        Eclipse was based on VisualAge for Java which was, IIRC, based on VisualObjects or something like that for Smalltalk. IBM bought that company/product and added C++ capabilities to it. There might have even been a Cobol version. So it was first Smalltalk and then C/C++ but written in Smalltalk. When Java came along, IBM added the Java modules to it. IBM was also doing killer work in the JIT/jvm area and since they effectively had 2 vm's in VisualAge , why not create a universal vm so that VisualAge used it f

        • Re: (Score:2)

          by toriver ( 11308 )
          Eclipse was based on VisualAge for Java

          There's not a smidgen of VisualAge in Eclipse; the former was a Smalltalk-based IDE family as you point out, the latter is written from scratch in Java with a custom native GUI toolkit (SWT) to mess things up.

          I have used both. If Eclipse had any of the horrid mess from VisualAge in it it would have been dead, and Borland's IDE codebase (used for JBuilder and Oracle's JDeveloper) would have won even though it was closed-source. VisualAge is an IDE from the first generat

          • Re: (Score:2)

            by Locutus ( 9039 )
            Before there was VisualAge for Java, there was VisualAge for C++. VisualAge for Java was based on the same foundation VA C++ was based on and that was a Smalltalk VM. IBM put alot of work into VAJ to merg the Smalltalk VM with Java and you might even find references to a universal virtual machine referencing this fact.

            It's been a while but Eclipse reminds me of VA of old but with a different skin and some of the things removed. Even VA C++ had method based compiling instead of full project compilation.

            Maybe
        • I'm pretty sure VAJava and Eclipse had radically different lineages, especially since I could get VAJava in 1999 but not Eclipse.

          I can't remember the name of the organization that did Eclipse anymore, but it started with O, like "Orion" or something. I remember the dev talking about how they weren't "really" IBM: they had funding and access to everyone else's code, but they didn't allowed anyone else to see theirs. They were apparently the brain child of a DE or two (Distinguished Engineers). The dev th

          • Re: (Score:2)

            by Locutus ( 9039 )
            I'm pretty sure VAJava and Eclipse had radically different lineages, especially since I could get VAJava in 1999 but not Eclipse.
            why would you then not consider Eclipse was based on VAJ lineage since it came before it?

            It sounds like maybe VAJ/VAC++/VASmalltalk might not have been too modular and the Eclipse people may have built it from the guts of the VA platform. From what I've seen, there's a common feel to it having used VAC++ and VAJ in the 90s.

            LoB
            • why would you then not consider Eclipse was based on VAJ lineage since it came before it?

              Yeah, I wasn't very clear there. I meant that if Eclipse really was the future of VAJava I would have expected to see or hear something like "the next release of VAJava will be called Eclipse" or "Eclipse is the new product from the VAJava / VAC++ line". Instead Eclipse seemed to spring suddenly out of the blue after years of semi-secret development, only shortly after the last official VAJava release, and with a pret

              • Re: (Score:2)

                by Locutus ( 9039 )
                ok, that makes more sense. As far as that goes, it might have been that announcing open sourcing of the product would harm the current sales channel so they didn't announce it. Or maybe they didn't know if it was going to be released until someone approved it. Of all the things that the anti-trust case against IBM did, one very evident result was that they would not and did not pre-announce products like they used to. Microsoft will announce stuff years before they see the light of day but with IBM, you're

        • Re: (Score:2)

          by Locutus ( 9039 )
          There's been some question as to Eclipse being derived from IBM's VisualAge products. FWIW, Wikipedia does a decent job at spelling it out but isn't too linear in its description. Object Technology International( OTI ) made a product in the early 90s which was based on Smalltalk and had a click-n-drag GUI application builder which included building apps with both GUI elements and non-visual/GUI elements. VisualAge was based on this product and IBM bought this company. After IBM built VisualAge for C++ ontop

  • Licensing and open source (Score:5, Insightful)

    by dryeo ( 100693 ) on Sunday February 10, 2008 @01:02AM (#22366822)
    One of the advantages of SOM is that it allows a closed source environment to be extended. Don't like the file dialog, subclass it with a better one. Or a recent example, need transparent png bolted on your 10 year old OS, well create a few new classes and use Cairo to display them. Suddenly you have modern transparent icons, transparent widgets on the desktop etc.
    Unluckily with GPL you can get into issues of whether closed source or just incompatible licensed libraries can be added. One of the ideas behind SOM/DSOM was that anyone could write a DLL and extend the WPS. Now it seems that in free software land you often have to worry about incompatible licenses.
    If IBM ever does open source SOM/DSOM I hope it is with something liberal like the LGPL. Don't have to think about issues with linking and the important source stays open.

    • Re: (Score:3, Informative)

      by IamTheRealMike ( 537420 )
      I would note that you can do all those things on Windows with COM. In fact that's how transparent PNG support was added to Internet Explorer, and is why you have to invoke them in such a funny way (MS could have done a better job of the IE/COM integration in the images department).

      • Re: (Score:2)

        by XO ( 250276 )
        Not exactly - how is it that you could, in Windows, change -all- applications that use the standard File->Open box, to use a new one tha you've written?

        I don't know a lot about windows coding, but I'd expect that if it were possible, there'd be a lot of replacement File->Open boxes out there.

        IE 6 supported PNGs, but not transparent PNGs, and DirectX supported display of transparency, so you had to make up some horrendous CSS hack to get windows to pipe the PNG through DirectX before displaying on scre

  • Its already there (Score:3, Funny)

    by blackpaw ( 240313 ) on Sunday February 10, 2008 @01:09AM (#22366870)
    Could the open-source community use a library packaging technology that enables languages to share class libraries regardless of the language an application was written in?

    Its called .NET or Mono

    • Re: (Score:2, Insightful)

      by sigzero ( 914876 )
      You have no clue. They are not in the same class at all.
      • Actually, .NET is far closer to SOM than COM is. One of the advantages of SOM was that it was, in essence, a runtime object system, so you could "inject" new methods into objects if you wanted (kind of like how smalltalk works). .NET allows just that sort of thing as well (though it's not widely known) through a process called Reflection for runtime discovory of objects, and you're allowed to modify objects on the fly.

        No, SOM and .NET aren't exactly the same (and .NET is a lot more than that, including san
      • So what? Just superclass them with the same class!

    • Re: (Score:3, Informative)

      by sl0ppy ( 454532 )
      .net and mono are functionally equivalent to a SWIG [swig.org] wrapper - a bit easier to deal with, but similar nonetheless.

      this is a bit different. for one, it allows you to redefine how an API is implemented. imagine a generic database API. instead of programming to a client library, all software can be written to a single standard API that then has its guts replaced with a simple call to be database specific. need to move from mysql to postgres and have 30-40 different maintenance programs and scripts that are

      • Re: (Score:2)

        by cnettel ( 836611 )
        And nothing stops you from implementing that in COM (where the "interface" aspect is very much a part of the concept) or .NET. In fact, that's the way ADO data access worked in Windows, to continue your example. That doesn't magically solve the issue of incompatible DB syntax. I think there were some plans on implementing a version of Gecko that exposed the MSHTML interfaces, but I don't think they ever got close to actually finishing it.

  • It's the best outcome (Score:4, Interesting)

    by jsse ( 254124 ) on Sunday February 10, 2008 @01:37AM (#22367042) Homepage Journal
    The good things about OS/2 I described before [slashdot.org] is blessed by the wonderful SOM. I really can't tell you all the good things about SOM here, but during the time I wrote apps at IBM in C Set, SOM really save us a lot of time and efforts.

  • Open Source should be the default "archive" choice (Score:4, Insightful)

    by TakeyMcTaker ( 963277 ) on Sunday February 10, 2008 @01:47AM (#22367098)
    Ignore IBM and OS/2 and everything, just for a second, and review this hypothetical situation on its own:

    A Big Computer Giant (BCG) purports to be very Open Source friendly. They defend OSS products and licenses, even using their own lawyers, and make a lot of money using/supporting OSS, in their own hardware, and in huge consulting contracts. It turns out they have this collection of source code that they aren't really using anymore, and they have complete rights to at least part of it. Let's just say they only have 2 real options when archiving the source code they own the rights to:

    1. Keep it locked in some internal media or shelf, never to see the light of day, unless an internal developer finds it interesting and digs it up for an internal-only project. The internal project may never see the light of day either.

    2. Put it on the Internet, and Open Source License it, preferably with an existing OSI license. Not only could the online repository be considered the source "archive", but it also leaves the possibility of growing a redundant, living archive. The source could then be provided by various OSS repositories and mirror hosts.

    I know I'm preaching to the choir here, but shouldn't #2 always be the default, or at least the first option considered? Even if you're not an OSS nut (like me), you have to admit the hypothetical company looks pretty darn hypocritical if they don't choose #2, when given the choice, early and often.

    So am I using a hypothetical situation to say that IBM (BCG) is a big hypocrite if they DON'T release and apply an OSI License to SOM/DSOM source, ASAP? Why yes I am! How could you tell?...

    • Re:Open Source should be the default "archive" cho (Score:3, Insightful)

      by Anonymous Coward
      It's not hypocritical because they didn't tell other people that they must open source everything. Also, you are somewhat familiar with the logistics involved by projects, archives, etc. You might consider that open sourcing is far from a 'default' choice, there are plenty of considerations:

      1. it takes time to look over something to make it ready to see the light of day. You have a reputation to uphold.
      2. you might want to make money off the software, now or in the future. as much as i love and support an
    • Because in real world companies exist to make money, not please OSS crowd.
    • Releasing internal code as open-source has many costs associated with it, from software packaging issues to legal ones. Unless it's clearly a case where that code has some value to a larger community, paying those "free the code" costs may have no payback for the company. It's completely reasonable to say that the default position is "do nothing", which also costs nothing, and only consider the costs of releasing as open-source when there's a demonstrated need or desire to use the code outside of the comp
    • Remember when Netscape put Communicator source on the internet, and everyone just whined how it didn't compile and how useless it was?

      And that's when Netscape was the most popular browser, not some 12 year old abandonware desktop middleware that nobody used in the first place.

      I don't think anyone active in the OSS desktop community wants a bunch of old unpopular OS2 crap. If anything, they have too many duplicate component models and they need to start standardizing, not add a new one.
    • They would have to check the code. Maybe the responsible developers have left the company, or maybe they are on an active project. It would take time to assemble the original team (or what is left of it) and ask them: Do we have the exclusive rights to this code? And if they were unsure they would loose even more time trying to find out. Time is money. If those people get decent wages it could be a lot of money. If they were working on important projects IBM was to earn a lot of money for they would loose t
    • How could they be a hypocrite for not releasing that code if they ARE helping the open source movement with their lawyers and stuff?  They're only a  hypocrite if they take and take and never give anything back, which they do.  They don't have to give up EVERYTHING they could just to not be hypocritical.

  • Of Course! (Score:4, Funny)

    by Tragek ( 772040 ) on Sunday February 10, 2008 @02:14AM (#22367246) Journal
    All should be open source. Source should never be hidden. It violates all ethos, it violates all truth, it violates my first GPL right to see the code!

    • Re: (Score:2, Funny)

      by Anonymous Coward
      What colour is the sky in your world?

      • Re: (Score:2, Insightful)

        by Idiot with a gun ( 1081749 )

        What colour is the sky in your world?
        Why, I can easily recompile the sky to be whatever color I want it to be, now that you mention it.

        • Why, I can easily recompile the sky to be whatever color I want it to be, now that you mention it.

          Not unless you're using Firmament Beta 12. The latest stable release only supports Skies with 4 bits per pixel.

          • Re: (Score:2)

            by Arimus ( 198136 )
            Ah, but he's got the source so he can modify to run 16 bits per pixel - just needs one hell of a CPU and graphics card, and if you do a poor job your sky ends up panicking.

      • Re: (Score:2)

        by Locutus ( 9039 )

        What colour is the sky in your world?
        if your sky were a SOM object, I'd subclass your sky, add a sun and some puffy clouds.

        LoB

    • Re: (Score:2)

      by CAIMLAS ( 41445 )
      Dude, you remind me of a Dr. Bronner's Magic Soap label:

      Absolute cleanliness is Godliness! Balanced food for mind-body-soul-spirit is our medicine! Full-truth our God, half-truth our enemy, hard work our salvation, unity our goal, free speech our weapon!

  • Business issues for open-sourcing SOM/DSOM (Score:4, Funny)

    by Duke ( 23059 ) on Sunday February 10, 2008 @02:50AM (#22367414)

    What are the business issues that would convince IBM to assent?
    I can think of three:
    1. That it would hurt Microsoft
    2. That it would hurt Microsoft
    3. That it would hurt Microsoft
  • I would ask the question of what SOM/DSOM would bring to the party, when much of that technology went into making CORBA [wikipedia.org]. CORBA is here now, has multiple implementations, both commercial and open (source and beer).

    The only thing I can point to is GUI components, but those were either tied to a specific implementation (OS/2) or to an additional frameword (OpenDoc) and I am not sure they would be of much value.

  • SOM = CORBA 1.0 (Score:3, Interesting)

    by micromuncher ( 171881 ) on Sunday February 10, 2008 @03:54AM (#22367712) Homepage
    SOM implements a subset of the CORBA specification. Other technologies implement CORBA. Some already are open source (MICO). So... consider porting to another ORB.

    And for the person who mentioned Apple... Apple implemented a subset of SOM specifically for OpenDoc. Though highly cool at the time, it was too castrated to be useful and has been surpased by other technologies for robustness (like J2SE/J2EE). Don't forget cool stuff like Spring... Lots has changed in 10 years.
  • Will that source code really be useful? A component like this may be completely useless in any other environment or maybe it can be seen as a curiosity and nothing more.

    Some of the ideas may survive in new solutions, but it can be a really bad idea to take this out of concept and trying to graft it upon a different platform. The amount of work involved for that operation may exceed the amount of work to re-create the functionality without source.

  • SOM, COM, CORBA are all much of a muchness. They let you define APIs to objects and interfaces in language neutral IDL, generate stubs that you implement and let you call those objects from other libraries, processes or even machines.

    If Linux really wants language neutral interface bindings, it already has it. There are numerous CORBA implementations, idl compilers and so on. For example GNOME offers ORBit (a Corba implementation) for embedding UI components via Bonobo. Bonbo appears deprecated and is bei

  • As other pointed out: there are enough CORBA implementations out there. The only advantage of SOM was that ist offered igh performance in an non distributed environment while beeing compatible with it's distributed peer DSOM. But even that is not so cool any more.

    What was realy cool was the only real application build with the SOM: The Workplace Shell. Neither KDE nor GNOME can to what the WPS could do.

  • Frankly, I don't care how it is achieved, but I am really getting tired of having different UIs to perform the simplest of tasks, particularly when newer applications seem to be defaulting to the GTK2 file dialog more often than not. That dialog is irritating enough on its own, but not having it be identical, from one application to another, really starts to get under one's skin.

    If SOM is the best method to do this, then bring it on. It seems to me that, in 2008, there could at least be something which deve

  • You Don't Want It (Score:5, Informative)

    by scherrey ( 13000 ) on Sunday February 10, 2008 @10:03AM (#22369242) Homepage
    I did two contracts with IBM in the early 90's, one on the OS/2 2.1 change team. In both I "got" to deal with SOM and its implementation source code. It's a giant nasty C macro & function pointer hack. OS/2's Workplace Shell was very cool but the underlying implementation was pretty nasty stuff. One of my fixes was dealing with how slow it was populating icons in folders. SOM is a good example of the "Prototry" anti-pattern where one does an initial implementation of a cool trick then ends up shipping & extending it rather than ever bothering to architect it right in the first place. I can understand why IBM doesn't want this source out in public. FWIW - I also had to deal with some of the Microsoft source code, especially device driver stuff. Was the worse C code I've ever seen in production...

    If you like SOM & Workplace Shell features you'll find it far easier to implement on top of Qt/KDE or wxWidgets or a smart functional integration of some Boost library features & a GUI than you'd ever have hopes of getting that code to work with anything modern or useful today. I loved OS/2. Borland had a Beautiful C++ compiler for it and CSet/2 was one of the better standards compliant compilers at the time as well. They're all bit rot by now though. Appreciate the memories but let this one die.
    • That was definitely true of SOM in the 2.1 days. SOM 2 took it from a cool, technically interesting hack to real code.

      • Re: (Score:2)

        by scherrey ( 13000 )
        I find this difficult to imagine as IBM was definitely not interested in investing in re-engineering any of the source code. A friend of mine and I put together a proposal to re-write Presentation Manager in 32bit in a few short months and it was simply not considered. A re-work of SOM would have required a rework of WPS and I'm fairly certain I would have heard about that effort. Once they moved from Boca to Austin that was it for real OS/2 dev that I'm aware of.
        • I covered OS/2 actively for several years past that point. I knew several of the developers, and was one of the lead perpetrators of the OS/2 WarpTech conference in 2000. So yeah, I have some idea of how much work continued to go into development. And how little went into marketing. ::sigh::

          • Re: (Score:2)

            by scherrey ( 13000 )
            These (and yourself) must have been some dedicated guys & gals. :) Well - would be cool for you all to make a BSD licensed version of the same concepts and maybe use a language that better naturally enforces these ideas. Might get me all nostalgic again!
  • Yeah, why does it matter anymore which language some binary was written in, in order to link it to another binary library? Everything uses a stack of pointers or values to pass arguments, and a symbol table to resolve references to instructions and data external to the binary package stating the reference. That seems to offer a language-neutral resolution of those references across binary packages, regardless of which language was used to generate them.

    Sure, there could be some differences, like argument or

  • petition (Score:2, Informative)

    by elkosmas ( 976961 )
    Online petition http://www.petitiononline.com/sombsom/ [petitiononline.com]

Slashdot Top Deals

On the eighth day, God created FORTRAN.

Close