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:
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);
}