 |
 |
 |
 |
 |
| 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 separate project (see progress report), which I
will work on in parallel and as relaxation from the BibleTrans project.
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.
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) It compiles my source code into IBSM binary. Right now it uses the TAG compiler, which is based on C, and there are a lot of intermediate steps. Getting this moved over to a system with a decent scripting language will greatly ease the burden of recompiling the whole thing. Today (July 1) it seems to be pretty stable: Wow, two whole days without making changes! There are some non-essential language features and some code optimizations I have not yet taken the time to put in, plus some known bugs that I gingerly step around.
Itty Bitty Stack Machine (IBSM/Mac) That 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.
Mostly I've been working on several parts of this in parallel. Building the File System interface, I discovered that some String Manager functions were wrong, or got left out; then I had to fix the compiler to support them, and add micro-kernel handlers to pass them through to the appropriate manager; the same kinds of synergy happened when I added scripting. In the old "waterfall" model of software development you were supposed to get your design right first, before starting to code. God gets His design right on the first try; the rest of us debug our designs. In the new "iterative" model of software development they teach at the university, you are supposed to go through planned and scheduled iterations, design-code-test, then repeat; this schedule has the same problem as waterfall, because you really don't know what you need to do unless you've done it already. If it's been done already, why do it again? That's why I say that "software engineering is a fraud."
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.
| 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 | 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 | ||
| Text Editor | |||||
| T2 Compiler in T2 |
* "No Known Bugs" When I stop working on fixing bugs and just use it.
Turk/2 Compiler (IBSM) I need to redo the TAG compiler to generate IBSM code, so to sever this final tie to the Mac.
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++.