#179 No GUID put into Windows registry for WSH

pending
nobody
WSH (6)
5
2014-08-24
2006-08-29
Terry
No

In short the problem is that ooRexx 3.1 is "not putting
its GUID into the registry (as scripting engines are
supposed to do)" for WSH.

I have pasted portions of emails to/from the RexxLa
forum below for a more detailed explanation.

My email to RexxLa:

I am using Windows XP sp2 and ooRexx 3.1.

I use 4Nt from JP Software.

The current problem has to do with running ooRexx
under the Windows Scripting Host (WSH).

I have been using a command line like the following
for some time now using 4Nt ver 7.

 cscript.exe //e:"Object Rexx" //NoLogo wsh.rex

I just played with 4Nt 8 beta. Ver 8 has a new
"script" command that should make working with ooRexx
under WSH a bit easier. I ran into a problem. I
reported the problem to Rex Conn, the main developer at
JP Software. I have pasted, below, the pertinent part
of his reply -- part of my email to him quoted first
and then his reply.

     If I enter the following command line:
          script /e"Object Rexx" Wsh.rexh
     then I get the following error:
          Error (SYS): Invalid class string

Rex Conn's reply to me (my original email to him):

 The problem is actually with Object Rexx; it's not

putting its GUID into the registry (as scripting
engines are supposed to do). Instead, it's relying on
the GUID being embedded in XML code that CSCRIPT parses
to find the script code. (4NT & SCRIPT do not support
the XML code parsing; they expect to simply find the
executable code in the file.)

My question to RexxLa forum:

Is Rex Conn correct that ooRexx should be putting
its GUID into the registry and is he accurate that
ooRexx does not so do?

Mark Hessling's reply to me:

Yes, Rex is probably correct. ooRexx does not add any
GUIDs to the registry for the WSH Engine.
Please raise a bug report on SourceForge.

Cheers, Mark

Discussion

  • Mark Miesfeld

    Mark Miesfeld - 2006-08-30

    Logged In: YES
    user_id=191588

    Mark Hessling,

    I looked into this a little bit. Even though, in the
    install, ooRexx does not add any GUIDs to the registry,
    they are there.

    I'm still in the learning state with this, but, I believe
    the Object Rexx Script engine is a "self-registering" COM
    object.

    The ooRexx script engine GUID is: 13DAD011-B0C9-11D4-A829-
    000629869785. This is defined in:
    oorexx\platform\windows\orxscrpt\guids.hpp in the source.
    If you search for this in the registry you will find it.
    It is possible that you may need to actually run one of
    the samples that uses the ooRexx script engine before the
    entries get put in.

    I installed ActiveState Perl, so I could compare the
    entries for PerlScript (which I know work from searching
    the web) and compared them to the ooRexx entries. I'll
    attach a zip file containing the ooRexx entries and the
    PerlScript entries.

    Basically, they look correct to me. ooRexx seems to have
    all the same keys, etc. The only thing I see is that
    under the CLSID entry, ooRexx is using 'Object Rexx' as
    the progid. I don't think it is allowed to have a space
    in the ID. (But, again I'm not 100% sure I understand the
    docs on OLE Automtation.)

    It could be that taking out the space would fix this - if
    it even is a real bug. Maybe Terry can report this back
    to JP Software and see what they say.

    I'll be happy to add this to the things I am looking
    into. I can try taking out the space and recompiling the
    orxscrpt DLL, if Terry is willing to try it to see if it
    changes anything.

     
  • Mark Miesfeld

    Mark Miesfeld - 2006-08-30

    Logged In: YES
    user_id=191588

    Well, looks like I can't attach a file. Send me an e-mail
    if you would like to look at the registry entries I saved.

     
  • Terry

    Terry - 2006-08-31

    Logged In: YES
    user_id=1256161

    Mark Miesfeld,

    I looked at my registry entries, so no need to send them to me.

    You wrote "I can try taking out the space and recompiling the
    orxscrpt DLL, if Terry is willing to try it to see if it
    changes anything."

    Of course I will be glad to test the altered orxscrpt.dll to
    see if it fixes anything.

    After I respond here, I am sending some of your comments to
    Rex Conn to see what he says and perhaps to get a bit more
    info from him about what he thinks we need to do.

     
  • Philippe Majerus

    Logged In: YES
    user_id=1655860
    Originator: NO

    The Object Rexx ActiveScript engine is correctly registered on my system during the installation (ooRexx 3.1.1 MT on WinXP SP2).
    However, WSH and some other script utilities uses an extra registration to find out which script engine to use for a specified file, so that the user doesn't have to specify both the filename and the engine to use.
    Note this is an extra feature for WSH, not a required feature for Active Scripting.

    .rex files are type REXXScript, found in \HKCR\REXXScript\ Adding a ScriptEngine\ subkey with a REG_SZ default value set to "Object Rexx" (without the quotes) will make it possible to use cscript and wscript without specifying the /e:"Object Rexx" argument, as they will then be able to find it out from the file name.

    You can test this feature by saving the following as "WSH ooRex fix.reg" and importing it in your registry:

    [HKEY_CLASSES_ROOT\REXXScript\ScriptEngine]
    @="Object Rexx"


    This could be included in orxscrpt.dll self-registration code, or added to the general installer.

     
  • Mark Hessling

    Mark Hessling - 2007-04-08

    Logged In: YES
    user_id=86185
    Originator: NO

    Mark M. You probably have a better chance of fixing this than me :-) Mark H.

     
  • Mark Miesfeld

    Mark Miesfeld - 2007-10-04

    Logged In: YES
    user_id=191588
    Originator: NO

    Rick and David

    In essence, this is not a bug, the proper entries to the registry are made. I have left this open for so long, because there is one thing that the orignal developers did, that I wish they hadn't: They added the completely spurious "Object Rexx" entry.

    What I'd like to do is close this bug and open a feature request to still track this item. Maybe there is some clean up we can do in this area. If you have the time to read through my lengthy explanation below, you could let me know what you think.

    The bottom line is, if you read through it all: ObjectRexxScript should be used when working with the ooRexx Active script engine, not "Object Rexx" The .rxs extension should be used when working with Active Scripting, not .rex. In this area, ooRexx exactly follows Perl and TclTk, and other scripting languages that work with Active Scripting. The "Object Rexx" entry in the registry should never have been made.

    I would like to just remove the "Object Rexx" entry, but all the samples used that, rather than the correct ObjectRexxScript. The ObjectRexxScript registry values are all set, and all set correctly. You just should never use "Object Rexx". But, if we remove that entry, I'm sure that there is a lot of stuff out there using "Object Rexx" that people would have to change. Here is the explanation:

    All the proper registry entries, including the GUID are put into the registry during the
    ooRexx install.

    ooRexx install program automatically registers on line: 156 (line number may have changed since I first wrote this, but the line itself is in the install.)

    !insertmacro InstallLib REGDLL NOTSHARED REBOOT_PROTECTED "${BINDIR}\orxscrpt.dll" "$INSTDIR\orxscrpt.dll" "$INSTDIR"

    The registration is done by calling DllRegisterServer() in dllfuncs.cpp. This
    in turn invokes OrxClassFactory::RegisterServer() from classfactory.cpp.

    The regsistry values are in guids.hpp.

    ====================================

    Compare ooRexx to Perl:

    Perl

    ftype:

    Perl="D:\Interpreters\Perl\bin\perl.exe" "%1" %
    PerlScriptFile=C:\WINDOWS\System32\WScript.exe "%1" %

    assoc:

    .pl=Perl
    .pls=PerlScriptFile

    ooRexx

    ftype:
    REXXScript="D:\Interpreters\Rexx\ooRexx\rexx.exe" "%1" %
    ObjectRexxScriptFile=%SystemRoot%\System32\WScript.exe "%1" %

    assoc:
    .REX=REXXScript
    .RXS=ObjectRexxScriptFile

    Perl has:

    Perl <- For the Perl interpreter
    PerlScript <- For the ActiveScript engine
    PerlScriptFile <- For the ActiveScript engine file

    ooRexx has:

    RexxScript <- For the ooRexx interpreter
    ObjectRexxScript <- For the ActiveScript engine
    ObjectRexxScriptFile <- For the ActiveScript engine file

    Plus an extra -

    Object Rexx <- For the ActiveScript engine. What a mistake this
    was !

    I have some registry picture files showing this, but they seem to be too big to attach.

     
  • Rick McGuire

    Rick McGuire - 2007-10-04

    Logged In: YES
    user_id=1125291
    Originator: NO

    I'd say as a first step, we should correct all of the examples so it's preferred usage. Then, some time in the future (length yet to be determined), quietly make the non-preferred version go away.

     
  • Mark Miesfeld

    Mark Miesfeld - 2007-10-04

    Logged In: YES
    user_id=191588
    Originator: NO

    Rick, as always good advice. I'll leave this as is now and work on correcting the examples.

     
  • David Ashley

    David Ashley - 2007-10-04

    Logged In: YES
    user_id=931756
    Originator: NO

    I agree with Rick on this one. Unfortunately we inherited this problem from the original IBM code. We just have to make the best of it until we properly document the correct procedure and slowly ween user of the old procedure.

     
  • Philippe Majerus

    Logged In: YES
    user_id=1655860
    Originator: NO

    ObjectRexxScript and .rxs files seems to be correctly registered except for one thing (in 3.1.2):
    [HKCR\ObjectRexxScriptFile\ScriptEngine]
    @="Object Rexx"
    This means if you remove the "Object Rexx" ProgID for the script engine, even your own .rxs files will not work anymore, as they are also using the wrong engine name. This could be fixed easily, but really needs to be fixed before removing the old ProgID.

    Also, the following entry is wrong (in 3.1.2):
    [HKLM\CLSID{13DAD011-B0C9-11D4-A829-000629869785}\ProgID]
    @="Object Rexx"
    This means the real ProgID of the engine is "Object Rexx" and "OpenObjectRexx" is just an alias ProgID to the same ClassID.
    Because of this, programs enumerating script engines on a system (searching for COM classes that implements IActiveScript) receive the "Object Rexx" name, and don't notice the "ObjectRexxScript" ProgID.
    I suggest this gets changed to "ObjectRexxScript" too.

    I would say for the sake of backward compatibility, the old ProgID needs to stay there, but definitely needs to be dropped from all the documentation except for the page explaining it's deprecated and suggesting to move to "ObjectRexxScript".

    If you really want to remove the old ProgID, I would make a few suggestion:

    Something to ease the transition might be to make the "Object Rexx" ProgID deprecated, so that the documentation still contains it but suggest moving to "ObjectRexxScript" instead, this will be a great help when people will notice their old script don't work anymore and search for information on the old ProgID.

    A solution that involves some more work but would really help users, would be to register "Object Rexx" using a new ClassID, then in OrxClassFactory, when you see a request for that ClassID, show some warning explaining that whatever software just called that object should be updated to the new ProgID, and then instanciate the same class as ObjectRexxScript. This would avoid user's confusion the day you decide to completely delete the old ProgID.

     
  • Mark Miesfeld

    Mark Miesfeld - 2007-10-04

    Logged In: YES
    user_id=191588
    Originator: NO

    Philippe,

    Thanks for that detailed post. It really helps, so that I don't need to spend so much time researching the little nuances.

    "A solution that involves some more work but would really help users, would
    be to .."

    I like this idea. Thanks. I don't mind doing work when what needs to be done is spelled out. <grin>

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-08-17

    Windows Scripting Host (WSH) has been temporarily disabled in ooRexx 4.0.0. The WSH implementation code is not compatible with the refactored interpreter and needs to be completely rewritten. The old code used undocemented, unsafe, APIs. Those APIs no longer exist.

    The WSH bugs are bugs in the old code. The old code is not going to be used, so technically, the bugs are not going to be fixed.

    This bug will put into the postponed state and used to ensure that this type of bug does not exist in the re-written WSH support. At that time it will be closed.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks