Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rick C. Hodgin

Pages: 1 ... 7 8 [9] 10 11 ... 17
121
General Discussion / Re: ES/2 open source OS/2 kernel
« on: June 05, 2017, 06:09:46 pm »
I began looking at my assembler last night, and when I stopped regular development last September, and worked only sporadically on the project since then (see blog), it was up to a point where the assembler was loading source code, expanding macros, and parsing top-down.  The parsing algorithms are partially complete, and development will continue from that point forward.  I've also since migrated my source code off of GitHub to my own Git server.  You can see the source code here.

My goals once again are to have the kernel up and running by the end of this year, first part of next year, and to be able to begin replicating the OS/2 command prompt on boot, as we add more and more abilities on top.

My first goals are to support the FAT32 and HPFS file systems, and a small range of video hardware devices, and to use BIOS for standard disk access.  This will allow more people to use the system in stages as it's being developed.  It will initially only be 16-bit and 32-bit, but eventually will be extended to be a true hybrid 32-bit / 64-bit kernel, capable of launching both from the single kernel.

My second goal is to have armies of developers come on board and begin helping write the lower-level drivers and devices, and then to begin porting apps from OS/2 to ES/2, as the API and compiler environment should be the same, but it will not be binary compatible any longer.

Here's to success!

Thank you, and God bless,
Rick C. Hodgin

122
General Discussion / Re: ES/2 open source OS/2 kernel
« on: June 04, 2017, 11:00:33 pm »
I have discovered the OS/2 kernel API is not published anywhere, except through illegally leaked IBM original kernel source code, which I've been told is what the Phoenix OS/4 project is based on.

UPDATE:  I've been told by developers on #os2russian on EFnet that the Phoenix OS/4 kernel is not based on leaked IBM kernel sources.  So, my apologies for having written that.  However, they have also told me that the kernel is written in "poetic form" and is to simply be accepted "as-is" ... so it has me in a wondering state to be honest. :)

As such, I'm going to focus on a full ground-up new effort, similar to what Linux did for UNIX.  This will be the ES/2 project, and it will be a complete mimic / duplication of everything in OS/2, but it will be made from all new sources.  Every main exe, dll, file, file format, etc., will be replicated.  Except for the fact that it won't be binary compatible, I believe every piece of code written for OS/2 that has sources, will be able to be re-compiled in the new ES/2 environment and work without change.

This is going to be a very large effort.  And I'm going to need help.  I'm going to start trying to recruit developers.  If any of you are interested in trying to help out, I'm willing to teach a class on C/C++ programming and even assembly programming on x86-based CPUs so you learn enough to start port user apps, including even low-level things like cmd.exe, a text-based version of e.exe, etc.

Thank you,
Rick C. Hodgin

123
General Discussion / Re: Exodus/2 (ES/2)
« on: June 04, 2017, 01:49:44 am »
I may pick this effort back up (to create a drop-in replacement kernel for OS/2).  It's a big job, but I truly believe it's the right place to start.  We need a completely flexible base to build everything atop, which can also be tweaked and extended as needed.  We also need a full kernel debugger.

I'm going to give it some thought over the next week.

Thank you,
Rick C. Hodgin

124
Storage / Re: HPFS and JFS internal definition specifications
« on: June 04, 2017, 01:47:00 am »
HPFS was one of the big reasons that made OS/2 a better DOS and Windows (3.x). Much faster then FAT.
It's a shame that MS kept HPFS386 and charged a $1000 for a license.
The story was that IBM and MS decided that they would each develop a new file system, written in C and capable of running on a 286 and which ever one was faster would be used. MS wrote HPFS386, won the contest by cheating as usual and IBM had to rewrite the HPFS driver and gave it the small 2MiB cache.
Hopefully you put some thought into the cache, could even use memory above 4GB I guess.

I promise you, I'm going to do it right.  And, it will be flexible and extensible.  I might even like to create a merged HPFS / JFS driver that handles both disk types.  But, we'll see.

As I start working on this I'm back to wanting to replace the kernel first.  There are significant limitations in trying to write and debug this type of code when you don't have access to the kernel source code.  It hampers you immensely.

Ugh.

Thank you,
Rick C. Hodgin

125
Storage / Re: HPFS and JFS internal definition specifications
« on: June 03, 2017, 10:31:23 pm »
It looks like the best thing for me to do is create my own custom disk format for development of this driver.  I can use a type that doesn't presently exist, and then create a driver which is able to access it using my own file system.

Once that is working and OS/2 is able to recognize the information on that disk through the API, an the API is all working correctly, then I can modify the algorithms to access the data on HPFS disks.

I'm really enjoying learning about HPFS.  I've always wondered why OS/2 hard disk access patterns sounded notably different than FAT32.  Now I know. :-)

Thank you,
Rick C. Hodgin

126
Storage / Re: HPFS and JFS internal definition specifications
« on: June 03, 2017, 02:41:32 am »
@Rick, don't forget there is a GPL HPFS driver in the Linux kernel.

I'm going over the patent right now, converting it from scanned image pages to text.  It's only 329 pages. LOL!  At least it's double- and triple-spaced mostly. :-)

Thank you,
Rick C. Hodgin

127
Storage / Re: HPFS and JFS internal definition specifications
« on: June 02, 2017, 07:10:28 pm »
Hi Rick.

My suggestions about file systems are the one that I posted.  If I will have to put those (HPFS, Boot JFS and ZFS) on priority order, it looks more interesting ZFS to me, since HPFS has MS patents on it and JFS is close source but AN is supporting it. ZFS can be focused on being an alternative for the future OS/2 file system. 

But while there are people saying "don't reinvent the wheel" I say "reinvent the wheel if it is not open source". Close source software is future abandonware to me, even if it works fine today. (Already discussed on the past how open source software reduce the risk to be left "high and dry")

Gordon Letwin, according to wikipedia, is a guy that made millions with Microsoft, so I found it a little bit hard to contact him to request HPFS source code, his OS/2 book, or any other things related to OS/2 to be turn open source/public domain. He seems to be more focused on environmental activism. But I had never tried to contact him.  Interesting historic post by Gordon Letwin, by the way.

If I can choose a priority outside the "File Systems" the priority should be to start cloning more deep components of OS/2 like the CPI API  (possible more based on libc library) and a PM/GPI clone (also with more close dependencies to libc instead of CPI). It will require developers with a good understanding of the CPI API, PM API and LIBC. But since I don't do development and do not have money for an army of developers, this is only "sweet sweet drunk talk" for the moment.

Regards

HPFS is very intriguing to me.  I'm going to continue learning about it to see if it continue to pique my interest.  It would be awesome to have an open source, well-debugged, high performance file system that could be ported to pretty much any OS with just a few tweaks.

I went through my old IDE hard drives last night looking for my PCI utility, but of the 10 drives I have, five were bad, three worked, and I have two left to test.  I couldn't find the content on the three drives that work.

Nonetheless, after booting up in DOS on those three drives last night, I had the thought I would create a FAT16 partition and install DOS, and a second HPFS partition and install OS/2, and then have files on there and begin writing my driver to be able to read that second partition, and eventually read and write to it, and then have it working and updating files in a way that OS/2 then sees when I boot back into it.

I might be able to accomplish the same thing looking at virtual machine disk files, but I'm not sure of their data format.  If they're linear, then it would be doable.  We'll see.

Thank you,
Rick C. Hodgin

128
Storage / Re: HPFS and JFS internal definition specifications
« on: June 02, 2017, 06:27:41 pm »
I restored the original fig5 and fig6 from the original source on the HPFS article. I don't what if the optimized images got list or maybe never was finished. I will check on that.
...I'll go ahead and create some new optimized images and you can update them when completed.

Emailed to you.  Taken from the link:  Google Patent #EP0416445A2

Thank you,
Rick C. Hodgin

129
Storage / Re: HPFS and JFS internal definition specifications
« on: June 02, 2017, 06:07:05 pm »
Quote from: Rick C. Hodgin
I contacted Arca Noae about this time last year when I was moving forward toward writing my open source OS/2 kernel replacement.  They were very non-receptive to the idea and it was a difficult email exchange over a week or two.

Well, first off, the kernel is not likely to be a short term project, and AN doesn't have the manpower to manage such a project over the longer term...

To be clear, I wasn't asking them to be involved with the project in any way, but was asking for some information, general help, guidance as to where to begin, etc., basically just as fellow members of the community.

I also never intended for it to be binary compatible.  It would become the root of a new open source OS/2 derivative that I have been calling ES/2.  It would be designed around every feature of OS/2 at its core (at least those that are publicly available), to produce an extremely similar environment to that of OS/2, but it would be its own off-shoot, kind of like how Linux is like UNIX, but it is not UNIX and there are distinct differences.

I still want to do that project.  I was telling my wife last night that if I had resources to do all the things I want to do, I would manage all of them, but the one thing I would personally write the bulk of the code for would be the kernel.  The rest of them I would write guidance and frameworks, but not details of the code.

Thank you,
Rick C. Hodgin

130
General Discussion / Mobile OS/2 kernel for ARM-based devices
« on: June 02, 2017, 04:43:28 pm »
Has anyone ever considered creating a mobile OS/2 version?

Is there any work in that area?  I can see the need for a new Presentation Manager, one that is backward compatible but revamps the presentation from its native form to a mobile display.  I have created a concept for my Visual FreePro language called mashing.  You take a standard form that looks like whatever it looks like, and then run a mash on top of it.  The mash can re-colorize, re-scale, substitute text, add a new appearance, or just do a copy-and-paste re-arrange of the original content.

The mash presentation algorithms trap keyboard and mouse events properly and send them to the correct handler in the original form below, only that upper surface visible layer exists for UI in the mash.

Maybe something like that would be doable, as a Presentation Manager Mash layer that would allow users to create the mashes whenever a screen is displayed, completely independent of any changes to the underlying OS/2 software.

I have a lot of ideas, and a lot of skills and abilities.  I do not have resources or funds to work on these projects as I desire to.  If anyone knows how I can get funding to complete these projects, I would be willing to work full-time on them.

Thank you,
Rick C. Hodgin

131
Storage / Re: HPFS and JFS internal definition specifications
« on: June 02, 2017, 04:37:33 pm »
Quote from: Rick C. Hodgin
I'm still waiting to hear back from Martin and the general community on what they think I should pursue.

It may be more useful to discuss the situation with Arca Noae. They are the ones who are driving the platform forward. No point in duplicating what they are doing, and they can use the assistance of a programmer who knows how to do such things.

I contacted Arca Noae about this time last year when I was moving forward toward writing my open source OS/2 kernel replacement.  They were very non-receptive to the idea and it was a difficult email exchange over a week or two.  If they're willing to guide me in some direction, I'd consider it.  I love the new Arca OS release.  And the idea of having a modern OS/2 is very appealing to me.  It's the most exciting idea I have in anything related to operating systems and general day-in/day-out computer use.

Thank you,
Rick C. Hodgin

132
Storage / Re: HPFS and JFS internal definition specifications
« on: June 02, 2017, 03:13:39 pm »
There already exists a "large file" API and there also exists additional entry points and extensions for existing entry points for file system drivers to support these new APIs.
These APIs will use 64-bit signed values to deal with file size and seek offsets.

The only problem is that the current HPFS.IFS was written at a point in time where these additional entry points where not yet defined.
If these additional entry Points were added to the existing HPFS.IFS then it would not be necessary to use the "DEADBEEF hack" and read in units of sectors instead of bytes.

As an example, there is an effort currently going on to add these additional "large file" entry points to the existing FAT32.IFS.
That will finally allow to deal with files up to 2^63 Bytes and likewise will allow byte granular accesses/seeks across disks up to a size of 2^63 bytes.

Well, since I'm essentially considering creating a new open-source HPFS from scratch with full backward compatibility, it would not be hard to add those newer extensions, and to allow for larger files.

We'll see.  I'm still waiting to hear back from Martin and the general community on what they think I should pursue.  I'm interested in both the USB and HPFS so far.  I want to take a look at JFS and ZFS as well.

Thank you,
Rick C. Hodgin

133
Storage / Re: HPFS and JFS internal definition specifications
« on: June 02, 2017, 02:07:14 pm »
I restored the original fig5 and fig6 from the original source on the HPFS article. I don't what if the optimized images got list or maybe never was finished. I will check on that.

Excellent.  Now that I see what they are, I'll go ahead and create some new optimized images and you can update them when completed.

Do you have an original source document for fig6?  It may be hard for me to decipher.

Thank you,
Rick C. Hodgin

134
Storage / Re: HPFS and JFS internal definition specifications
« on: June 02, 2017, 02:37:12 am »
Draw backs of HPFS, long chkdsk time, hate to think how long a chdsk /f:3 on a 2TiB partition would take :) Lack of large file support, the 2GiB file size limit is a problem. It is possible to work around this with the DEADBEEF flag, which changes seeking from per byte to per sector with caller having to manage things.
I don't know much else about the structures.

I've been reading about this tonight.  It looks like large file support could be overcome, as the theoretical maximum is over 7+GB as is.  That 7+GB limitation could be defeated with a tweak it could be extended out as far as is needed.

It seems the only true limit right now to very large files in HPFS is in the legacy API, which only receives 32-bit value for file-related offsets.  That could also be defeated with our own open source kernel and new API which supports 64-bit file operations.

-----
If I had money, I would devote a team of developers to creating our own open source OS/2 clone from the ground up, kind of like what Mark Shuttleworth did with Ubuntu Linux, although he still built atop the community base, and ours would be a full ground-up replacement effort, but I would be supporting the full legacy OS/2 API so all of our code could be compiled on existing OS/2 code bases for testing, and would also compile on the new OS/2.

Ah to dream...

Thank you,
Rick C. Hodgin

135
Storage / Re: HPFS and JFS internal definition specifications
« on: June 02, 2017, 01:28:53 am »
Martin, do you have these HPFS folder files somewhere?  This one is referenced specifically (www . os2world . com / images / hpfs / fig5 . png):


It's missing, and it's linked on this page:
http://www.edm2.com/index.php/HPFS

Thank you,
Rick C. Hodgin

Pages: 1 ... 7 8 [9] 10 11 ... 17