Author Topic: Executables are not assigned the proper WPS class  (Read 506 times)

Lars

  • Hero Member
  • *****
  • Posts: 1452
  • Karma: +73/-0
    • View Profile
Executables are not assigned the proper WPS class
« on: August 07, 2025, 08:04:34 am »
I have XWorkplace 1.0.17 installed.

Under the WPS, for many but not all executables (that is: .EXE and .DLL files, possibly others like .ADD, .DMD etc ?), these are not assigned the proper WPS class (X)WPProgramFile. Instead, they are assigned class (X)WPDataFile.

The effect is that I cannot start an executable by double clicking on it. Additionally, I cannot see the "Module" page that gives info about the executable module (XWP extension for XWPProgramFile objects).

This is true, even if these files are marked with file type "Executable" in which case I am still not able to select the (X)WPProgramFile class from the "Become" page in the settings notebook.

1) How can I fix this problem in general ? The "Workplace shell" object allows to assign applications to file types but for this case this does not help.

2) How can I manually fix this for the already existing objects that should be of WPS class "XWPProgramFile" but they are not ?

« Last Edit: August 07, 2025, 08:11:42 am by Lars »

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5418
  • Karma: +48/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Executables are not assigned the proper WPS class
« Reply #1 on: August 07, 2025, 05:10:22 pm »
Hello Lars

I wanted to understand the problem better, so I tried to see it in my VM.

I took CPU.EXE (Picture attached) and it is fine, it registered as "WPPngPProgram" class, it shows the "Module" tab and it executes when you double click it.

I tried to look for other .EXE with a different class registered and I was not able to found those. And If change a .exe to "WPDataFile" under the "Became" tab, I can return it back. I have no idea how to change the "Class" in batch for several files.

In the case of "Drivers" (Picture attached), I found no way to change it to "WPPngPProgram" on the "Became" tab. I would like to see the "Module" tab on a driver, but I'm not sure if "WPPngPProgram" will be the right class. I'm open to suggestions here. This also applies  with DLL files.

Extra doubt: Should the tab "Became" (simple past tense form of the irregular verb "become") a good name for that tab? Maybe it should be "Class", I don't know. But verbs are not used for the rest tabs like (Type, Icon, File, Menu) (Nouns)

Sorry, I have no answer, but I share your same doubts with this subject.

Regards

« Last Edit: August 07, 2025, 05:12:45 pm by Martin Iturbide »
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Rich Walsh

  • Sr. Member
  • ****
  • Posts: 413
  • Karma: +30/-0
  • ONU! (OS/2 is NOT Unix!)
    • View Profile
Re: Executables are not assigned the proper WPS class
« Reply #2 on: August 07, 2025, 05:18:54 pm »
Under the WPS, for many but not all executables (that is: .EXE and .DLL files, possibly others like .ADD, .DMD etc ?), these are not assigned the proper WPS class (X)WPProgramFile. Instead, they are assigned class (X)WPDataFile.

<short answer>
This may be the result of a long-time bug in XWP that I fixed in 1.0.17.  The quick fix is to delete these files' .CLASSINFO EA then restart the Desktop.

<long answer>
WPS classes can specify which file extensions they're associated with - but WPProgramFile does not specify anything. This lets some internal WPS logic decide what class these files should be. XWPProgramFile broke this by specifying "*.COM,*.EXE", causing some binaries to be mis-classified. Manipulating the file in the WPS - for example, by opening its notebook - locked the error in place by forcing a .CLASSINFO EA to be written for that file.

AFAICT, the internal logic for binaries applies to .EXE .COM .and .DLL only. Other binaries are taken to be WPDataFiles unless they have a .TYPE EA of "Executable" (most likely put there by the linker).

So... for any binary with the wrong class (easily identified by its icon), delete its .CLASSINFO EA. For binaries that would otherwise be identified as WPDataFile, add an "Executable" .TYPE EA. For best results, keep the WPS folder containing these files closed, and work from the commandline or a GUI app to make changes, then restart the WPS.

Rich Walsh

  • Sr. Member
  • ****
  • Posts: 413
  • Karma: +30/-0
  • ONU! (OS/2 is NOT Unix!)
    • View Profile
Re: Executables are not assigned the proper WPS class
« Reply #3 on: August 07, 2025, 11:18:20 pm »
As an alternative to deleting EAs and setting file types, you can use the attached copy of 'oo' which supports a "Become" (/b) option. For example:
Code: [Select]
oo /b DANIS506.ADD WPProgramFile

If you plan to execute this in a loop to change multiple files, bracket your loop with "oo /+" and "oo /-" to lock the RWS08 class in memory so it doesn't have to be reloaded on each call. Example:
Code: [Select]
oo /+
for %1 in (*.ADD) do oo /b %1 WPProgramFile
oo /-

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 5418
  • Karma: +48/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Executables are not assigned the proper WPS class
« Reply #4 on: August 08, 2025, 12:11:05 am »
Thanks Rick

Here oo worked fine and I changed the DLLs to WPProgramFile without issues.

I also used FT.CMD to change the "Type" from "Executable" to "Dynamic Link Library" on the DLLs.  Does this impact in a negative way to the .INI file size? I think I was told that some time ago that.

Regards
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Lars

  • Hero Member
  • *****
  • Posts: 1452
  • Karma: +73/-0
    • View Profile
Re: Executables are not assigned the proper WPS class
« Reply #5 on: August 08, 2025, 12:13:10 pm »
Under the WPS, for many but not all executables (that is: .EXE and .DLL files, possibly others like .ADD, .DMD etc ?), these are not assigned the proper WPS class (X)WPProgramFile. Instead, they are assigned class (X)WPDataFile.

<short answer>
This may be the result of a long-time bug in XWP that I fixed in 1.0.17.  The quick fix is to delete these files' .CLASSINFO EA then restart the Desktop.

<long answer>
WPS classes can specify which file extensions they're associated with - but WPProgramFile does not specify anything. This lets some internal WPS logic decide what class these files should be. XWPProgramFile broke this by specifying "*.COM,*.EXE", causing some binaries to be mis-classified. Manipulating the file in the WPS - for example, by opening its notebook - locked the error in place by forcing a .CLASSINFO EA to be written for that file.

AFAICT, the internal logic for binaries applies to .EXE .COM .and .DLL only. Other binaries are taken to be WPDataFiles unless they have a .TYPE EA of "Executable" (most likely put there by the linker).

So... for any binary with the wrong class (easily identified by its icon), delete its .CLASSINFO EA. For binaries that would otherwise be identified as WPDataFile, add an "Executable" .TYPE EA. For best results, keep the WPS folder containing these files closed, and work from the commandline or a GUI app to make changes, then restart the WPS.

Hi Rich,

thanks for the explanation. That also explains why this issue popped up with installing XWP 1.0.17.

I'll go and delete the .CLASSINFO EAs. I just now need to find David's specialized EA deletion tool so that I do not delete all EAs ...
Or better: I use your updated version of oo (which I already have).

One question remains: under XWP 1.0.17, I recently unzipped a file containing an executable (with a .EXE file extension). The unzipped executable still was not classfied correctly. How can that happen ? Will Unzip also unzip EAs ?

I also had a look at your change regarding XWPProgramFile::wpclsQueryInstanceFilter.

Ulrich mentions a problem when "Turbo Folders" is enabled. Maybe the code in xwppgmf.c can work around it this way:

Code: [Select]
SOM_Scope PSZ  SOMLINK xpgfM_wpclsQueryInstanceFilter(M_XWPProgramFile *somSelf)
{
    /* M_XWPProgramFileData *somThis = M_XWPProgramFileGetData(somSelf); */
    M_XWPProgramFileMethodDebug("M_XWPProgramFile","xpgfM_wpclsQueryInstanceFilter");

    if (0 == strcmpi(_somGetName(somSelf),"XWPProgramFile") /* compare the actual class name against the desired class to avoid changes on replacement class objects */
    {
#ifndef __NOICONREPLACEMENTS__
        if (cmnQuerySetting(sfIconReplacements))
            return (PSZ)G_pcszPgmFileFilter;
#endif

        return "*.COM,*.EXE";
        // the below code doesn't work: there is no wpclsQueryInstanceFilter
        // method in WPProgramFile. Apparently the WPS uses some internal hack
        // to explicitly make COM and EXE files program files, but this won't
        // work if turbo folders are enabled, so set this explicitly.
        // V0.9.16 (2001-11-25) [umoeller]
    }
    return M_XWPProgramFile_parent_M_WPProgramFile_wpclsQueryInstanceFilter(somSelf);
}
« Last Edit: August 08, 2025, 06:49:06 pm by Lars »