OS/2, eCS & ArcaOS - Technical > Utilities
Executables are not assigned the proper WPS class
Lars:
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 ?
Martin Iturbide:
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
Rich Walsh:
--- Quote from: Lars on August 07, 2025, 08:04:34 am ---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.
--- End quote ---
<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:
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: ---oo /b DANIS506.ADD WPProgramFile
--- End code ---
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: ---oo /+
for %1 in (*.ADD) do oo /b %1 WPProgramFile
oo /-
--- End code ---
Martin Iturbide:
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
Navigation
[0] Message Index
[#] Next page
Go to full version