COM/CGI problems resurface

Hi Blair,

My recent COM/CGI experiments ended when I discovered that Pi3Web would
allow a WinCGI app to make COM calls to my Dolphin apps.

That blissful scenario came to halt yesterday, and I have **no** idea why.
I rebooted, reinstalled the server, tried it as an app, as a service;
nothing worked.  It had been fine just minutes before =:0

A little tweaking gave me a Dolphin WinCGI analogous to the long-running C++
app that was suddenly not able to work.  The error messages were the same as
when I tried COM and CGI under Apache - erroneous (that's my story, and I'm
sticking to it<g>) claims that the class object was not registered.

Fully aware that my long-running C++ solution to the problem was broken, I
looked at its source code to see how it might be different from my first
COM/CGI attempt under Dolphin.  Two things stood out: (1) it uses
CoCreateInstance() vs. a separate class factory step; (2) it specifies local
servers only as the context.  I made those changes to the Dolphin WinCGI,
and suddenly things are working again - I can't explain that either.

It gets better: similar changes allow the COM/CGI to obtain an interface
pointer.  That particular app does not work for other reasons, but that's
not really surprising.  I'm trying something with Win32 events that should
require some debugging.

Could licensing be behind the problems?  Or is there something special about
the separate class factory?  For now, I'm torn between taking advantage of
the opportunity to return to my original problem and trying things under
Apache.


An aside about web servers:
Hopefully the revised CGI (after debugging) or a simpler version will work
under Apache.  I've noticed that Pi3 isn't quite as polished as Apache.
Even without considering the recent incident, Pi3 has obvious problems with
its GUI - applied changes don't always stick, etc.  In constrast, Apache
"just works", though I should mention that I read many reports of problems
installing the latest version????  One thing, in the 2.0 line, watch out for
something like 2.0.39(???) - there's a version with a security hole in it,
and the most recent version fixes it.  There is also a configuration tweak
that can be applied to fix or at least mask the hole for those with reasons
not to install the latest version.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:amako8$o56$[hidden email]...
>
> [..snip discussion of problem cocreating Dolphin COM objects from Pi3Web
and CGI app...]
>
> Could licensing be behind the problems?  Or is there something special
about
> the separate class factory?

I'm not sure, but I would think it is more likely to be to do with the
"context" used. I have also found that there is quite a bad smell emanating
from the COM subsystem on Win9x, and certain failures will leave it in an
inconsistent state such that things that worked before a crash no longer
work after it (an example being stale ROT entries), requiring a reboot.

It may be that your COM/CGI app. is registering as supporting in-process
activation for some reason (i.e. it has an InProcServer32 entry), or that
you have such a registration left over from debugging (the Dolphin dev. env.
will do that as the default), so the problem may be as simple as a duff
registry entry.

Regards

Blair

Blair,

> I'm not sure, but I would think it is more likely to be to do with the
> "context" used. I have also found that there is quite a bad smell
emanating
> from the COM subsystem on Win9x, and certain failures will leave it in an
> inconsistent state such that things that worked before a crash no longer
> work after it (an example being stale ROT entries), requiring a reboot.

If I were using 9x, this wouldn't be a problem :)   One of the unpleasant
surprises on win2k was that the web server I used for testing turned out not
to be able to run, at least not entirely.  The price was right (it was a
free teaser for the commercial server we use) and was a big help.  It's so
old that rather than digging for possible workarounds, it seemed reasonable
to find something that was being actively developed.  One look at the Win32
Apache convinced me.  Then the WinCGI issue turned up.  I couldn't do what I
needed from an ordinary CGI under Aapache, etc.

After the tweaks that really shouldn't have fixed anything, it broke again.
The frustration factor was sufficiently high that I wrote an embedded web
server.  It cheats on the WinCGI protocol, but the browser doesn't seem to
know the difference.  This is not something that I'd do in production
because I don't feel like writing my own secure server (and no doubt get it
wrong).  Obviously, running a home-brew web server when connected to the
real world is dangerous.  At least I have a debugging solution for isolated
machines, and since I know what static pages I intend to serve and run only
one type of dynamic content, I can limit the risk by refusing anything that
doesn't look right.

Back to COM, does CoRegisterClassFactory() produce a ROT entry?  My limited
reading on the subject suggests that it's mostly about objects with
elaborate monikers.  If there should be an entry, then I'll try the ROT
viewer or maybe write a Dolphin goodie for the purpose.  The last time I had
a problem like this , the ROT viewer I had was no help.  Of course, that
would have been under 9x, and the real problem might have been the smell you
noticed :)


> It may be that your COM/CGI app. is registering as supporting in-process
> activation for some reason (i.e. it has an InProcServer32 entry), or that
> you have such a registration left over from debugging (the Dolphin dev.
env.
> will do that as the default), so the problem may be as simple as a duff
> registry entry.

Interesting idea.  Would that override the class factory that's registered
at server startup?

I'm still stumped, but this is starting to look like either a random bug in
MS security and/or licensing, or that some sequence of events causes Pi3 to
run the WinCGI as either a more or less powerful user than expected.

I haven't decided against FastCGI, but that's not a trivial move, and I'd
prefer to use an ordinary CGI if that can work.  If I'm going to have to do
lots of work, I'd rather get the most generic result possible.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]