Author Topic: ES/1 open source kernel  (Read 8104 times)

Alfredo Fernández Díaz

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 17
    • View Profile
Re: ES/1 open source kernel
« Reply #45 on: December 16, 2017, 01:23:58 pm »
Just a quick question: unicode?

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #46 on: December 16, 2017, 01:33:37 pm »
Just a quick question: unicode?

For ES/1, partially supported through limited code page support through libsf and libsf-mono fonts.  I am creating a new font editor tool.  The more help I get in authoring characters for other languages, the more support there will be.  I wil unveil the font tool next.  You will see limited ES/1 updates until then.

For ES/2:  Planned to be fully supported.  I like Microsoft's ability to have funcA() for ascii, and funcW() for unicode.  There will be full kernel support for unicode, including filenames and all tag names.  Everything that can be asciiz can also be unicode, except conversion functions. :-)
« Last Edit: December 16, 2017, 01:40:30 pm by Rick C. Hodgin »

Alfredo Fernández Díaz

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 17
    • View Profile
Re: ES/1 open source kernel
« Reply #47 on: December 16, 2017, 01:58:16 pm »
For ES/1, partially supported through limited code page support through libsf and libsf-mono fonts.  I am creating a new font editor tool.  The more help I get in authoring characters for other languages, the more support there will be.  I will unveil the font tool next.  You will see limited ES/1 updates until then.
You may want to check Alex Taylor's bitmap and vector fonts -- I think his license would let you relieve quite some work from that front. Custom tools or not, I don't think you have developed a third way to define glyphs* so you probably can re-use work.

*You haven't, have you? :)

Quote
For ES/2:  Planned to be fully supported.  I like Microsoft's ability to have funcA() for ascii, and funcW() for unicode.  There will be full kernel support for unicode, including filenames and all tag names.  Everything that can be asciiz can also be unicode, except conversion functions. :-)
Just like it is a subset of all codepages, ASCII is also a subset of unicode (ASCII chars are unicode chars 0-127), so why do you need funcA?

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #48 on: December 16, 2017, 02:22:42 pm »
For ES/1, partially supported through limited code page support through libsf and libsf-mono fonts.  I am creating a new font editor tool.  The more help I get in authoring characters for other languages, the more support there will be.  I will unveil the font tool next.  You will see limited ES/1 updates until then.
You may want to check Alex Taylor's bitmap and vector fonts -- I think his license would let you relieve quite some work from that front. Custom tools or not, I don't think you have developed a third way to define glyphs* so you probably can re-use work.

*You haven't, have you? :)

I began with fundamentals.  I designed everything up from there.  I did what made sense to me.  Others can judge for themselves the nature of its originality or usefulness.

Quote
For ES/2:  Planned to be fully supported.  I like Microsoft's ability to have funcA() for ascii, and funcW() for unicode.  There will be full kernel support for unicode, including filenames and all tag names.  Everything that can be asciiz can also be unicode, except conversion functions. :-)
Just like it is a subset of all codepages, ASCII is also a subset of unicode (ASCII chars are unicode chars 0-127), so why do you need funcA?

ASCII goes 0..255 in my opinion. :-)  It never made sense to hobble existing apps which use those characters so they'd have to be significantly rewritten in moving forward.  Less of an issue now, but still ... it's a sound goal.

I'm not trying to piece together what already exists because it's faster.  I'm trying to build up a product from the ground, founded on the Lord, given over to this project for the people, so that all of it is built from within those who will contribute, for that purpose, on purpose.  In that way its origins are solidly given over in that way, with a common thread of purpose throughout.
« Last Edit: December 16, 2017, 02:34:55 pm by Rick C. Hodgin »

Alfredo Fernández Díaz

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 17
    • View Profile
Re: ES/1 open source kernel
« Reply #49 on: December 16, 2017, 02:55:42 pm »
ASCII goes 0..255 in my opinion. :-)
But that's what the codepage mess was about from the start. All codepages I know of* (classic ones, I don't know if the term has caught on a new meaning lately) are 255-character sets, and every character on any of them is therefore represented by one byte. And that's the problem: simplifying quite a bit, you only 'know' character 0x65 is an 'A' because ALL codepages have 'character 0x65 = A' in their definition. But the answer to 'what is character #128' (or whatever > 2^7 -1 = 127)? depends on what codepage you are using. You can't just put say Spanish and Russian ASCII text together like that because the same numbers above 127 represent different characters, etc. Unicode was conceived to get rid of those problems, but had to be retro-fitted unto existing systems, which caused problems of its own.

If you asked me, my own Unicode implementation would be very different from what we have currently, but that's another story. If you are beginning something from scratch, and want it to be able to eventually 'talk' to the rest of existing software, proper Unicode support is a must because it is nearly universal now.

*I am leaving DBCS CPs aside for the sake of simplicity. These are of course 65535-char codepages, hence 'DBCS'.

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #50 on: December 16, 2017, 03:00:41 pm »
If you asked me, my own Unicode implementation would be very different from what we have currently, but that's another story. If you are beginning something from scratch, and want it to be able to eventually 'talk' to the rest of existing software, proper Unicode support is a must because it is nearly universal now.

What would you create?  OS/2 supported unicode, albeit clunkily.  It would be a reversal of direction to replace it.  It's also completely prevalent today.  If any apps would be ported, support would have to exist.

Alfredo Fernández Díaz

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 17
    • View Profile
Re: ES/1 open source kernel
« Reply #51 on: December 16, 2017, 03:13:34 pm »
Sorry, we can discuss my own ideas of how we could have a better Unicode some other day, it would require much thinking and long-term plans of interoperability -- assuming it would actually be better ;)

What I meant to say is that any new thing of yours that wants to talk to other software today must readily implement Unicode as we have it today (or interfaces to it), and not get stuck in the codepages stage. If it is not, fine :)

Andreas Kohl

  • Sr. Member
  • ****
  • Thank You
  • -Given: 6
  • -Receive: 12
  • Posts: 280
    • View Profile
    • warpserver.de
Re: ES/1 open source kernel
« Reply #52 on: December 16, 2017, 04:28:54 pm »
ASCII goes 0..255 in my opinion. :-)
7-bit ASCII was always from 0 to 128. But ISO-8859-1 (CP819) offers 8-bit.

Quote
But that's what the codepage mess was about from the start. All codepages I know of* (classic ones, I don't know if the term has caught on a new meaning lately) are 255-character sets, and every character on any of them is therefore represented by one byte.
That's the special case for 8-bit SBCS codepages - it's a good idea to distinguish between codepage and char set.

Quote
And that's the problem: simplifying quite a bit, you only 'know' character 0x65 is an 'A' because ALL codepages have 'character 0x65 = A' in their definition.
I can not follow at this point. Only a subset ASCII derived codepages behave this way. Decimal 65 for 'A' fine but in EBCDIC 'A' is 193.

Quote
But the answer to 'what is character #128' (or whatever > 2^7 -1 = 127)? depends on what codepage you are using. You can't just put say Spanish and Russian ASCII text together like that because the same numbers above 127 represent different characters, etc.
ASCII is a stupid American thing. For Russian there is GOST or better use Unicode. If you want to manage it with 7-bit ASCII you can do it with TeX.

Quote
*I am leaving DBCS CPs aside for the sake of simplicity. These are of course 65535-char codepages, hence 'DBCS'.
But nowadays MBCS are quite common or call it variable character size encodings.

Rick C. Hodgin

  • Newbie
  • *
  • Thank You
  • -Given: 2
  • -Receive: 0
  • Posts: 37
  • Greetings. I come in peace (for OS/2 things only).
    • View Profile
Re: ES/1 open source kernel
« Reply #53 on: September 18, 2018, 11:09:32 pm »
Just a quick update.

This project has not gone away and will continue.  I am currently working on developing a general purpose compiler called CAlive that supports (C/C++)-like code.  It will serve as the base compiler used for x86, as well as my own VM I'm working on (called Inspire VM), and will serve as the compiler I use to compile the user OS/2 source code people have for creating binaries that run in ES/2.

ES/1 will serve as a simple test platform for developing and testing new designs that will filter into ES/2.

If any of you would like to help, my plans are to continue development of ES/1 and ES/2 after I get my compiler completed, which is targeted for sometime on or around Christmas 2019.

Thank you. :-)
« Last Edit: September 19, 2018, 01:22:07 am by Rick C. Hodgin »

David Graser

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 8
  • Posts: 206
    • View Profile
Re: ES/1 open source kernel
« Reply #54 on: October 06, 2018, 07:25:15 pm »
Rick

Hopefully your new kernel will eventually do away with the SIQ. 
« Last Edit: October 06, 2018, 09:49:40 pm by David Graser »