Messages

1

Programming / Re: Development Help with INF2Html

« on: May 13, 2024, 08:24:35 am »

The generated HTML for the lists is completely wrong. You don't put <ul> inside <ul>.
You have to do something like the following:

Code: [Select]

<ul>
  <li>WC_BUTTON<br/>
Consists of buttons and boxes that the operator can select by clicking the pointing device or using the keyboard. These messages are described in <a href="...">Button Control Window Processing.</a>
  </li>
...
</ul>
you can also try to wrap the explanation in <p> making it its own paragraph, then you don't need the <br/>. But I  don't know ATM how that would look.

2

Programming / Re: ClassiCube porting thread

« on: May 10, 2024, 02:39:02 pm »

I will create a ticket next week, as I'm away doing other retro stuff.

3

Programming / Re: ClassiCube porting thread

« on: May 08, 2024, 02:01:34 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.

One more data point, I could get, was, that when call WinFileDlg directly after WinCreateMsgQueue, the dialog stays up (without showing any files), but after that CC can't create any (p)threads, and so stops.
Something is really screwing up the memory.

FOC DNU list is less than ideal, but could be a solution.

4

Programming / Re: ClassiCube porting thread

« on: May 08, 2024, 08:47:43 am »

I have attached a new executablewith my most recent version.
Can somebody with the eCoSoft runtime installed, please test it.
Please start a single player game, then press ESC. In the menu, please click on "Load Map", and then on "Load File".
If everything works, and you exit, the application will put up a crash message. I don't have investigated that.

5

Programming / Re: ClassiCube porting thread

« on: May 08, 2024, 07:14:57 am »

This is not correct.

Actually, Lars is correct. 'args' is the setup struct from ClassiCube, and filters is an array of pointers (more acurate a pointer to pointer )

@Rich: Thanks all the same, anyone thinking about the problem could be bringing us nearer to the problem. And yes, you are correct, copying a simple string to fileDialog.szFullFile is a better solution, but I verified this already

6

Programming / Re: ClassiCube porting thread

« on: May 08, 2024, 07:06:23 am »

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

I added these calls just recently. With or without them the app crashes.

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:
[..]

You are correct, but that's why I did '*(args->filter)' which let's me copy the first string to fileDialog.szFullFile. Also, I have used 'char szFullFile[CCHMAXATH] = "*.*"', and copied it to fileDialog.szFullFile. The app still crashes.

I suspect, that thread 0a from the popuplog is spinned up by the dialog, since it's always the last one, as per process dump.

7

Programming / Re: ClassiCube porting thread

« on: May 07, 2024, 09:35:17 am »

@Lars: Thank you for your persistence.
I don't why it's crashinh in a thread. CC spins of some threads for the background music and the resource HTTP fetch, but the WinFileDlg call happens in the main game loop, which runs on the main thread. IDebug tells me that, too.
I pushed the most recent changes to Github, so if somebody wants to look at the thing...
I will try to create a process dump, and post it.

8

Programming / Re: ClassiCube porting thread

« on: May 06, 2024, 08:13:56 pm »

Yes, installed the newest runtimes.
szFullFile can be *.ext, and yes

Code: [Select]

*(args->filters) is correct.
strcpy vs memcpy doesn’t matter. I tried alle combinations. I also tried

Code: [Select]

char filter[CCHMAXPATJ]=„*.*“, but it doesn’t matter.

9

Programming / Re: ClassiCube porting thread

« on: May 06, 2024, 03:20:16 pm »

Another problem, I can't solve, is that the eCosoft Runtime's file dialog crash with the following code

Code: [Select]

FILEDLG fileDialog;
HWND hDialog;

memset(&fileDialog, 0, sizeof(FILEDLG));
fileDialog.cbSize = sizeof(FILEDLG);
fileDialog.fl = FDS_HELPBUTTON | FDS_CENTER | FDS_OPEN_DIALOG;
fileDialog.pszTitle = (PSZ)args->description;

memcpy(fileDialog.szFullFile, *(args->filters), CCHMAXPATH);
hDialog = WinFileDlg(HWND_DESKTOP, hwndFrame, &fileDialog);
if (fileDialog.lReturn == DID_OK) {
}
I uninstalled the runtimes. Nothing crashes, everything is fine. I reinstalled the newest runtime. The apps crashes again.
Other apps, like EPM, have no problems. I also replicated the example for WinFileDlg, but it's all the same.
My popup log is attached.

1) are you sure that args->description will be a valid address across the call to WinFileDlg ?
2) What did you set fileDialog.pszOKButton to ?
3) What did you set fileDialog.pszlDrive to ?

In particular for the latter, the doc does not say that you can set it to a NULL pointer. Even if the code example implies differently. And even if the default dialog procedure gracefully handles NULL pointers for certain arguments, then the eCosoft runtime dialog procedure override might not.

1.) Yes, because WinFileDlg does not return, until you close the dialog. All samples would not work with local variables. Also, I tested that code with a local variable in a different script program and there it works, even without explicitely setting 2.) + 3.)

10

Programming / Re: ClassiCube porting thread

« on: May 06, 2024, 03:09:28 pm »

Sure, I didn't tell you, because it's not used anymore. You quoted the code snippet, that's what I'm working with.

11

Programming / Re: ClassiCube porting thread

« on: May 06, 2024, 09:33:57 am »

Exception codes are documented in the OS/2 Debugging Handbook (sg244640.inf) and the Control Program Guide and Reference (GPG&R)

Both annotate the value differently.  Given c0000005, you need to search for 0c0000005h in the Debugging Handbook and for 0xc0000005 in the CPG&R.

As Dave noted, you need to expand the per thread stack for TID 0xa.  You can use LIBC_THREAD_MIN_STACK_SIZE to set the minimum at runtime or, assuming that ClassiCube is using pthreads, you can adjust the compile time values by modifying the code that eventually invokes pthread_attr_setstacksize()

Note that while you can get stack overflow if the stack is too small, you can also get stack overflow if the code recurses unexpectedly.  A popuplog is typically not going to tell why the stack overflow happened.  This requires an exceptq report or a process dump file.

BTW, are your sources available anywhere?

Well, here we go. I knew, I was missing something, like that app stack is not thread stack.
Yes, I use pthreads at the moment, and I saw that ClassiCubes implementation will use some constant values. I will have to #ifdef them, I suppose.

My code is here, but it's not the most recent: https://github.com/josch1710/ClassiCube/tree/os2.

EDIT: I let the code run in IDEBUG until WinFileDlg is called. The function gets called from the main thread (i.e. main() is in the call stack). In the call stack is the window procedure reacting to a mouse button click.I suppose, this is should not be an issue, because in the end, everything gets called from the window procedure. At the time, the code is about to call WinFileDlg there is about 1M of stack memory left. This should enough, shouldn't it.
Also the dialog box flashes on the screen, and I can see a lot of dialog messages being processed, until the dialog crashes the app.

12

Programming / Re: ClassiCube porting thread

« on: May 05, 2024, 10:57:26 am »

This looks like stack overflow in a secondary thread (TID 0xa).  If possible, try rebuilding with larger thread stacks.

Steven

Thanks for the hint, but even with a stacksize of 81920000 the dialog crashes the app (and also the IBM debugger, BTW).
There must be something else be going on.

BTW, do you know where to find this SYSxxxx code?

13

Programming / Re: ClassiCube porting thread

« on: May 04, 2024, 07:24:44 pm »

Another problem, I can't solve, is that the eCosoft Runtime's file dialog crash with the following code

Code: [Select]

FILEDLG fileDialog;
HWND hDialog;

memset(&fileDialog, 0, sizeof(FILEDLG));
fileDialog.cbSize = sizeof(FILEDLG);
fileDialog.fl = FDS_HELPBUTTON | FDS_CENTER | FDS_OPEN_DIALOG;
fileDialog.pszTitle = (PSZ)args->description;

memcpy(fileDialog.szFullFile, *(args->filters), CCHMAXPATH);
hDialog = WinFileDlg(HWND_DESKTOP, hwndFrame, &fileDialog);
if (fileDialog.lReturn == DID_OK) {
}
I uninstalled the runtimes. Nothing crashes, everything is fine. I reinstalled the newest runtime. The apps crashes again.
Other apps, like EPM, have no problems. I also replicated the example for WinFileDlg, but it's all the same.
My popup log is attached.

14

Programming / Re: ClassiCube porting thread

« on: May 04, 2024, 07:15:49 pm »

Sure, I read the WM_CHAR help, but there is no clue, why this happens only for captured windows.
While captured, I still see that F4 is released with ALT pressed. Weird.

15

Programming / Re: ClassiCube porting thread

« on: May 03, 2024, 09:37:16 am »

So I'm getting along, but I noticed some behaviour, I can't explain and I haven't find any clue in the Toolkit help.
While in the Launcher window or while in Game window with the menu open, the pointer isn't captured, so ALT+F4 works.
But in Game window with the menu closed, the pointer is captured, and then ALT+F4 will not work, while other keypresses are sending WM_CHARs.
Has someone a hint, what is happpening here?