> Long before operating systems got exciting names based on giant cats and towns in California named after dogs, most of their names were pretty boring.
Ah, yes. Mavericks, California. It's a great little offshore town, just off Pillar Point. I love that town.
Kidding aside, this is a great article.
Related to this story, the Windows 3.0 visual shell was originally not supposed to be Program Manager and File Manager. It was going to be a program called Ruby that I worked on with Alan Cooper and our team.
Ruby was a shell construction kit with a visual editor to lay out forms and components, which we called gizmos. You would drag arrows between gizmos to connect events fired by one gizmo to actions taken on another.
The shell was extensible, with an API for creating gizmos. A really weak area was the command language for the actions to be taken on an event. It was about on the level of batch files if that. But we hoped the API would allow for better command languages to be added along with more gizmos.
BTW, this project was where the phrase "fire an event" came from. I was looking for a name for process of one gizmo sending a message to another. I knew that SQL had triggers, but for some reason I didn't like that name. I got frustrated one night and started firing rubber bands at my screen to help me think. It was a habit I had back then, probably more practical on a tough glass CRT than it is today.
After firing a few rubber bands, I knew what to call it.
(As one might guess, I've always been curious to know if the phrase "fire an event" was used before that. I wasn't aware of it, but who knows.)
Anyway, Ruby didn't become the Windows 3.0 shell after all. The went with ProgMan and FileMan instead. To give Ruby a better command language, they adapted Basic and the result was Visual Basic. Gizmos were renamed "controls" (sigh), and my Gizmo API became the notorious VBX interface (sorry about that).
And we still don't have a programmable visual shell in Windows.
Inadvertently, you could say I owe my entire programming career to you specifically. Yes I can expound upon VisualBasic's retarded conceptions but playing around and making "Forms" was how I got really interested in programming as a career choice. One could say DOS batch scripting had a hand before that but it wasn't until VB3 that I really pursued it in earnest. It wasn't until a CS 101 course teaching Pascal where every thing really gelled into a cohesive unit in my brain. I still can't deny the VB underpinning even if I laugh when I admit it. Had Ruby been around with my batch scripting background, things likely would've taken the same turn either way. Regardless of how you see it now, there's likely a lot more people like myself with a similar story.
Having said all that, what you describe would still be interesting today. I just don't know how feasible it would be to implement. I had a file manager/shell idea in the form of a game construct. Something like crates to open or destroy as a delete mechanism. It was never more than a fleeting concept but I find it interesting that I'm not the only one lamenting about what is now Explorer.exe.
Actually, the apology at the end of my post wasn't about Visual Basic as a whole, but the VBX interface specifically. People did use it to build a lot of nifty controls and extensions, but the interface itself wasn't the best-designed thing in the world, and Microsoft eventually replaced it with COM/OCX.
"Control refers to any set of rules describing conditions under which processes may fire an event or switch to a new state."
Other sources confirm that there is a 1979 book with that title. (Google Books sometimes has a dramatically wrong year.) However, I don't have access to the book to verify it for myself.
There's also a interesting reference from particle physics; "Figure 6 shows the number of tubes that fire an event vs. the number of photo- electrons.", Proceedings of Workshop on "Weak Interactions and Related Topics", December 13-15, 1979. While not the same, it feels like a similar construction.
Otherwise, the only relevant hits for that phrase are post-1990.
> And we still don't have a programmable visual shell in Windows.
Very true, there isn't one. But there are several. None of them all that good though. Windows Workflow, System Center Runbooks, Biztalk, they've all made their mark. I've seen serious systems built using all of them, ultimately I have to wonder whether visual programming on that scale is even a good idea.
It is not a good language indeed. It doesn't allow you to express proper abstractions or anything particularly interesting.
But it did allow you to get things done very quickly, and that's why you see that was used a lot in several industries for small things that doesn't require to be maintained a lot and still do useful things.
I don't think we used that exact terminology, but back in the '70s in the real-time interrupt-driven world, the concept was there. In fact, if you had used that phrase at that time, everyone would have grasped the meaning.
Indeed, when I was firing those rubber bands, I didn't think I'd coined some truly novel piece of terminology. It seemed like a fairly obvious word, especially given the use of "trigger" in the SQL world.
Ah, it starts to come back! In SQL, "trigger" is a noun, not a verb. It refers to a stored procedure that's executed in response to some event.
I knew "trigger" could also be used as a verb, of course, but it seemed that it might be confusing to use it that way given its meaning in SQL. So that's when I started searching for words and firing rubber bands.
I might have fired up something else too, but that's a story for another day...
I knew about Alan Cooper legacy in VB, but not the Ruby project. Is VB the only program that used this idea at Microsoft ? even another internal project ?
I wasn't working with Alan when he wrote the original Tripod prototype. He hired me and Gary Kratkin, Mark Merker, and Frank Raab to rewrite the whole thing in a more maintainable and extensible way.
Alan was a good coder before he decided to concentrate on UX design, but like many prototypes where a number of different ideas have been explored, the code got a bit messy and he felt a fresh start was called for.
Ah, yes. Mavericks, California. It's a great little offshore town, just off Pillar Point. I love that town.
Kidding aside, this is a great article.
Related to this story, the Windows 3.0 visual shell was originally not supposed to be Program Manager and File Manager. It was going to be a program called Ruby that I worked on with Alan Cooper and our team.
Ruby was a shell construction kit with a visual editor to lay out forms and components, which we called gizmos. You would drag arrows between gizmos to connect events fired by one gizmo to actions taken on another.
The shell was extensible, with an API for creating gizmos. A really weak area was the command language for the actions to be taken on an event. It was about on the level of batch files if that. But we hoped the API would allow for better command languages to be added along with more gizmos.
BTW, this project was where the phrase "fire an event" came from. I was looking for a name for process of one gizmo sending a message to another. I knew that SQL had triggers, but for some reason I didn't like that name. I got frustrated one night and started firing rubber bands at my screen to help me think. It was a habit I had back then, probably more practical on a tough glass CRT than it is today.
After firing a few rubber bands, I knew what to call it.
(As one might guess, I've always been curious to know if the phrase "fire an event" was used before that. I wasn't aware of it, but who knows.)
Anyway, Ruby didn't become the Windows 3.0 shell after all. The went with ProgMan and FileMan instead. To give Ruby a better command language, they adapted Basic and the result was Visual Basic. Gizmos were renamed "controls" (sigh), and my Gizmo API became the notorious VBX interface (sorry about that).
And we still don't have a programmable visual shell in Windows.