OSDev.org

Posted: **Fri May 09, 2014 5:35 am**

embryo wrote: But it still seems impossible to me to organize all the XML files in some manageable project with the OS as an output. At least it will be very great bunch of XML files and there should be some means to manage all of them. Also, the XML (and XSLT in particular) is not as compact as C or Java or many other languages - it is a problem too, it hides essential parts from a quick view or requires very powerful management application (XML IDE). It is very interesting if there is such an IDE and how it manages proposed combination of XSD+XSLT+XML.

Yes, there are a lot of files in my project, but I don't think it's any worse than the number of files in Linux or in your OS. Especially considering all of the platforms that are included. If you were to only count the 32-bit x86 stuff, I probably have less than 50 files.

But yes, it is a lot of work to keep it all organized. I've got them in folders that are laid out like namespaces, similar to Java or C#, which helps, a little.

I like Visual Studio's XML editor. It allows you expand and collapse elements, so you can collapse a class file and only see the method elements, and expand the one that you are working on at the moment. That helps a lot. And it's still a lot better than FASM.

Posted: **Fri May 09, 2014 5:45 am**

I should point out that I don't have any cross-platform code working yet, so none of the classes or functions that I've written for 32-bit x86 will work on 64-bit x86. It will all need to be recreated from scratch (or more likely, copied and pasted, and modified slightly). I decided to wait until I start working on the level 4 virtual machine stuff to tackle cross-platform code.

However, it would be easy enough to define a XSD schema that would include some common high level functions that would handle basic I/O, and write separate XSLT files for each platform to implement the functionality. You would just need to define a way to pass parameters to those methods that would work on all platforms, similar to stdcall or fastcall.

Makes me wish I had more time. Maybe it's time to put it up on github or google code...

Posted: **Sat May 10, 2014 11:20 am**

SpyderTL

Your words are quite explaining, I even can see something like high level OS picture. But I still have some troubles with program logic expressed in XSLT. It is simple to write assembly-like code using XML, and it is simple to transform such XML to the binary program representation using a bit extended XSLT engine (which is able to write raw bytes). But how to express some high level concepts using assembly-like approach? It is possible to write a whole OS in assembly, but the time to write such system will be very great. May be there is some way, similar to the high level language usage, to express the program actions? After you have assembly function defined it is required to call it from some kind of code - what kind of high level code you are going to use? If it is XSLT then I see some trouble in its algorithm agnostic nature. First of all the linear stream of execution is not the native thing for XSLT. Next the traditional conditional jumps and loops are not very friendly to the XSLT. It seems quite expensive to express a complex logic in XSLT. But, of course, any logic eventually can be expressed even in brainfuck

However, the time required to implement and debug such logic using brainfuck seems similar to the case with the XSLT as a primary vehicle of the program logic.

But may be it is just my incomplete and inexperienced view of the XSLT

Posted: **Sun May 11, 2014 2:07 am**

Yes, it's taken me years to get to where I'm at now. And I have no real memory manager, no class method parameters, no multitasking, and almost no network support.

However, I didn't start this project to get finished as quickly as possible... I did it to learn how modern PCs work, and how different things would be if someone started from scratch, and re-evaluated every accepted way of writing an OS, building an application, and interacting with a computer. I wanted to go back in time and say "what if we knew then what we know now?" Would we have done things the same way? Would we still use files, and folders, and icons, and windows? ANSI C and ASM are 40 years old. Are they really the best languages for OS and application development?

Posted: **Sun May 11, 2014 3:45 pm**

I mentioned earlier that I was pretty well convinced that XML wouldn't be terribly useful for cross platform application development. The way I'm thinking, you really only need two "keywords" or instructions to build an application using existing functionality -- one to define variables, and one to call methods. You may also need a few for program flow control: loop, if then else, etc. But that's pretty much it. So an application written in high level XML would probably be a lot of elements of the same type, which is highly redundant. So I'm trying to find something else to use for that.

Posted: **Sun May 11, 2014 7:43 pm**

Do you mean something like

Code: Select all

<set>
  <variable name="a" />
  <literal>0</literal>
</set>
<while>
  <condition>
    <lessthan>
      <variable name="a" />
      <literal>10<literal>
    </lessthan>
  </condition>
  <body>
    <increment>
      <variable name="a" />
    </increment>
  </body>
</while>

An XML abstract syntax tree?

Posted: **Mon May 12, 2014 1:24 am**

Yes. And as you can see, writing an application using that syntax would cause you to jump off of a tall building. Although you could simplify it a bit:

Code: Select all

<workflow name="CountToTen">
  <variable name="x" type="System.Integer" value="0"/>
  <variable name="y" type="System.Integer" value="10"/>
  <variable name="continue" type="System.Boolean" value="true"/>
  <while isTrue="continue">
    <call method="Increment" class="System.Integer">
      <parameter variable="x"/>
      <result variable="x"/>
    </call>
    <call method="IsLessThan" class="System.Integer">
      <parameter name="first" variable="x"/>
      <parameter name="second" variable="y"/>
      <result variable="continue"/>
    </call>
  </while>
</workflow>

This is more along the lines of what I was thinking. I may end up using something like this to store and process the application workflow (like an Intermediate Language). However, I still wouldn't want to type all of this in, by hand. For that, I would want a simplified version for viewing and editing the workflow. Perhaps something like:

Code: Select all

CountToTen
  x = 0
  y = 10
  continue = true
  while continue
    x = x.Increment
    continue = x.IsLessThan(y)

I'm open to suggestions, but it would need to be something that could easily be converted between the two formats. I would also like to minimize the number of keywords in the "language" itself (while, if, loop, break, etc.), and use static methods on classes instead. (i.e. x.Increment instead of x++)

Posted: **Mon May 12, 2014 5:15 am**

SpyderTL wrote:I wanted to go back in time and say "what if we knew then what we know now?" Would we have done things the same way? Would we still use files, and folders, and icons, and windows? ANSI C and ASM are 40 years old. Are they really the best languages for OS and application development?

Yes, I agree. It is very interesting to redefine many OS related things. Basically, there is almost no OS classification beside of monolithic kernel, micro kernel, exo kernel or some mixture of all of them. It means there is a plenty of things to redefine and redesign.

I think it is important to make some better OS classification and it should not be based on such crude division as is the case with all the kernel names. My preference is an OS architecture with clearly defined parts. Currently the parts are defined as components like memory manager or scheduler. But the enthusiastic OSes often have no scheduler and can have just tiny memory manager in form of a single simple function. How can we assess the OS value without an in depth analysis of it's code? Such assessment is possible when based on some classification, accepted by the majority of OS developers. Until such accepted classification is elaborated there will be the same short and obscured OS announcements like we have in the corresponding forum group.

However, XML based OS is highlighted by it's base language - the XML. It really distinguish such OS from other OSes and it is it's obvious value.

Posted: **Mon May 12, 2014 5:36 am**

The XML part is really only used at compile time, and is only used as a replacement for Assembler. After compile time, everything is just functions, structs and classes.

However, I have considered leaving some objects and classes in their XML form, and reading them in at run time. Although this would slow things down quite a bit, it would be interesting to see an OS that stored everything in XML on the hard drive, and maybe even in memory. Everything would be user readable, and editable. Maybe one day...

Posted: **Mon May 12, 2014 5:41 am**

SpyderTL wrote:I mentioned earlier that I was pretty well convinced that XML wouldn't be terribly useful for cross platform application development.

It is better to keep looking for the advantages of the XML. For example the nice part of XSLT is it's ability to work efficiently with such powerful abstraction as pattern matching. So, may be there is some way of redefining OS architecture as a set of components with pattern based interaction or something like this. It is an old idea about pattern driven systems with some works on it done in prolog and lisp. May be XSLT can add some value here?

SpyderTL wrote:you really only need two "keywords" or instructions to build an application using existing functionality -- one to define variables, and one to call methods.

We really only need a Turing-machine with it's simplest state-action relations as a program. But such abstraction is not very convenient. However, the state-action definition in XML with the XSLT as an actual state to action connecting vehicle, can be an interesting exercise.

SpyderTL wrote:You may also need a few for program flow control: loop, if then else, etc. But that's pretty much it.

It's the same problem for languages like prolog - with the power in a different area than the standard control of flow they still somehow manage to attract our attention.

SpyderTL wrote:So an application written in high level XML would probably be a lot of elements of the same type, which is highly redundant. So I'm trying to find something else to use for that.

If there would be another language then it will be not an XML-OS. As long as your competence is with XML it is better to leverage it as much as possible. May be you will invent a new way of writing XML with the help of home made IDE? So when you type:

Code: Select all

int x = 0

the IDE translates it to:

Code: Select all

<variable name="x" type="System.Integer" value="0"/>

Posted: **Mon May 12, 2014 5:52 am**

SpyderTL wrote:The XML part is really only used at compile time, and is only used as a replacement for Assembler. After compile time, everything is just functions, structs and classes.

No human being can manage the tons of machine codes after the compilation is completed. It means there is no problem - what is there after the compilation, just let the processor to do it's job. But when some design is implemented by a human being then there is a problem of simplicity which can be solved in many ways. And one possible way - the XML based system. In such system human readable content is meant to simplify the system development, while the compiled part is destined to be just a hardware friendly representation of human efforts.

SpyderTL wrote:However, I have considered leaving some objects and classes in their XML form, and reading them in at run time. Although this would slow things down quite a bit, it would be interesting to see an OS that stored everything in XML on the hard drive, and maybe even in memory. Everything would be user readable, and editable. Maybe one day...

Runtime things in XML are usable for debugging but hardly for something else. But human readable program sources and data files can help a lot during everyday system usage.

Posted: **Mon May 12, 2014 11:57 am**

embryo wrote:In such system human readable content is meant to simplify the system development, while the compiled part is destined to be just a hardware friendly representation of human efforts.

Exactly.

embryo wrote:But human readable program sources and data files can help a lot during everyday system usage.

They would be great for configuration files, shell scripts, etc. The question is whether the user should be able to open a program, view it as XML, change the XML, save it, and run it with the new code in place. I have to admit, that would be pretty cool, but I'm not sure how well it would work out in the real world. It would be pretty easy to implement, though, once you had the XML -> machine code conversion in place at run time.

Posted: **Mon May 12, 2014 12:13 pm**

embryo wrote:SpyderTL

Your words are quite explaining, I even can see something like high level OS picture. But I still have some troubles with program logic expressed in XSLT. It is simple to write assembly-like code using XML, and it is simple to transform such XML to the binary program representation using a bit extended XSLT engine (which is able to write raw bytes). But how to express some high level concepts using assembly-like approach? It is possible to write a whole OS in assembly, but the time to write such system will be very great. May be there is some way, similar to the high level language usage, to express the program actions? After you have assembly function defined it is required to call it from some kind of code - what kind of high level code you are going to use? If it is XSLT then I see some trouble in its algorithm agnostic nature. First of all the linear stream of execution is not the native thing for XSLT. Next the traditional conditional jumps and loops are not very friendly to the XSLT. It seems quite expensive to express a complex logic in XSLT. But, of course, any logic eventually can be expressed even in brainfuck However, the time required to implement and debug such logic using brainfuck seems similar to the case with the XSLT as a primary vehicle of the program logic.

But may be it is just my incomplete and inexperienced view of the XSLT

Maybe it would help if we were to focus on a specific example problem, and discuss possible solutions using XML/XSD/XSLT.

For example, I have yet to wrap my head around how to handle exceptions in XML. The hierarchal layout suggests using blocks surrounded by try/catch error handlers, like C#:

Code: Select all

<try>
  <call method="Open" class="System.File"/>
  <catch exception="System.FileNotFoundException">
    <call method="Show" class="System.Dialog">
      <parameter value="The file could not be found..."/>
    </call>
  </catch>
</try>

I have no idea how this would work on the back end, but fortunately, that is a problem for the VM or compiler to figure out...

Can you give me a program or OS situation where you think XML/XSD/XSLT would be difficult or impossible to represent, and I'll see if I can come up with a solution.

Posted: **Mon May 12, 2014 12:30 pm**

Another idea that I have been considering for simplifying the XML workflow approach would be to use the class definition XML files to create even more XSD/XSLT files:

Code: Select all

<class name="System.File">
  <method name="Open" type="System.File" isStatic="true">
    <parameter name="path" type="System.String"/>
    <!--Do stuff here-->
  </method>
</class>

This XML file could be used to auto-generate the following XSD file:

Code: Select all

<schema>
  <element name="System.File.Open">
    <attribute name="path"/>
  </element
</schema

And the following XSLT file:

Code: Select all

<stylesheet>
  <template match="System.File.Open"/>
    <call method="Open" class="System.File">
      <parameter name="path" value="@path"/>
    </call>
  </template>
</stylesheet>

This would simplify the program XML to:

Code: Select all

<System.File.Open path="../MyFile.txt"/>

And would convert it to:

Code: Select all

<call method="Open" class="System.File">
  <parameter name="path" value="../MyFile.txt"/>
</call>

This is similar to how all of my other low level (level 2) functions work now, but it would require even more XSD/XSLT files, and it would need to be somewhat automated as part of the build/compile process.

BTW, writing an XSLT that outputs an XSLT is an exercise in mind-bending, multiple planes of existence, out of body experience type crap...

Posted: **Tue May 13, 2014 2:36 am**

SpyderTL wrote:I have yet to wrap my head around how to handle exceptions in XML. The hierarchal layout suggests using blocks surrounded by try/catch error handlers, like C#:
Code: Select all
<try>
  <call method="Open" class="System.File"/>
  <catch exception="System.FileNotFoundException">
    <call method="Show" class="System.Dialog">
      <parameter value="The file could not be found..."/>
    </call>
  </catch>
</try>

The code you are trying to write represents just another form of an ordinary high level language. And it is the problem. New XML based language is worse than many other languages due to XML's size. It is much better to type

Code: Select all

x=1

than

Code: Select all

<set>
  <var>x</var>
  <value>1</value>
</set>

because the first variant is short. So you need to figure out some advantages of the XML and only after the advantages are clear for you it is possible to create some form of high level algorithm description in XML. For example, on of such forms is the XSLT. You can create something better

SpyderTL wrote:Can you give me a program or OS situation where you think XML/XSD/XSLT would be difficult or impossible to represent, and I'll see if I can come up with a solution.

It is not about impossible, but it is about time it takes to implement such solution. The two code examples above differ exactly in such a manner - both are possible, but time requirements for them are very different.

Concentrate on XML/XSD/XSLT advantages. And may be first you need to figure out those advantages.

And the form of the try-catch blocks is of least importance when it is still not clear why XML approach is better than a traditional high level language.

OSDev.org

Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS

Re: Object Oriented OS