Q1. What is a Code Server?
A1. The term “Code Server” refers to the analogue of a “File Server” for program code.
A File Server arrangement allows you to open a file without the OS knowing the intricacies of how and where the file is stored. A Code Server arrangement allows you to open a program without the OS knowing where the pieces of the program are, and with only the immediately necessary modules at the client.
Until Code Servers were invented, operating systems had to refer to programs as files. Programs had to be directly visible as a file that the computer’s storage system could access. With a Code Server arrangement, the access intrinsics can be reduced to a series of protocol calls which avoid the issues of code management such as installation, versioning, and sharing. This “client-serverization” of the relationship between an OS and its program files (modules) is at the heart of the Code Server.
Q2. How does a Code Server work?
A2. The operating system, instead of making requests on files queries a Code Server.
The Code Server:
a. knows what kind of client and will send different versions depending on the client’s processor, Operating System etc
b. knows the client’s preferences and will search for particular versions before sending (eg test version, upgrade, encrypted version) the version that the client requires. Software subscriptions can be handled this way, for example.
c. can tell the client when it thinks that the client already HAS the code in question, thereby saving transmission bandwidth.
The Client:
d. can make up rules telling the server HOW to search
e. as long as it checks with the server on each request, is guaranteed the desired version even if an update has taken place since the last transmission.
The core of the technology is related to something called Dynamic Linking, which enables computer programs to be broken up into small pieces (modules) which exist and are maintained independently. What a Code Server does is to enable the distribution of these pieces while keeping control of the relationships between them, by storing information about those relationships. Our term for this is “association”.
Q3. There must be some client software on the client machine that is able to communicate with Code Servers and do the dynamic linking. Should this be a part of the operating system or a program you can download conventionally?
A3. To work nicely, the client will have a Mini Code Server (Mini-CS) that speaks the same protocol but is somewhat intimate with the dynamic linking mechanism of the operating system. To be clean, every LOAD by the OS needs to be routed through the Code Server. We did this with Windows to prove the concept – and it works.
Q4. Is machine code suitable for dynamic linking or do you need pcode or Java bytecodes or something similar?
A4. Yes. They had dynamic linking with machine code in the earliest versions of Windows and OS/2, and it remains the basis of most operating systems (DOS is the exception). We do NOT claim to be inventing dynamic linking, or pcode. However, dynamic linking of pcode was not done under Microsoft operating systems until our first Code Server!
Q5. So is the Code Server mechanism applicable to all kinds of processors?
A5. Yes. The Code Server idea is suited to any system that uses dynamic linking. A broader reading of the patent would suggest it is applicable to any operating system that makes requests for modules of a program.
Q6. Doesn’t dynamic linking require a different kind of compiler output (obj)?
A6. No one distributes OBJ right now. But all executables are dynamically linked. This includes EXE’s and DLL’s, as well as VxD’s. I am less sure about Unix (Linux) since dynamic linking is relatively new there (see the docs on SPRING). Current compiler/linker output is designed to resolve API and inter-module calls to some set of slots which are ready to call the outside world. Then DYNAMIC linking resolves these, usually one module at a time.
Q7. What do most users do currently to install programs?
A7. A typically large file is copied or downloaded to the computer and installed. This frequently involves copying support libraries to some known location, such as the WINDOWS directory. This is advantageous because once the copy is done, access is fast. The disadvantage is that to update the software, the download generally has to be repeated, and there is no simple mechanism to detect or control which parts truly need replacing, or where they belong on the target machine.
Q8. Why is it disadvantageous to execute remote files?
A8.
a. Slow – connecting to a file system requires lots of overhead both at connect and file-access time.
b. Insecure – you need to take all sorts of steps to protect the remote file system from abuse.
Q9. Won’t installing software over the network be extremely slow (especially for large applications)?
A9. Most internet connections are intolerably slow, and it might take too long to install an entire program over the network. This would not be a problem with a fast enough connection (e.g. ISDN or DSL), and seeing as there is a big push on the part of ISP’s for faster connections, the issue of network speed might well become secondary. However, Code Servers also help with the issue of speed – See here for an in depth discussion.
Q10. I assume that if you start an application distributed by a Code Server it begins execution immediately after the main module has been loaded while the loading continues in background. The modules are loaded in the sequence they are required for program execution.
A10. Correct. As long as all the pieces can be found. That is, in principle if not in practice, how applications work right now. It is only necessary to fault into memory the actual modules being executed – just as long as the tables and suchlike for the faulting in of the rest are completed during association, i.e. before we start.
Q11. I imagine a Code Server could be running either on one or more server-machines in a lan or on many internet servers. This could be combined in a proxy-like manner (I am not sure if I know what proxy really means today). On the internet, an application could could be located on several Code Servers – for example the main module on the vendors’ Code Server but the 3d graphics module on the server of the 3d guru.
A11. Right. But the intent is that all the pieces an application eventually end up on the client machine. Also, it is unlikely that the client would need to go farther than his local ISP for the required modules. The issue of distributed processing is entirely different.
Q12. What about data that comes with software, e.g. configuration files, scenarios? Can they be handled with the Code Server too, or do you need to download them conventionally? I am not referring to data that is produced by the user of the application, e.g. the text that is typed in a text processor.
A12. Yes, they could. The patent can probably be interpreted to mean any “recipe” with reference to other recipes as covering this. Of course most such data files lack the complicating property of reference to yet other such code files in a recursive kind of manner, so they are just the simple case of a referenced object. And the infrastructure we propose will handle these files as part of the packages – it will be as if there is a “code” envelope for configurational data. If you know how icons are embedded in Windows executables, you may be able to see a close parallel.
Q13. What is the preferable size for modules that are distributed by a Code Server?
A13. It doesn’t matter – but the better broken up they are, the more seamlessly they can be distributed. Against that, the more modules there are, the more entries in the module interrelationship diagram there are (more searching, more association time), but we say that the time to associate is small compared to the time to download as long as the network is slow (and it always will be). Also, Code Servers can store the results (i.e. names, locations, and reference lists) in a database. Use of large modules is a stupid optimization which works when you have a fast disk. The original system we built this for had a slow network (1 MBps) and (potentially) NO hard disk. EVery so often someone points out that things load faster with larger modules (see for example this technical note from Microsoft), but with the Code Server approach we are pushing for smaller ones.
Q14. When an application is completely in the client’s permanent storage cache and therefore can be executed offline, how can the client be notified about a new version available?
A14. The responsibility of the Code Server, starting with the Mini-CS on the client, is to check with its immediate superior if there is a change in status of the code file in question. It will make the same request to the Code Server it made before. If the answer it gets is different (eg checksum has changed) then it knows to download the new version. And the Code Server will check with its immediate superior in the same way. Of course when a change is made at the source level (way out there at the Guru’s computer to use our earlier example), there are two ways such a change can be forced all the way to the user
a. The Code Server periodically polls its superior for all “known” modules every so many hours/days/invocations.
b. The Guru (software maintainer) can send down a flag to the Code Server network to specifically force the clearing of the “ok” flag for that module. Of course even then the download doesn’t actually take place until there is a request for the object.
All this is technology that the “push” network folks (Marimba, Pointcast and others) must have already worked out.
And of course if there’s no network turned on then no checking is possible. That brings up the point that this technique could be used to install applications off CD’s. No more installation programs, hoorah!
Q15. Code Servers encourage you to easily try out programs offered in the web. How can you ensure or even make it more probable that the programs do no harm to your computer and the data stored on it?
A15. Easily – the Code server is a perfect way to license, meter or encrypt software. Thus it easily allows a Software Provider (or its agents such as ISP’s) to make rules about who gets what and in what version. This would allow the point-of-sale to be the ISP rather than Microsoft, for example. Wouldn’t that be a nice improvement for everyone? (postscript 14.7.99 the latest jargon for this is “software rental”, see for example this reference)
Q16. Will there be one Code Server standard (at least for PCs), or will there be several Code Server products incompatible with each other? Are you going to enforce standardization using the power obtained from the patent?
A16. The standard will be when the operating system is modified by Microsoft or Torvalds or whoever. It will represent a level of binary compatibility (the protocol) without which things won’t work. Vendors are right now doing a bunch of ad hoc things to distribute (Netscape smart update, Marimba, Ncompass, Microsoft) but they are all tacked on the outside of the O/S just as our original thing was. Once the OS itself does it, the whole OS can be distributed by Code Servers and there wont be an issue.
A pure application product for distributing software by this means will not succeed commercially, I predict. You might be able to sell an application which included it and depended on it for distribution (the killer app for the code server platform). The incremental improvements (eg NT5) in existing technology will encourage people to buy the Microsoft product or some other standard such as Linux. That in turn leaves our only option for making money as legal — unless we can get a competing OS vendor or an application vendor with some clout to embrace the Code Server idea.
Q17. How did you come up with the name Microtopia?
A17. Despite the rather obvious connection to Utopia, the name is more subtle in that the greek letter m (mu), which stands for the prefix micro, looks (and sounds!) a lot like a ‘u’ in the Arabic alphabet. We wanted a name that suggests how ideal is the world of Code Servers. The definitions on the index page mimic the Oxford English Dictionary definitions of Utopia; we put the second one up there because this idea really does sound too good to be true, but we have yet to find a fundamental flaw. Seriously though, this idea could make the computer world a lot more Utopian, and might even make order out of the chaos of the internet!