Position on OS engineering without source code This is outline of a position on source code issues which I circulated to members of the panel beforehand and lightly edited afterwards. Obviously these are entirely my own opinions and not neccessarily endorsed by my company. (1) We (VenturCom) have a long history of doing incremental OS and system engineering relying on examination and modification of the source code for several successive generations of PC UNIX (real-time, embedded) based products. We have in the last two years undertaken the same exercise with WinNT and with virtually no source code. We developed a realtime subsystem for NT which: Fields device and timer interrupts and schedules threads in (really) deterministic time; Communicates with NT for RPC service, sharing memory and implementing sychronizers between NT and RTSS threads; Exposes a Win32 subset API such that code can be written that can be build for either the realtime RTSS environment or the normal WinNT environment. See our paper on the RTX Realtime Subsystem for Windows NT in the proceeding of this worksop for more details. We managed this with the limited source code provided in the NT HAL (hardware adaptation layer), we were able to do what turned out to be a very satisfactory implementation in very satisfactory time -- which certainly speaks to the quality of the original design. The functional partitioning is very good and the funtional content of the HAL cover (sort to speak) what needs to be modified in order to host a subsystem in NT (a little source code goes a long way). (2) The downside of extensively hacking someone else's kernel is that as soon as you're done, they send you another version and you have to start all over again. However that may be, fitting into the existing framework makes maintenance and incremental development going forward dramatically easier. For this reason and just general software truth and beauty not modifying the base system is a desireable goal in most instances. (3) All of that notwithstanding, the source code used to be the documentation of first reference and last resort. Everything else failing, it was very relaxing to be able to scan the source code for details not reflected in published design and reference materials. That sort of relaxation is not possible these days for many people. It's not possible for the vender to anticipate all applications to which their software will be made -- our case is a great example: a desktop/server OS wegged into ROMS and bolted into factory control systems. The source would facilitate legitimate use and extension in unanticipated applications. The more successful a product is, the more likely it is that the original requirements and documentation will be stretched. Accomodation from the vender is clearly going to increase the success of the porduct. The other major engineering project we've done with WinNT in the last two years is a kind of componentization of the whole distribution into incrementally includable bits that start with an 8 mb core and build up to a full system. We provide the component definitions in a development system (CI 3.4) that allows you to engineer a complete system/application configuration save it away and subsequently retrieve it and load into a rom or flash disk or whatever for your embedded target hardware. Understanding the dependencies between NT services, utilities, applications, OS support, etc. was a nightmarishly difficult forensic software analysis problem that would have been greatly facilitated by periodic peeks at the code base -- which I offer as a case in point for the above. (4) Finally, I often wonder what venders intend by holding the source code as closely as they do. I understand wanting to maintain the purity of the teachings sort-to-speak but... I perhaps naively think that since these OSs are private property, that their source code could be distributed without rights to produce binaries and we might have the best of both worlds. Perhaps in the case of NT, there are other darker reasons. I made a list of possible reason's that Microsoft might not want NT source to see the light of day: People (like Margo) clearly would make fun of how it was designed and implemented; The comments are really really bad; The modules are riddled with DEC copyright notices? Just kidding. (5) Bottom line, staying away from the OS vender source code seems to me like a very good idea even for the implementation of major OS theme variations (eg. realtime thread scheduling interrupt dispatching, memory management and et cetera hacks). That notwithstanding, the vender source code may often be the ideal documentation and reference for development. Line under the bottom line, if it were easy, everyone would want to do it. No way was want of the source code going to stop us from developing our couple of products. -- Nick Vasilatos Director of Engineering VenturCom Incorporated boxer@vci.com 215 First St. (617) 661-1230x250 Cambridge, MA 02142 https://www.vci.com