Hi Steve,
Respond in-line below.
David
Steve Easton said:
Hi David.
If I understand you correctly what you want to do is use an .hta to create a "front end GUI" to run
what is basically a "console application" in the background.
The .hta / "front end GUI" is correct. As far as "console application" - I
am not sure. It is true that portions of the application would run from time
to time autonomously in the background but would also be accessed by the
user like any other full fledged Windows applicatioon.
In-Line below
Although the file that launches an .hta is mshta.exe ( Microsoft HTML Application host ) an .hta
runs in the Internet Explorer domain with all of the security guards and restictions of Internet
Explorer.
But as mentioned, I think I read somewhere that I can incorporate IE
components (at least sufficiently enough to run .hta) [when using VS 2005 ?]
into C++ so the user would not need IE by itself. In a second thought, that
is not a big deal in the Windows market since IE is about 90% of the
Windows' browsers' market share. Interestingly though, FireFox started to
gain some momentum and for the first time in years, it pulled down IE in
Europe slightly below 90% (already last December).
Managed code is code that runs under .NET You can easily compile
"unmanaged" code. However, the
more familair you become with .NET and managed code the more you will realize that what "managed"
actually means is "better security."
As I mentioned before, I don't have much concerns of security. The
application connects once in a couple of days to the internet (in the
background, w/o user's intervention) but: 1. That automatic, fairly short,
interaction with the internet does not involved in the transfer of any
sensitive information whatsoever. 2. In terms of hackers trying to use these
internet sessions just to cause havoc in the clients computer - if my
application has full control of the internet communications (especially if I
incorporate the "internet connection" objects into the application), I
believe I could easily take care of the hackers.
Proprietary API's . Interesting term. I wouldn't call them proprietary. Windows API's are windows
API's. They run in / interface with windows. They are freely available for any developer to use.
I think you are right that i need to clarify "Proprietary API". What I mean
is that the API could be a very simple - the fact that there could be (and
actually are) 1000s of function calls to the OS does not mean they have to
be made complicated and being a changing target all the time. For example,
why are good Forms interface design available only under .NET and "managed"
C++ and not simply true C++? Not only that, in many of MS' books that deal
with .NET, they say on the one hand that C++ is "not left orphant" but on
the other hand, most if not all examples are in VB or C#... - no mentioning
of C++. Moreover, many things simply require VB and/or C# (both of which are
MS proprietary stuff par excellence and of no particular advantage compared
to other languages) or "managed" C++ at best. I heard that VS 2005 is
suppose to somewhat rectify on this situation but I have my big doubts about
it.
For obvious reasons (even though MS trys to hide that fact) MS is trying to
keep the development community as a captive community (resulting also a
captive product market) with all those akward .NET/C#/"managed C++" (as if I
need MS to "manage" my C++...). Imagine that the API would be a simple TRUE
(PURE) standard C++ interface - one could then easily port his application
to many OS, perhapse with few #ifdefs, which is obviously against MS's
interest.
Is there any non-morbid reason for the creation of C#? Isn't that
proprietary par excellenace? Nobody could ever give me an non-morbid reason
for the creation of C#. C++ is too complicated for many programers? Fine,
for those who find the full C++, especially including template perhaps etc.,
too complicated - don't use the full power of it - use only the simpler
portions of it and everybody is happy.
I think that this unnecessary complicated, cumbersome and moving target API
is my main problem. And that is why I was trying "to cling" to .hta. But, as
I wrote originally, that approach may be too good to be true.
