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
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.

2
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.

3
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.

4
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


5
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).

6
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.

7
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 ?

8
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.

9
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" ...

10
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.

11
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.

12
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;

13
Programming / Re: ClassiCube porting thread
« on: May 07, 2024, 08:57:46 am »
As Steve has already mentioned, the trap is due to a stack error.
Your app is trying to push a DWORD to mem address 0x0464fffc but the lower limit for the stack obviously is 0x04650000 (that is where ESP points to on occurence of the trap). It also does not look like your code (at least the invocation of the function in PMMERGE.DLL which is the "Win32RequestMutexSem" function I seem to remember) is being called from the main thread because TID=000a (it should be TID=0001 for the main thread).

You say that the provided stack is big enough.
The only remaining thing I can think of is that you are overwriting your stack (with EBP being overwritten with a bogus value before it is being popped or assigned to ESP). Or some recursion happens.

You will need to create a process dump and have a look at that. That should allow you to detect a recursion.

14
Programming / Re: ClassiCube porting thread
« on: May 06, 2024, 06:56:38 pm »
1) Are you making sure that you are passing a fully qualified filename to fileDialog.szFullFile ?
2) is *(args->filters) the correct pointer or rather (args->filters) ? Shouldn't you copy with strcpy rather than memcpy ?


Since I have zero problems using the eCosoft runtime functions, regardless of application:

3) have you installed the latest version of the eCo Software "Win" and "Base" runtime ? I have version 2017.11.15.0 and 2018.11.8.0 installed, respectively. I think these should be the newest versions.

15
Programming / Re: ClassiCube porting thread
« on: May 06, 2024, 01:14:23 pm »
In addition, in your latest checkin you also do this (without telling us):

fileDialog.fl = FDS_HELPBUTTON | FDS_CENTER | FDS_PRELOAD_VOLINFO | FDS_OPEN_DIALOG;
fileDialog.pfnDlgProc = WinDefFileDlgProc;

The latter is completely unnecessary as you are not providing your own file dialog window procedure anyway.

But what's more, if you use FDS_PRELOAD_VOLINFO, it is your responsibility to allocate and also manage memory for
fileDialog.papszIDriveList (read further info of how the table needs to look like in the explanation for this field).

At least that is what I would try out to check if it makes a difference.

Pages: [1] 2 3 ... 87