Registry free COM for VBScript Clients
Peter Olcott
--
100% Accurate Display Screen OCR
http://www.OCR4Screen.com
Mayayana
| --
By "VBScript client" you mean a running .vbs file?
"Client" is usually used in some kind of interactive
situation, like a server and webpage.
I realize that you're trying to protect your ideas in
these posts, but the posts sure are hard to answer. In
general it sounds like you've chosen the wrong tool
in using script. On top of that you're providing minimal
information while often using terminology that's
inapproriate/vague/superfluous, in an apparent effort
to make it sound more official.
I also wonder if you understand the landscape. You're
talking about using an interpreted language, but it
sounds like what you really mean is that your end-users
will use an interpreted language. You seem to want
it free -- you don't want to buy anything to do this
project. But you want to write ActiveX libraries. But
you don't want dependencies. And you're very secretive
about your code, but you're talking about writing your
libraries in either VBScript or C#.Net. Neither of those
will hide your code because they're not compiled. And
probably neither is the answer you need, anyway. VBScript
components are probably not appropriate, and .Net has
hundreds of MB worth of dependencies.
So now you want RegFree Com for a running script,
so that your .Net components won't have to be
registered (even though people may need to download
hundreds of MB worth of .Net Framework files, anyway)?
What's the problem with installing this software? Now
that it requires .Net it's not going to run "out of the box".
If you install it you can register the COM libraries.
I don't know for sure, but it seems very unlikely that
you can get RegFree COM for libraries loaded by a VBScript.
You need a manifest, which means the manifest
would need to be in the same location as wscript.exe.
But why would Windows look for a manifest when
launching wscript.exe? And even if it did, wscript.exe
would have to be designed to adapt to that, adding
the object to the scope of all scripts it runs, rather
than to the scope of its own process. That means
that wscript would have had to have been rewritten
since regfree COM came in circa XP. And since RegFree
COM is really not relevant for VBScript, that wouldn't
have made much sense.
Stefan Kanthak
> How can I do registry free COM for VBScript clients?
Instanciate the COM object via GetObject() and reference it by its
DLL-pathname.
Stefan
Mayayana
| > How can I do registry free COM for VBScript clients?
|
| Instanciate the COM object via GetObject() and reference it by its
| DLL-pathname.
|
loading libraries, since he already posted about
doing it with WSCs.
If you have a method for that I'd like to see
it. It doesn't seem to work for me to do anything
like:
Set fso = WScript.GetObject("c:\windows\system32\scrrun.dll",
"Scripting.filesystemobject")
(And that's a registered class.)
Peter Olcott
> |
> |> How can I do registry free COM for VBScript clients?
> |
> | Instanciate the COM object via GetObject() and reference it by its
> | DLL-pathname.
> |
> I think he's talking about real RegFree COM,
> loading libraries, since he already posted about
> doing it with WSCs.
>
Not quite. I am talking about a VBScript using a COM component written
in C++ without this component being registered. I thought that I read
something about this being possible if {the script interpreter, the
script, and the COM component} were all in the same directory.
> If you have a method for that I'd like to see
> it. It doesn't seem to work for me to do anything
> like:
>
> Set fso = WScript.GetObject("c:\windows\system32\scrrun.dll",
> "Scripting.filesystemobject")
>
> (And that's a registered class.)
>
>
Peter Olcott
> | How can I do registry free COM for VBScript clients?
> | --
>
> By "VBScript client" you mean a running .vbs file?
> "Client" is usually used in some kind of interactive
> situation, like a server and webpage.
>
The COM component will be written in C++. The user of the COM component
could be any computer language including scripting languages, .NET
languages, regular VB, C++. Basically any language that can use a COM
component. The least powerful of these languages are the scripting
languages. VBScript is a scripting language. I would prefer that every
language be able to use my COM DLL written in C++ to do so registry
free. The scripting languages are the ones that I could not yet find a
way to make registry free use of COM.
> I realize that you're trying to protect your ideas in
> these posts, but the posts sure are hard to answer. In
> general it sounds like you've chosen the wrong tool
> in using script. On top of that you're providing minimal
> information while often using terminology that's
> inapproriate/vague/superfluous, in an apparent effort
> to make it sound more official.
In this case providing a generic problem where the details are moot.
Also I am working on two distinctly different problems. This issue is
related to a problem that I have not yet discussed so any assumptions
based on my prior discussions would not apply.
> I don't know for sure, but it seems very unlikely that
> you can get RegFree COM for libraries loaded by a VBScript.
> You need a manifest, which means the manifest
> would need to be in the same location as wscript.exe.
> But why would Windows look for a manifest when
> launching wscript.exe? And even if it did, wscript.exe
> would have to be designed to adapt to that, adding
> the object to the scope of all scripts it runs, rather
> than to the scope of its own process. That means
> that wscript would have had to have been rewritten
> since regfree COM came in circa XP. And since RegFree
> COM is really not relevant for VBScript, that wouldn't
> have made much sense.
I thought that I read the reg-free COM would work if the script, the
interpreter, and the COM component were all in the same directory.
Mayayana
| > I think he's talking about real RegFree COM,
| > loading libraries, since he already posted about
| > doing it with WSCs.
| >
|
| Not quite. I am talking about a VBScript using a COM component written
| in C++ without this component being registered.
Yes. That's what I meant by "real" RegFree COM,
as opposed to RegFree WSC operation. The former
enables EXEs to load COM libraries (on XP+) in the
same folder by including a manifest file or a manifest
in the EXE resource table. The WSC RegFree is using
the script: moniker to load something that's not a COM
library in the first place. It's just a script file. The concept
of WSC RegFree is actually rather silly. First there's
the ability to register script code files with COM, so that
one doesn't need to know the path to them. If that were
not silly enough, one can use "RegFree COM" to load that
file without needing to deal with COM reg., if one knows
the path to the file. :)
| I thought that I read
| something about this being possible if {the script interpreter, the
| script, and the COM component} were all in the same directory.
|
...So what you need is an interpreter EXE that checks
for a manifest. I did some searching and found a post
someplace where people were talking about HTAs. They
seemed to be saying that one could do RegFree COM
for HTAs in XP but that a different approach is required
in Vista/7 because those systems don't look for a manifest
for mshta.exe.
It sounds like a longshot. And it means you'll need to
write/edit a manifest for wscript.exe. Plus you'll have
to put all of your files into system32 and create some kind
of shortcut to them. All that doesn't seem
to fit very well with your plan to create a tool with no
dependencies and no install required. But you can always
try it out. If you Google manifests you'll find the details
you need for that.