Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Lars

Pages: [1] 2 3 ... 87
1
Applications / Re: Experiment: Moving OS/2 Graphic/MM Resources
« on: July 12, 2024, 07:54:26 pm »
The Mouse Setup object is managed by WPS class "WPMouse". That class is implemented in DLL WPCONFIG.DLL.

If I unpack WPCONFIG.DLL, I find this text string in it:
STARTFOLDER=?:\OS2\POINTERS

It is therefore hard coded and cannot be changed.

Note: The STARTFOLDER is a setup string for the "wpclsFindOneObject" class method of WPObject for the top level folder to search from. So you will only be able to search under that folder.

2
Events / Re: Warpstock Europe 2024 Follow Up
« on: June 20, 2024, 10:34:02 am »
Maybe your system is old enough to foresee use of a 32-bit OS, just like mine that is about 7 years old.
The problem with (many ?) new systems is that they reserve large amounts of physical address space below the 4 GB physical boundary for PCI use (and therefore not for RAM).
I think I read somewhere that this was done for older HW that can only address below the 4GB physical boundary but needs a large memory space, for example older graphics cards with very large screen apertures and memory space to hold textures and the like.
That makes much sense if a 64-bit OS is in use but severly restricts a 32-bit OS that has to rely on that memory space to be (mostly) addressable for RAM.
The reservation of that physical address space is static to cater for a 'worst case'.

3
Applications / Re: RPM Repository: IBM OS/2 Toolkit.
« on: May 24, 2024, 09:51:45 am »
I would not assume exactly the same code. However, I would always prefer the files in \OS2\DLL over those in \OS2TK45\SOM\COMMON\DLL.

People not installing the toolkit (which should be assumed to be the majority) need a working system.


4
Programming / Re: ClassiCube porting thread
« on: May 11, 2024, 09:45:52 am »
AN will answer you that it is not their SW.
The author is Sergey (glassman). The best you can do is find his email address or contact Eugene Gorbunoff who would know how to contact Sergey.

Sorry, meant to say Dmitry (Steklenev) and not Sergey.

Anyway, he has a webpage that also allows contacting him directly, maybe that is easier and also more efficient: https://5nets.ru/

There is a feedback link: https://5nets.ru/feedback/


The difference I found between the initial version of FOC contained in eCS (where it does not crash) and that in ArcaOS (where it crashes):

The install script of eCS forwards the functions "WinFileDlg","WinDefFildDlgProc","WinFreeDlgFileDlgList" from PMCTLS.DLL to PMEX.DLL but it does not "clone" them, so the original routines in PMCTLS.DLL are not accessible anymore. PMEX.DLL in turns calls into FOC.DLL.

ArcaOS on the other hand does not only forward the original functions from PMCTLS.DLL to PMEX.DLL but it also "clones" them to another ordinal so that the original procedures can be called from foc.dll, for example.

That seems to be the difference that makes FOC crash under ArcaOS but work ok under eCS. As I said, I have no probs under eCS and even regedit2.exe works just fine with FOC even though AN puts it on the exclusion list.

5
Programming / Re: ClassiCube porting thread
« on: May 10, 2024, 11:38:25 am »
AN will answer you that it is not their SW.
The author is Sergey (glassman). The best you can do is find his email address or contact Eugene Gorbunoff who would know how to contact Sergey.

6
Programming / Re: ClassiCube porting thread
« on: May 09, 2024, 03:20:15 pm »
As a quick test, back up and replace the files as contained in the ZIP file.
Explanation to follow.

7
Programming / Re: ClassiCube porting thread
« on: May 09, 2024, 11:37:51 am »
Actually, "PMEX.DLL" is dynamically binding to and calling into "FOC.DLL" to do its job and that is part of the "Win" eCosoft runtime.

I am beginning to believe that eCoSoft "win","base","net" runtime has been broken in later versions.

I have 2018.11.8.0 installed for "Net" and "Win" and 2017.11.15.0 for "Base". I do not experience crashes but (after registering the WPS class for FOC configuration, gleaned that from the ArcaOS installation), after setting exception in the FOC exception list, it has no effect/is ignored.

You can find older versions here:
https://en.ecomstation.ru/projects/developer/toolkit/?action=runtime-old


8
Programming / Re: ClassiCube porting thread
« on: May 09, 2024, 09:30:23 am »
What you can also try: deregister class "WPFOCSystem". For that you will need to have full XWorkplace installed. This is the configuration class that adds the "FOC" page to the Workplace Shell configuration object, not the real file dialog replacement.

You can always reregister this class via REXX. For that, have a look at \system\install\foc\filedlgtofocdlg.cmd.
Look for "FOCRegisterWPClass".

Another thought: configure FOC to only scan "local drives" and not "all" (if you haven't done that anyway).

9
Programming / Re: ClassiCube porting thread
« on: May 09, 2024, 09:01:12 am »
Hi Dave,

eCS does not have that "FOC" tab in the Workplace Shell Object ...

By the way: FOC has nothing to do with eCosoft Runtime.
What FOC does is to change PMCTLS.DLL to forward the entry points of these functions:
WinFileDlg
WinDefFileDlgProc
WinFreeFileDlgList

to these functions in PMEX.DLL:
WinExFileDlg (directly replacing WinFileDlg)
WinExDefFileDlgProc (directly replacing WinDefFileDlgProc)
WinExFreeFileDlgList (directly replacing WinFreeFileDlgList)

My PMEX.DLL has this size and file date:
13.04.11   9.31          13.114      0  PMEX.DLL
Unfortunately, it has no buildlevel string and I have no clue where this DLL came from or if it was part of the original eCS installation.

So, my buest guess is that PMEX.DLL has received an update with ArcaOS (apparently, as FOC now offers configuration) and that that update broke the file selection dialog functionality.
I just checked and yes, PMEX.DLL has been updated with ArcaOS.

10
Programming / Re: ClassiCube porting thread
« on: May 08, 2024, 06:48:55 pm »
Yes, DIVE seems to create an additional thread on its own.
On my system, with FOC enabled, nothing crashes. Since I seem to use an outdated version of the eCo Runtime, maybe that is the cure ?

I am still using eCS 2.2 beta. Where do you configure FOC ?

11
General Discussion / Re: smp.inf - Adendum
« on: May 08, 2024, 02:35:51 pm »
There was an updated SMP.INF called "SMP Programming Addendum". I think I have that floating around somewhere and I cannot remember where I got it from.

12
Programming / Re: ClassiCube porting thread
« on: May 08, 2024, 02:33:48 pm »
[..]
On all occasions, the trap does not happen in the main thread. I suspect some problem with the File Dialog obscuring part of the window drawn to by DIVE and the DIVE thread trapping rather than "WinFileDlg". In all cases, it is running out of stack.
Do you mean, Dive itself spins up thread. I myself wait for CC to call me for an update without doing the blit in a thread.

I will need to run the DIVE samples provided with the OS/2 toolkit but I seem to remember that they are running with 3 threads where the app itself only creates 2 threads (the main thread and an additional thread for blitting). If that is true, DIVE itself seemingly is creating its own thread. And I don't know what that additional thread does and what it accesses. Looks like it is calling "WinRequestMutexSem" ...

13
Programming / Re: ClassiCube porting thread
« on: May 08, 2024, 12:27:33 pm »
2) "args->filters" is effectively a PAPSZ pointer, that is, a pointer to an array of pointers where the last pointer in the variable array is a NULL pointer

This is not correct. There is absolutely no indication anywhere in the *OS/2* docs that that 'fileDialog.szFullFile' is anything other than a simple string. If you wanted to filter based on multiple extensions, you do it like this: "*.exe;*.cmd" using a semicolon, not a null, to separate the filters.

Regardless, the most appropriate way to determine whether this is the source of the problem (and I doubt it is) is to make the assignment as simple as possible:  strcpy(fileDialog.szFullFile, "*.*");

Quote
see the example code for the Windows implementation

Not helpful.

I talked about "fileDialog.papszITypeList" and not "fileDialog.szFullFile". Maybe you should first read what I have written before answering.
Anyways, I also doubt that that is a problem.

14
Programming / Re: ClassiCube porting thread
« on: May 08, 2024, 12:23:07 pm »
Actually, there are 3 traps in Davids POPUPLOG.TXT file. And the last two trap screens seem to stem from the very same execution.

Anyway, the file tells us that now we experience traps at 2 different places in PMMERGE.DLL (I'll have to look up the second place). I think that "WinFileDlg" in isolation is not the problem but the interchange with other threads executing (like for example the thread that DIVE spins off, I seem to remember).

On all occasions, the trap does not happen in the main thread. I suspect some problem with the File Dialog obscuring part of the window drawn to by DIVE and the DIVE thread trapping rather than "WinFileDlg". In all cases, it is running out of stack.

15
Programming / Re: ClassiCube porting thread
« on: May 07, 2024, 05:25:08 pm »
1) Since the trap occurs in "WinRequestMutexSem" (which you are apparently not directly calling from anywhere), I suspect it has something to do with calling "WinSetVisibleRegionNotify" before calling "WinFileDlg" and after calling "WinFileDlg". My gut feeling is that it is a problem surrounding the call to "WinFileDlg" with these calls. As a test, I'd remove that

2) "args->filters" is effectively a PAPSZ pointer, that is, a pointer to an array of pointers where the last pointer in the variable array is a NULL pointer, see the example code for the Windows implementation:
Code: [Select]
const char* const* fileExts = args->filters;
...
for (i = 0; fileExts[i]; i++)
{
if (i) String_Append(&filters, ';');
String_Format1(&filters, "*%c", fileExts[i]);
}

That might help in properly setting up the "papszITypeList" of "WinFileDlg". In fact, you should be able to do a:
fileDialog.papszITypeList = (PAPSZ)args->filters;

Pages: [1] 2 3 ... 87