 |
 |
 |
 |
 |
| Mac, My Windows | Mac, Hosted Windows | PC, My Windows | PC, Hosted Windows | PC, Native |
This started off to be a shell to run my BibleTrans
project development and deployment in, but it got too big. So now it's
a (dormant) separate project (see progress report),
which I planned to work on in parallel and as relaxation from the BibleTrans
project.
Nothing happened to this document between 2005 and 2012, so some of the design decisions and intermediate steps didn't get recorded. I'm trying to fill in some of that from memory...
Although I stopped working on MOS directly, I kept
the basic system call framework as glue to access Win32 and the (classic)
MacOS. I got BibleTrans working (download
demo here) using this framework, and am now (starting 2012 April) updating
the framework to do things better, more
OOPS-like,
and fully supported on the Mac. Then I will port the new version to Win32
and bring BibleTrans up to date (not necessarily in that order). The current
MOS
API is documented here. I'm using MOS just
about every day now (2013 March), for all new code, particularly as a testbed
for my BibleTrans project,
but also frex to do my income taxes, and it works pretty reliably. The
TAG
compiler is compiling itself with C completely out of the picture as of
the end of 2011, and in the revised (classic MacOS, but OOPS)
framework as of the end of 2012; the T2C version generates credible (but
still buggy) C++ code from a common source base as of 2013 March.
Program Manager, which starts and stops individual programsScripting is one of the things that programmers like about Unix. We really need it, but it doesn't have to be command-line based. With no command line, it's essential that the system be able to record the events as they go by. Apple did it right the first time, but threw it away (their current offering is crippled, but since the system is Unix, programmers can use shell scripts and makefiles). Except for being able to edit in conditionals and loops, I have recording working. Loops and conditionals means you also need script variables, which starts to look like a full programming language. I need something a little less complex.
Memory Manager, which allocates memory to individual programs on request
String Manager, to make this as easy to use as HyperCard was
File System, to store data in named disk files, organized into directories (folders)
Window Manager, to make it look and work Mac-like
Shell/Finder/Explorer, what the OS user sees, which finds programs to open data files
Scripting, so I can semi-automate complicated sequences of steps
Undo Manager, which is part of the scripting package, but also works without it (in the PC)
For now I think I will just parasite onto the host computer file system, which works. Later I can do my own. Similarly, I started with a simple command-line ("CLI") style of shell for debugging the OS, which worked so well I threw it away and went on to a window-based Mac-Finder-like program. That is now working. More details.
Turk/2 Compiler (Mac) The first version compiled my source code into IBSM binary. It used the TAG compiler, which was initially based on C, and there were a lot of intermediate steps. Getting this moved over to a system with a decent scripting language would greatly ease the burden of recompiling the whole thing, but instead I just made the compiler smarter. After I was generating IBSM code, I added what I call "virtual emulation" to generate 68K code which could be plugged into a Double-XX shell for stand-alone MacOS programs. Then I rewrote the XX shell code in T2 and eliminated the HyperCard step; also (I forgot which order) I revised the TAG compiler to generate T2 code. The result is that the TAG compiler now compiles TAGs down to T2, and one of those TAGs compiles T2 to native 68K code. With the TagLib now rewritten in T2, the whole process is a couple runs through the compiler, first TAG->T2, then T2->68K. If I start with the TAG compiler grammar, I get a new iteration of the TAG compiler. If I start with the T2->68K grammar, I get a new iteration of that compiler. Eventually, I expect to add a T2->x86 (native) compiler, but an intermediate step is T2C, which targets VisualStudio C++, and which I hope to be functional first half 2013.
Itty Bitty Stack Machine (IBSM/Mac)
The IBSM pretends to be a computer and makes everything
else completely platform independent. The current version is written in
compiled HyperTalk (same as the old Mac version of BibleTrans), with extensive
debugging facilities built in. The virtual machine is pretty stable, but
I keep adding debugging tools. More details. I have
not touched this in years. If I come back to it, I will translate the HyperTalk
to T2 before resuming. I have a tool that does about 90% of the conversion.
Before that I will probably see if I can build a T2-based OS on top of
the Linux kernel or (probably not) Win32. I briefly considered OSX as the
underlying platform, but there are too many hurdles -- like the dock, which
I don't know how to turn the bugger off; I think there's an API for turning
off the Windows task bar, and in Linux I can just eliminate that part of
the code.
| Project . . . | Started Work | Clean Compile | Usable | No Bugs* | |
| Micro-Kernel | 2004 May? | 2004 June 18 | 2004 July 1 | 2004 November 1 | |
| I/O Drivers | 2004 July 9 | 2004 July 14 | 2004 July 22 | ||
| Program Manager | 2004 early June | 2004 June 18 | 2004 July 31 | 2005 February 5 | |
| Memory Manager | 2004 mid June | 2004 June 18 | 2004 December 24 | 2005 January 24 | |
| String Manager | 2004 July 1 | 2004 July 5 | 2004 July 30 | 2005 February 28 | |
| File System | 2004 July 5 | 2004 July 9 | 2004 Dec 18 (host) | ||
| Window Manager | 2004 September 24 | 2004 October 16 | 2004 November 23 | 2005 January 26 | |
| Shell/Finder | 2004 July 20 | 2004 December 22 | 2004 December 24 | ||
| Scripting | 2004 December 27 | 2005 January 21 | 2005 January 26 | ||
| T2 Compiler (C) | 2004 March | 2004 April | 2004 June | ||
| IBSM/Mac | 2004 March | 2004 April | 2004 May | ||
| IBSM/PC | 2005 January 5 | 2005 January 7 | 2005 February 11 | ||
| 68K framework | 2010? | ||||
| Win32 framework | 2005 | 2008 (not OOPS) | |||
| Text Editor | 2011 sometime? | 2012 March | |||
| T2 Compiler in T2 | 2011 October | 2012 January 14 |
* "No Known Bugs" When I stop working on fixing bugs and just use it.
Turk/2 Compiler I used to have a (C-based) T2->C compiler; I'm
trying to get it working again with the OOPS version
of T2, so to sever at will this final tie to the Mac. But I'll probably
continue to use the MacOS for development, at least until I get the editor
and scripting working and portable.
You need to have done some things similar enough to this project so that you can reasonably expect to succeed. However, if it's exactly the same, if all you are doing is what the managers and the experts call "code re-use" then you are wasting the good gray matter God gave you. I don't do that. Maybe that's why I'm writing this here, instead of giving a report to a supervisor. It's also why I'm able to attempt great things, and sometimes succeed. I'm not alone in this, there are at least a dozen, maybe hundreds of sharp programmers who refuse to be straight-jacketed into somebody's "methodology." Sometimes we fail, but the really cool programs didn't come out of methodology.
One problem I recently encountered is with DragonDrop, if you start a drag, and then abandon it on a non-drop site, somebody needs to clean up the mess. MOS can be told to catch those cases, but what about dropping in on a drop site when the receiver drops the ball? HyperCard had this hierarchy of message handlers, so if one level of recipient didn't catch it, the next level up did. In MOS I really need some way to queue up a default cleanup task to take over after the intended recipient has had a chance to deal with it. Apple's DragonDrop always reported back to the sender as the final step, but that was not properly threaded. I'm trying to let the sender go after releasing the package, but that may be too optimistic.
What we need is a third category of event, in addition to synchronous messages, where the sender process waits in the event queue of the receiver and is released when the receiver goes back for another event; and asynchronous messages, which use one of a set of pre-allocated message records. This third category can use the same async records, but there is attached to it a defined reply (async) message that gets sent when the receiver completes. That way a drop message can automatically notify the system to delete the package when the receiver is done processing it. We can also use it to release a lock on the system clipboard, which keeps (possibly a copy of) the data stable during a Paste, even while the user has gone on to initiate another Copy.
IBSM/PC A couple weeks of work and presto! Everything runs
on the PC. Or unix. Or whatever. How about One Week? There are still
a couple glitches (this is, after all, C, and most of the debugging time
has been spent finding bugs that my T2 compiler would never let out of
the gate), but Yeeehaw! See screen shots.
2004 July 30 -- A command-line shell ran the first separately compiled program file. It takes a lot of operating system to support this much.
2004 October -- Took six weeks off to write and debug GeneScreen, a Windows program. I guess it was a good thing to do, but I planned on finishing it in 2 weeks. sigh
2004 November 20 -- The new window manager opens a window with a button that takes clicks. Windows and graphics are more than 25% of the total program so far, some 2500 of about 9600 lines (6000 MOS + 3600 IBSM). By the way, the industry standard for software productivity is one line of debugged and documented code per hour; I have done something close to 80 lines in each of the 1200 hours or so I spent so far, but it's not fully debugged and hardly documented at all. Oh wait, I forgot 4700 lines of Turk/2 compiler source code, more than half of it new this year.
2004 December 24 -- The Finder opens and closes windows with icons in them, and 2-clicking an icon runs the program, which opens its own windows. The command line shell is gone. Memory is allocated dynamically to programs as they need it. In other words, the system basically works.
2004 December 31 -- Scripting (along with system support for Copy/Paste, DragonDrop, and Undo) is in, and I have a clean compile, but I have not yet started to debug it. File dialogs turned out to be messier than I hoped, and I need to be able to save the recorded script and edit it... When you design a system from the ground up to be event-driven, these things (scripting, not the dialogs) are incredibly easy to do and get right.
2005 January 5 -- It now records scripts as things happen, but playing the script back with full conditionals and loop control is a little more involved that I was thinking. I'm going to put it on the back burner to simmer while I work on the PC implementation of the virtual machine.
2005 January 11 -- How about that? The PC version up and able to 2-click program files. The framework I bought for the gooey is quite sluggish, but the underlying virtual machine runs some 30x faster than the emulated 68K code on the Mac, where it is also full of extra debugging code. Much more significant, this takes a lot off my concern about finishing BibleTrans in a timely manner. The Mac version of the IttyBittyStackMachine is coded in 4000 lines of compiled HyperTalk, the same language as 67,000 lines of BibleTrans. If 4000 lines convert to (yuk!) C and runs in a week, then it's reasonable to suppose that a 16x bigger program just might be converted to a far superior language in a half year or less. Hallelujah, we can do this!
2005 January 26 -- Previously recorded (and possibly edited) scripts now execute, complete with loops and conditionals and temporary variables. I wrote a little script to open three copies of my test program, then to move the windows to a staggered place on the screen. Scripting is essentially yet another programming language, with a virtual machine to execute it and a compiler to convert text into its machine language. I've done this kind of thing enough times that there was never any doubt about making it happen, but it is a significant piece of work. Althought it does not at this time, it would be a "simple matter of programming" (not necessarily trivial, but unlikely to harbor unforseen show-stoppers) to use this to script the Windows (host) command line, so that I can use the same scripting tool to automate Windows stuff as well as my own, although of course I don't have recording access to the Wintel command line, so I can't make it any easier to use than a unix shell script at that level. Inside my own system, however, I just turn on recording, do what I want automated, edit the script text (if necessary) to adjust parameters, then save it as another icon to double-click when I want it to do that task.
2005 February 5 -- I think today is a glimpse of the next half-year or so. The GUI framework I bought to run this on a PC is a little more crippled than I hoped, so it took some hacking to get the Wintel-hosted windows (see below) working. To start my heavy analysis I decided to collect the relevant files together into one, a trivial job for a unix shell script, or pretty easy in HyperCard; I decided to do it in MOS-hosted T2, where it should have been easier than HyperCard (but not yet as simple as a shell script) -- then spent the whole day swatting all the system bugs that came crawling out. You expect some, but I thought it was more robust than it turned out to be.
At the end of January I could have actually started programming BibleTrans in Turk/2, but I thought it might be better to rework my operating system environment so it (optionally) uses the host windowing system. Ideally I can write programs to run in my system, then by flipping a switch in the OS, they look like native Wintel programs. Ultimately, that's what I need to do with BibleTrans, but I have a few months right now to do that in the Qt framework I bought, then get out of Qt entirely (it's just another proprietary third-party package to depend on, and I have been burned too many times doing that) before their one-year support runs out. At the rate things are going, I can have that done in a couple or three months, and still have BibleTrans working by the end of the year.
2005 February 9 -- Got the IBSM running with
hosted windows. Here is the same operating system code and the same compiled
test program, running in both the Mac and PC, both my own windowing system
and the host:
|
|
|
|
|
| Mac, My Windows | Mac, Hosted Windows | PC, My Windows | PC, Hosted Windows | PC, Native |
The window with the menu and disk icon on it in the hosted shots is
only there for testing; it will go away for embedded programs. The PC version
is still using the Qt framework. Hopefully that will go away soon. [2005
February 14 update: the screen shot on the right end was made without Qt!
The program is half the size of the Qt version (2% if you count the required
Qt DLL) and also runs in older systems like Win95,
which the Qt version does not.]
2005 February 11 -- When I first tried to use the Microsoft
VisualStudio (VS) compiler at the university, it was an exercise in frustration.
I was totally unable to get anything useful to compile. I could use their
wizards to create a "solution" which opened a generic document window,
but I could not add any code to it that did anything useful. Qt uses the
same VS compiler, but they make their own project files, which do work.
About the same time I got an evaluation copy of a Microsoft Press book
Programming Windows by Charles Petzold. I considered using it to
teach the C/C++ course, but there were better choices and I set it aside.
This week I got it back out to see if it could help. He gives a lot of
source code, and there's a CD with ready-to-use source code and VS project
files. The CD has the usual onerous EULA on it --
which if at all possible, I carefully avoid "agreeing" to, this time by
not using the CD -- So I typed in his classic C "Hello World" program by
hand. VS refused even to give me the option to compile it. Finally I made
up one of the generic VS project "solutions" and deleted all the generated
source code and pasted my hand-typed text in -- and it worked. It's a crummy
way to run a compiler, but this hand-typed program runs on Win95 (Petzold's
book is targeted at Win98, which is mostly the same inside), while their
wizard program requires WinXP. Recall that this is Microsoft Press,
and they make their money selling their latest operating systems (WinXP),
not books. I'm now on my way to proprietary product freedom.
2005 February 17 -- As I found to be the case with VisualBasic, the Microsoft documentation is so bad that there is great incentive for 3rd-party replacements. I found what I needed to do DragonDrop (not covered in the Petzold book) yesterday on James Brown's Catch22 website -- and it's all explicitly "public domain." I am now completely free from all dependencies except the operating system itself, and even that is open: my test program (and eventually BibleTrans will) runs on everything from Win95 on. Amazingly, it's faster to program in Win32 native than in the Qt framework, and the code is smaller and easier to understand. "Houston, we have lift-off!" I can probably even sell my services as a genuine Wintel programmer...
2005 February 26 -- Decided to split this project off from BibleTrans. A "simple" open-file dialog took waaay too long to get going. Finally got it working March 7. Getting a production-quality text editor up is probably 6 weeks; converting the TAG compiler to Turk/2 another month. Only God knows how many pitfalls I still cannot see. sigh.
2005 April 1 -- Got data resources working as system calls in MOS. It turned out to be messier than I expected, but writing test code sure was a big help in finding the problems cleanly. It also helps to be doing this on my own software.
2005 October 1 -- A MsgBox for short output messages (and button selection for input) is pretty trivial to write; I had it going pretty early in the game. A text input dialog is a lot messier, and I put it off -- until I really needed it. It still only does my fixed-width system font, but at least selection and typing and arrow keys work as expected. I needed this facility for a NewFile dialog, which also works today. Whew.
2005 December -- Formal work on MOS suspended. I'm still supporting the API in a PC Framework, which compiles into a library of C++ functions that get linked into T2 code also compiled to C++.
2008 -- I got enough of the PC framework working so that BibleTrans is now downloadable. Started work on my Text editor...
2012 April -- I decided to set the editor aside and finish the BT conversion to OOPS.
2012 December -- Lost my context for a couple months (Nov+Dec),
so I resumed in late December converting my T2C compiler. Still working
on it.