I've been working on a very light-weight replacement for Quicken (which sucks rocks) and, obviously, Perl CGI is the way to go.

I'll take a chance of being accused of heresy here and say that I am not convinced that is 100% true. It is one way of doing this but not necessarily the way to go.

Ever since my flight from The Evil Empire and my reliance on Open Source software for my personal and professional desktop and laptop needs and quite a majority of server needs I haven't looked at or worked with Quicken®. I did use Quicken® when I was using the appropriate excuse for an OS that it ran on. It suited my needs at that time. I have worked with GnuCash and found that for my modest needs it works fine.

I say all that to say this: I refuse to reinvent the wheel. There are products out there that work and before I am going to rewrite one of them I first must answer the question: "What do I have to gain by expending my energy on that?"

So, I was wondering if this is possible:
1. You open a file on your machine.
2. IE looks at the file and executes it
3. That file returns back some HTML, which IE displays.
4. All the links go back to that file, causing step #2 to reoccur.

Yep, it's possible. Isn't that what an ActiveX® object does? I hated the darn things when I had to deal with them. Just as a "proof of concept" when ActiveX® was new and shiny I wrote an ActiveX® of a very malicous nature. It stole the contents of a Microsoft Wallet and wrote the contents to a MSSQL database for my later perusal. I wrote it and had a friend and coworker of mine execute it from my internal website at work just to prove a point. I later destroyed the code. Point being I don't like having browsers execute things on my machine other than trivial JavaScript stuff.

That's the question. The meditation is this - if this were possible, what does that open up in terms of distributability of apps, especially on Win32. IE is an excellent UI, the known HTML limitations aside.

I can see using IE (or other embedded browsers) as your presentation layer but not your execution layer. Let your backend code do the execution and let the browser do what it was designed for and present.

As far as software distribution, portability and such there is more than legions of facets to that topic, more than I am abitious enough to get into here.

I'll say this though: the "promise" of Java was supposed to be that whole "write once run anywhere" thing that Scott MacNeally was touting for so long. What Java was supposed to deliver was a development environment were your application was embedded within the browser and could run on any browser without a plugin. Albeit you could argue that a JVM is still a plug-in. Lots of folks have written lots of apps in Java using the insert browser here browser as the presentation layer. Very few of them that I've seen have impressed me in terms of performance or even portability. Case in point are some applications that my company has developed for internal use that will not run on Netscape but will on IE or vice versa. That isn't portability or "write once run anywhere" in my book.

OBTW: I agree with your assesment of Cygwin. I am done with Cygwin.