I have rigid deadlines that have to be met, so it does look like Q4 2000-Q1 2001 will be the release date - hope I don't burst my boiler doing so:)
The first target (fully functional kernel capable of providing base win32 kernel services) has been reached without blowing out by more than 3 months. The next target is a GUI which could effectively run a thin client or bare bones windows apps - this is about 30% done and I hope to achieve this by the end of the year. The graphics framework is running, and all I need to do is build the widgits and glue code to interface to applications and we're pretty much there.
Troll alert... Bzzt. Wrong. Trumpet Winsock was written completely from scratch to have a clean copyright from the very beginning, and I can tell you it was no easy task to code TCP directly from the RFC's despite the occasional peek at existing code. Another reason I didn't borrow any code was simply because there was none - my first application was in Pascal (Trumpet Newsreader), and at the time no Pascal tcp stack was publicly available anywhere. It was only with the support of my wife who believed in what I was capable of that I even embarked on writing a TCP stack from scratch, and the rest is now history - all those computer widows take note.
This was done at a time when just most of the commercial stacks were derived from the BSD Net2 code. And I even remember at the time that I got involved in the Internet that there was a rumor that MS felt that the Internet would not amount to much. They changed their tune within a couple of years though:)
Finally, my beef is not with MS. We were fully aware of the risks and the direction that MS were going when the company formed. I keep a respectable distance from them, and presumably they respect us also. My beef is with the myriads of unscrupulous companies who thought it was fair game to simply use and distribute our product without any hint of royalties being paid by themselves or the end users. I think that in itself speaks about the quality of our product and why it may have been an important step in bringing the internet to many desktops even though the lost revenue to ourselves runs up into the millions.
I have first hand experience of widespread exploitation of software, and that's more about what I am referring to mainly. With this issue I am seeing some worrying influences of corporatism taking seed and it would be good to understand the full implications of what has happened. To me it's a classic question of who's really in control.
In my opinion, Open source is going to show more and more of these problems because of the conflict of interest between open development and maintaining commercial advantage to remain competitive.
The fundamental issue is that if you are going market an operating system, you need to have a well defined and controlled environment for building the OS, especially the compilers and linkers. In fact, the very first part of the PetrOS project was to create a compiler capable of building the kernel from, which has proved fruitful because the kernel is extremely stable - I know exactly what machine codes are executing at any point in the kernel. When you are left to a 3rd party compiler, you are at the mercy of the compiler developers interpretation of how the language should be implemented, and even suffer the bugs they may have left in the distribution. I am only too familiar with that aspect.
The other issue that open source developers face is the frequent version releases, some perhaps not fit for public consumption. Clearly in this case, the gcc people should have made their version numbering scheme represent the beta nature of the product. Heck, even we do that with Trumpet Winsock. Before we go to major version release, we tag the version number with a beta sub version number to clearly indicate that the product won't be supported and that it should not be used for any production implementations or distributions.
It is for precisely these reasons that I have opted not to endorse an open source model for the PetrOS project, but rather some form of synthesis whereby key parts of the distribution are kept closed source, but allowing some of the outer edges of the project to be open source. I believe this is the only way for complicated projects like an operating system.
The other comments I hear (hearsay???) about Red Hat being closed shop about their plans hints of corporatism.
A word of advice to all those penguins out there. Beware the corporate world - it's ruthless and they'll take every advantage of the open source movement, even to it's detriment!!! I'm certainly not saying that Red Hat are doing this, but sooner or later, some company who wants to cash in on the Open Source movement will come in and plunder all the good work that's been done. Perhaps this incident is a small warning of what *could* happen. It's happened before in other parts of society - eventually "feel good" movements get exploited in one way or another either politically or economically.
I could say more, but it really deserves a much better appraisal than an off the cuff comment on a forum.
Don't get me wrong, I am in no way denigrating Open Source - I'm just saying that trying to operate it on a commercial basis is full of problems.
Just to set the record straight about what is reality from someone who has written an IPv6 stack. (Trumpet Winsock 5.0)
Firstly, IPv6 can actually aid your privacy in that it is now technically possible for you to *choose* your IP address provided you reset the globally unique bit, and use the duplicate address detection mechanism to make sure your traffic will work. The only time duplicates become a problem is when the same address exists in the scope of the network where it matters. i.e. your subnet for an ethernet connection, or the PPP link when you are using dialup.
It would be technically possibly for you to dynamically change the lower 64 bits of your IPv6 address during the life of your connection to the internet be that ethernet or PPP. There is one proviso in that it is not currently feasible to modify your address for active TCP/UDP connections, so you would need to close all active connections to lose all trace of your older address.
Given the active discussion that this topic has generated, I am now keen to add a feature to our stack which would build a random EIU64 address each time the interface is opened. This feature is already in place for PPP connections, and I could also add a button which would force a new address to be built on all interfaces. Of course to pick up the new address, all connections would need to be broken, but it would be a simple matter for the stack to continue using both addresses until the original address is fully deprecated. IPv6 is powerful enough to use as many addresses as you like from your internet node. That is the beauty of stateless autoconfiguration and neighbor discovery.
I suggest that slashdotters go and read the relevant RFCs *and* Internet Drafts in some detail, and they will realize how powerful IPv6 is and how it will solve many of the issues facing the immediate future of the Internet.
The claim has not been made. I have a small subset of Win32 available to interface things. It uses COFF executable format, and there is not resemblance to NT driver structure whatsoever.
The rest has really been the result of the press. All I have said is that it could be likened unto an NT lite. It is a 32 bit OS that does away with the DOS layer, but has the potential to have similar characteristics to NT.
The only similarities to NT are...
1) the kernel and drivers are COFF executables. 2) there is a Win32 layer using DLLs.
Apart from that, there's nothing that can indicate that it is a rip off of NT. Indeed I adopt a completely different driver architecture to NT or Windows 3.x, Windows 4.x. (Windows 9x)
This is a downside in that NT drivers won't work as some people were curiously postulating.
As the OS has been designed from first principles, there are a multitude of API's that it could run, and this is its true potential.
One possible API that has been given serious thought to within the company is to have a native Java API built into it as close to the kernel as possible. The Win32 layer could then interface or coexist with this Java layer.
There are however some concerns about Java as a framework. The first one is that the Java architecture cannot fully represent the complete set of solutions to a given programming problem, and the second is that considerable resources need to be expended to get equivalent Java code executing at roughly the same speed as native C++ or Pascal code. Another concern I have is that I believe the garbage collection (GC) model used by Java will interact badly with the virtual paging mechanism. There are flaws in the GC model of Java that make it a challenge to write a truly well defined Java Virtual Machine (JVM). This may however be only be a feature of some of the earlier implementations of Java virtual machines.
Regardless, I have done some preliminary work on a just-in-time JVM for PetrOS. I am aware of the work of the ElectricalFire project, and this may be a short term solution to getting a working GUI operational if we can provide just enough framework for a Java GUI to operate.
But certainly, I want to reiterate that we are not wanting to supplant NT or whatever, but rather our strategy is to coexist in the marketplace with all other operating systems, and neither are we making claims that we are or will be NT compatible.
Finally, I have had time to reply to this topic after the interest that it's cooked up.
The most common feedback is that I should use OSS techniques to distribute the product. I however am yet to be convinced that this would be commercially practical to our company, since for the project to be successful, it will need to fund itself. OSS would work against us in that regard in my opinion.
From the point of view of making OSS provide resources for us, I have reviewed over the past year several of the OSS projects related to Win32. WINE has certainly caught my eye, but my concern is that the development has maybe progressed too far for me to make effective use of it in our project. If we can marry the two successfully and deal with any contentious commercial issues, it might be a goer. Of primary importance is however size. The primary goal of PetrOS is to keep the size of a working system to the minimum possible, as evidenced by our small kernel size.
Some technicalities of PetrOS.
The size is indeed *around* 100K. The last time I looked last week, the kernel was at around 120K. Although this is certainly likely to grow, I'm currently using my own pascal compiler which produces manageable code, not optimal code. If & when I am able to get the kernel to compile with the Delphi command line compiler, I am likely to reduce the size down to almost 50% of its current size.
The kernel at the moment has built in support for FAT16, FAT32 IDE drives (no floppy support yet), standard AT keyboard, CGA monitor, COM1-4 ports, virtual paged memory, COFF executables and sockets. It's been built using object oriented Pascal throughout which has added significantly to its stability. It also supprots a loadable driver model so that the kernel itself should not require significant redevelopment over time. The sockets api is extendible allowing us to have the tcp/ip and network drivers as individual kernel modules loaded as necessary. In all this, I have no intention to become another Unix clone - indeed the Unix model possibly works against trying to create a framework that has the potential to provide any kind of alternative to a particular well known OS. Just to clear up any misconceptions, my work to date in no way emulates any of the NT kernel at all since I have no desire to be seen as an NT clone either. My only desire is to create a small & stable kernel that can run equally comfortably on legacy 486 machines to the latest & greatest Intel machines. As it is also written in high level language, porting to other platforms while not trivial should be relatively painless.
Also important in my design is to get the hardware as close as possible to the application layer without losing system integrity. I believe this is possible with prudent design, but does remain to be realized. Don't forget that one is using the same CPU cycles in kernel mode as you are using in User mode. The real bottleneck in OS design is user kernel transitions so if a lot of the grunt work can be done at the application layer, one *may* be able to write a fairly fast and robust GUI at that level.
As far as my background goes, I have some qualification to do what I am doing. I have been writing compilers since the late 70's and have spent at least 10 years of my working life writing and maintaining a variety of real time operating systems over diverse platforms. This all before I actually got involved in the internet and writing Trumpet Winsock for which you all know me.
Well, that's enough for now. I could talk heaps more about it, but the more CPU cycles I burn here, the less I have to work on the OS.
I just hope that you all can catch the vision of what the PetrOS project is all about, that I'm not trying to tear down Linux or FreeBSD or Windows NT or whatever. It's just that there's a need for something a little different to the mainstream out there, and PetrOS may have a chance of fulfilling that something.
Slashdot Mirror
I have rigid deadlines that have to be met, so it does look like Q4 2000-Q1 2001 will be the release date - hope I don't burst my boiler doing so :)
The first target (fully functional kernel capable of providing base win32 kernel services) has been reached without blowing out by more than 3 months. The next target is a GUI which could effectively run a thin client or bare bones windows apps - this is about 30% done and I hope to achieve this by the end of the year. The graphics framework is running, and all I need to do is build the widgits and glue code to interface to applications and we're pretty much there.
Troll alert... Bzzt. Wrong. Trumpet Winsock was written completely from scratch to have a clean copyright from the very beginning, and I can tell you it was no easy task to code TCP directly from the RFC's despite the occasional peek at existing code. Another reason I didn't borrow any code was simply because there was none - my first application was in Pascal (Trumpet Newsreader), and at the time no Pascal tcp stack was publicly available anywhere. It was only with the support of my wife who believed in what I was capable of that I even embarked on writing a TCP stack from scratch, and the rest is now history - all those computer widows take note.
:)
This was done at a time when just most of the commercial stacks were derived from the BSD Net2 code. And I even remember at the time that I got involved in the Internet that there was a rumor that MS felt that the Internet would not amount to much. They changed their tune within a couple of years though
Finally, my beef is not with MS. We were fully aware of the risks and the direction that MS were going when the company formed. I keep a respectable distance from them, and presumably they respect us also. My beef is with the myriads of unscrupulous companies who thought it was fair game to simply use and distribute our product without any hint of royalties being paid by themselves or the end users. I think that in itself speaks about the quality of our product and why it may have been an important step in bringing the internet to many desktops even though the lost revenue to ourselves runs up into the millions.
I have first hand experience of widespread exploitation of software, and that's more about what I am referring to mainly. With this issue I am seeing some worrying influences of corporatism taking seed and it would be good to understand the full implications of what has happened. To me it's a classic question of who's really in control.
In my opinion, Open source is going to show more and more of these problems because of the conflict of interest between open development and maintaining commercial advantage to remain competitive.
The fundamental issue is that if you are going market an operating system, you need to have a well defined and controlled environment for building the OS, especially the compilers and linkers. In fact, the very first part of the PetrOS project was to create a compiler capable of building the kernel from, which has proved fruitful because the kernel is extremely stable - I know exactly what machine codes are executing at any point in the kernel. When you are left to a 3rd party compiler, you are at the mercy of the compiler developers interpretation of how the language should be implemented, and even suffer the bugs they may have left in the distribution. I am only too familiar with that aspect.
The other issue that open source developers face is the frequent version releases, some perhaps not fit for public consumption. Clearly in this case, the gcc people should have made their version numbering scheme represent the beta nature of the product. Heck, even we do that with Trumpet Winsock. Before we go to major version release, we tag the version number with a beta sub version number to clearly indicate that the product won't be supported and that it should not be used for any production implementations or distributions.
It is for precisely these reasons that I have opted not to endorse an open source model for the PetrOS project, but rather some form of synthesis whereby key parts of the distribution are kept closed source, but allowing some of the outer edges of the project to be open source. I believe this is the only way for complicated projects like an operating system.
The other comments I hear (hearsay???) about Red Hat being closed shop about their plans hints of corporatism.
A word of advice to all those penguins out there. Beware the corporate world - it's ruthless and they'll take every advantage of the open source movement, even to it's detriment!!! I'm certainly not saying that Red Hat are doing this, but sooner or later, some company who wants to cash in on the Open Source movement will come in and plunder all the good work that's been done. Perhaps this incident is a small warning of what *could* happen. It's happened before in other parts of society - eventually "feel good" movements get exploited in one way or another either politically or economically.
I could say more, but it really deserves a much better appraisal than an off the cuff comment on a forum.
Don't get me wrong, I am in no way denigrating Open Source - I'm just saying that trying to operate it on a commercial basis is full of problems.
Just to set the record straight about what is reality from someone who has written an IPv6 stack. (Trumpet Winsock 5.0)
Firstly, IPv6 can actually aid your privacy in that it is now technically possible for you to *choose* your IP address provided you reset the globally unique bit, and use the duplicate address detection mechanism to make sure your traffic will work. The only time duplicates become a problem is when the same address exists in the scope of the network where it matters. i.e. your subnet for an ethernet connection, or the PPP link when you are using dialup.
It would be technically possibly for you to dynamically change the lower 64 bits of your IPv6 address during the life of your connection to the internet be that ethernet or PPP. There is one proviso in that it is not currently feasible to modify your address for active TCP/UDP connections, so you would need to close all active connections to lose all trace of your older address.
Given the active discussion that this topic has generated, I am now keen to add a feature to our stack which would build a random EIU64 address each time the interface is opened. This feature is already in place for PPP connections, and I could also add a button which would force a new address to be built on all interfaces. Of course to pick up the new address, all connections would need to be broken, but it would be a simple matter for the stack to continue using both addresses until the original address is fully deprecated. IPv6 is powerful enough to use as many addresses as you like from your internet node. That is the beauty of stateless autoconfiguration and neighbor discovery.
I suggest that slashdotters go and read the relevant RFCs *and* Internet Drafts in some detail, and they will realize how powerful IPv6 is and how it will solve many of the issues facing the immediate future of the Internet.
A good place to start is
http://playground.sun.com/pu b/ipng/html/ipng-main.html
The claim has not been made. I have a small subset of Win32 available to interface things. It uses COFF executable format, and there is not resemblance to NT driver structure whatsoever.
The rest has really been the result of the press. All I have said is that it could be likened unto an NT lite. It is a 32 bit OS that does away with the DOS layer, but has the potential to have similar characteristics to NT.
The only similarities to NT are...
1) the kernel and drivers are COFF executables.
2) there is a Win32 layer using DLLs.
Apart from that, there's nothing that can indicate that it is a rip off of NT. Indeed I adopt a completely different driver architecture to NT or Windows 3.x, Windows 4.x. (Windows 9x)
This is a downside in that NT drivers won't work as some people were curiously postulating.
As the OS has been designed from first principles, there are a multitude of API's that it could run, and this is its true potential.
One possible API that has been given serious thought to within the company is to have a native Java API built into it as close to the kernel as possible. The Win32 layer could then interface or coexist with this Java layer.
There are however some concerns about Java as a framework. The first one is that the Java architecture cannot fully represent the complete set of solutions to a given programming problem, and the second is that considerable resources need to be expended to get equivalent Java code executing at roughly the same speed as native C++ or Pascal code. Another concern I have is that I believe the garbage collection (GC) model used by Java will interact badly with the virtual paging mechanism. There are flaws in the GC model of Java that make it a challenge to write a truly well defined Java Virtual Machine (JVM). This may however be only be a feature of some of the earlier implementations of Java virtual machines.
Regardless, I have done some preliminary work on a just-in-time JVM for PetrOS. I am aware of the work of the ElectricalFire project, and this may be a short term solution to getting a working GUI operational if we can provide just enough framework for a Java GUI to operate.
But certainly, I want to reiterate that we are not wanting to supplant NT or whatever, but rather our strategy is to coexist in the marketplace with all other operating systems, and neither are we making claims that we are or will be NT compatible.
Finally, I have had time to reply to this topic after the interest that it's cooked up.
The most common feedback is that I should use OSS techniques to distribute the product. I however am yet to be convinced that this would be commercially practical to our company, since for the project to be successful, it will need to fund itself. OSS would work against us in that regard in my opinion.
From the point of view of making OSS provide resources for us, I have reviewed over the past year several of the OSS projects related to Win32. WINE has certainly caught my eye, but my concern is that the development has maybe progressed too far for me to make effective use of it in our project. If we can marry the two successfully and deal with any contentious commercial issues, it might be a goer. Of primary importance is however size. The primary goal of PetrOS is to keep the size of a working system to the minimum possible, as evidenced by our small kernel size.
Some technicalities of PetrOS.
The size is indeed *around* 100K. The last time I looked last week, the kernel was at around 120K.
Although this is certainly likely to grow, I'm currently using my own pascal compiler which produces manageable code, not optimal code. If & when I am able to get the kernel to compile with the Delphi command line compiler, I am likely to reduce the size down to almost 50% of its current size.
The kernel at the moment has built in support for FAT16, FAT32 IDE drives (no floppy support yet), standard AT keyboard, CGA monitor, COM1-4 ports, virtual paged memory, COFF executables and sockets. It's been built using object oriented Pascal throughout which has added significantly to its stability. It also supprots a loadable driver model so that the kernel itself should not require significant redevelopment over time. The sockets api is extendible allowing us to have the tcp/ip and network drivers as individual kernel modules loaded as necessary. In all this, I have no intention to become another Unix clone - indeed the Unix model possibly works against trying to create a framework that has the potential to provide any kind of alternative to a particular well known OS. Just to clear up any misconceptions, my work to date in no way emulates any of the NT kernel at all since I have no desire to be seen as an NT clone either. My only desire is to create a small & stable kernel that can run equally comfortably on legacy 486 machines to the latest & greatest Intel machines. As it is also written in high level language, porting to other platforms while not trivial should be relatively painless.
Also important in my design is to get the hardware as close as possible to the application layer without losing system integrity. I believe this is possible with prudent design, but does remain to be realized. Don't forget that one is using the same CPU cycles in kernel mode as you are using in User mode. The real bottleneck in OS design is user kernel transitions so if a lot of the grunt work can be done at the application layer, one *may* be able to write a fairly fast and robust GUI at that level.
As far as my background goes, I have some qualification to do what I am doing. I have been writing compilers since the late 70's and have spent at least 10 years of my working life writing and maintaining a variety of real time operating systems over diverse platforms. This all before I actually got involved in the internet and writing Trumpet Winsock for which you all know me.
Well, that's enough for now. I could talk heaps more about it, but the more CPU cycles I burn here, the less I have to work on the OS.
I just hope that you all can catch the vision of what the PetrOS project is all about, that I'm not trying to tear down Linux or FreeBSD or Windows NT or whatever. It's just that there's a need for something a little different to the mainstream out there, and PetrOS may have a chance of fulfilling that something.