Code Server: a brief presentation

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 xxx 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 porno (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!

Concerns for investors in mobile telecommunications

Slowing sales growth and increased margin pressure are shaping up to be the major concern for investors in mobile telecommunications equipment makers in 2005.

Market leader Telefon AB LM Ericsson’s (ERICY) fourth quarter 2004 gross margins Thursday came in below expectations in the face of intense competition. The company said the effect was specific to the fourth quarter – an assertion some investors appeared to doubt as the shares were marked down 7.8% to close at SEK20.20.

Market research firm Gartner forecasts the market for mobile network gear, which accounts for the majority of sales, will grow 5% in 2005.

That compares with estimated 10% growth in 2004, which helped major players show good revenue growth and recovering earnings to offset massive losses and falling revenue in previous years. Ericsson’s shares were up 64% in 2004.

Ericsson projects the market growing between 2% and 5% – both Gartner and Ericsson measure in dollars – and Gartner analyst Jason Chapman said he sees industry margins coming under pressure short term as there will still be a fairly high proportion of hardware sales during at least 2005.

Hardware sales typically attract lower margins than software. Competition for new contracts is fierce and vendors are forced to accept wafer-thin margins, hoping to increase them over time.

“Later, margins should be helped by a growing share of software as upgrades to third generation equipment show up in sales,” Chapman added.

Currently many new networks are being rolled out generating sales of hardware such as base stations and other network equipment. In emerging markets such as Russia, India and Brazil it’s primarily second generation networks using Global Systems for Mobile communications technology that is driving sales. In Europe, third generation network rollouts are now taking place on a large scale.

In connection with the fourth quarter earnings releases Alcatel SA (ALA), Nokia Corp. (NOK) and Ericsson all said that margins have been or will likely be negatively affected by low prices on some new orders the companies have signed for rolling out those networks.

Analysts are worried about the implications of these signs of margins weakness.

“We remain concerned that margins, both gross and earnings before interest and taxes, will remain under pressure through 2005,” said CSFB in a comment to Ericsson’s fourth-quarter earnings.

The bank sees Ericsson’s operating margin coming down to 20% in 2005 from 22% in 2004.

CSFB added that the mobile systems market remains one of the most competitive global industries.

Number two xxx player Nokia said after its fourth-quarter earnings release on Jan. 27 that its targeted 14% operating margin in the infrastructure business will likely not be met short term, also blaming new network rollouts.

Ericsson, Nokia, Motorola Inc. (MOT), Alcatel and Lucent Technologies Inc (LU) showed a combined 14.5% sales growth from its mobile infrastructure and services businesses in 2004 measured in euros, according to calculations by Dow Jones Newswires.

Measured in dollars that growth was around 26%, implying that the major vendors gained market share at the expense of smaller ones.

Ahead, sales growth is seen being higher for services related to mobile xxx infrastructure than for the gear itself. Ericsson said it sees the services market growing 10% in 2005.

Siemens AG (SI) no longer discloses figures for the mobile networks unit and Nortel Networks Ltd (NT) has yet to disclose its full year 2004 earnings due to videos xxx accounting problems.