Compiling a PM sample with GCC (2023)

[Rich Walsh]

You are asking, here is the answer: an application is very likely a 16-bit application if:

Thank you, Lars. Your response was vastly more helpful than mine.

I have deleted my earlier postings but evidence of their ugliness remains in various responses. I apologize to those who still have to see them, most especially Martin.

[Martin Iturbide]

You are asking, here is the answer: an application is very likely a 16-bit application if:

Thank you, Lars. Your response was vastly more helpful than mine.

I have deleted my earlier postings but evidence of their ugliness remains in various responses. I apologize to those who still have to see them, most especially Martin.

Thanks Lars

Thanks Rich. I also apologize. But please don't loose your patience because I'm going to keep asking more stuff and I'm going to keep compiling 16bit stuff because I found the sample result interesing.

I'm a slow learner on this area and even that I have my notes to solve some compile errors and warnings, I still get warnings and errors that I can not solve, even they look a lot similar of what was asked before.

If you loose your patience because I ask the same things, you don't have to reply.

Regards

[Martin Iturbide]

Hi Again.

Now it was the turn of MousDemo. A simple PM all that shows the coordinates of the mouse pointer on the screen.
https://github.com/OS2World/DEV-SAMPLES-C-MousDemo

It compiles and works. I had solved the compile errors and warnings.

Based on Lar's comments about 16bits applications.
On this sample:
1) It is a sample from 1988 - Which means it was for OS/2 1.x
2) I had removed the HEAPSIZE from the DEF file
3) Now it uses wl.exe
4) I changed the USHORT/SHORT for ULONG/LONG
5) Changed the (HWND hwnd,USHORT msg,MPARAM mp1,MPARAM mp2) for (HWND hwnd,ULONG msg,MPARAM mp1,MPARAM mp2)
6) Didn't find any "_loadds keyword" on the code.
7) Checked that it does not use the old "Family API", but I'm not sure which is the list of "legacy" PM functions that should not be used now.

Does it means this is a "good" sample for 32bits app? Or is still something on the sample that it makes it useless (bad/old practice) because it came from the 16bits world?

Regards

[Lars]

The correct answer would likely be: almost every 16-bit application can be converted into a 32-bit application (or at least into a hybrid 32-bit/16-bit application that contains a bare minimum of 16-bit code where there is no 32-bit equivalent) but it takes time, effort and a bit of engineering judgement to do so. As you have already realized.
So, yes, if you convert it to 32-bit, it still can be helpful to achieve its initial, intended purpose.

[Martin Iturbide]

Hi

NBEZ was an interesting sample of a Notebook control sample in vertical style. After fixing some little errors it also compiled and works without any issues I can find.
https://github.com/OS2World/DEV-SAMPLES-C-PM-NBEZ

Regards

[Martin Iturbide]

Hi

Some other samples that compiled and keep working.
- https://github.com/OS2World/DEV-SAMPLES-C-PM-Bug
- https://github.com/OS2World/DEV-SAMPLES-C-PM-GPI-Bezier
- https://github.com/OS2World/DEV-SAMPLES-C-PM-MetaTest

Regards

[fusion]

Off topic I guess but I converted the mousdemo version to compile with Virtual Pascal:

[Martin Iturbide]

Hi Fusion.

That is interesting. I haven't compiled anything with Virtual Pascal. Do you think you can pack it up in a zip file with the makefile and txt file explaining. You can modify the included TXT (https://github.com/OS2World/DEV-SAMPLES-C-PM-MousDemo/blob/master/MOUSDEMO.TXT)

Regards

[fusion]

That is interesting. I haven't compiled anything with Virtual Pascal. Do you think you can pack it up in a zip file with the makefile and txt file explaining. You can modify the included TXT (https://github.com/OS2World/DEV-SAMPLES-C-PM-MousDemo/blob/master/MOUSDEMO.TXT)

Pascal compilation is generally easier than C.. there is no Makefile involved. Just open the file in the Virtual Pascal IDE and press F9 (or click Compile -> Make). The output binary goes to C:\VP21\OUT.OS2 by default.

[Martin Iturbide]

Hi Again

I have an issue with this old 1.x sample:
https://github.com/OS2World/DEV-SAMPLES-C-WinTree

I got this:

Code: [Select]

gcc -Wall -Zomf -c -O2 wintree.c -o wintree.obj
wintree.c: In function 'TraverseWindows':
wintree.c:130:7: warning: implicit declaration of function 'WinLockWindow'; did you mean 'WinShowWindow'? [-Wimplicit-function-declaration]
  130 |       WinLockWindow(hwndNext,FALSE);
      |       ^~~~~~~~~~~~~
      |       WinShowWindow
wintree.c:150:26: warning: format '%p' expects argument of type 'void *', but argument 4 has type 'HWND' {aka 'long unsigned int'} [-Wformat=]
  150 |       sprintf(szLine,"%s%p...%s...%s",szLeader, hwndNext, szTitle, szClass);
      |                         ~^                      ~~~~~~~~
      |                          |                      |
      |                          void *                 HWND {aka long unsigned int}
      |                         %ld
gcc -Zomf wintree.obj wintree.def -o wintree.exe
weakld: error: Unresolved symbol (UNDEF) '_WinLockWindow'.
weakld: info: The symbol is referenced by:
    C:\dev\DEV-SAMPLES-C-WinTree\wintree.obj
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: _WinLockWindow is an undefined reference
file C:\dev\DEV-SAMPLES-C-WinTree\wintree.obj(wintree.obj): undefined symbol _WinLockWindow
make: *** [makefile:10: wintree.exe] Error 1
On this case I'm not sure if I'm compiling it wrong, or is it that "WinLockWindow" should not be used anymore.
On the modern OS2TK I was not able to find information about it, but I know it exists because it is reference on OS2286.LIB (that what I guess it is old).

I'm not sure how to solve that warning too.

Regards

[Dave Yeo]

Seems to be a pure 16 bit API, it is in OW's os21x/pm.h if you want to compile a 16 bit version of the program. Calling it from 32 bit land means thunking and aligning and even then I'm not sure with GCC.
Surrounding it with a #if 0 #endif block allows the compilation to finish, making the stack bigger allows it to run.
As for the formatting, not sure. The original displays 16 bit addressing, the new one looks like 32 bit hex and changing the %p to %ld as GCC suggests results in decimal output with negative numbers. Looks better with %p.

Code: [Select]

--- WINTREE.C.bak       2023-05-07 09:07:52.000000000 -0700
+++ WINTREE.C   2023-05-07 09:19:26.000000000 -0700
@@ -126,9 +126,9 @@
       {

       /* Unlock the Window */
-
+#if 0
       WinLockWindow(hwndNext,FALSE);
-
+#endif
       /* Build the proper indentation string */

       for(i = 0; (i < 89) & (i < sLevel); i++)
@@ -147,7 +147,7 @@

       /* Append the handle to the window */

-      sprintf(szLine,"%s%p...%s...%s",szLeader, hwndNext, szTitle, szClass);
+      sprintf(szLine,"%s%ld...%s...%s",szLeader, hwndNext, szTitle, szClass);
       WinSendMsg(hwndList, LM_INSERTITEM, MPFROMSHORT(LIT_END), MPFROMP(szLine)
);


[Lars]

Use %u instead of %p. Or, if you want hex output, use %x.

[Dave Yeo]

Use %u instead of %p. Or, if you want hex output, use %x.

GCC suggests %lu or %lx to fix the warning, and they do. Both work fine, personally I prefer the hex output as well, the original also had hex output.
Edit: Actually I like the capitals that %lX gives.
Hard to find what the l does, from the Linux man page on sprintf()

Code: [Select]

l

(ell) A following integer conversion corresponds to a long int or unsigned long int argument, or a
 following n conversion corresponds to a pointer to a long int argument, or a following c conversion
corresponds to a wint_t argument, or a following s conversion corresponds to a pointer to wchar_t
argument.


[Martin Iturbide]

Hi

I followed the advice with WinLockWindow

+#if 0
       WinLockWindow(hwndNext,FALSE);
+#endif

It runs, but I have the issue with the process numbers (see picture, the one on the right is the old one and should be the correct one), is that what is being discussed, right?

I also tried replacing WinLockWindow with WinEnableWindow(hwndNext, FALSE); Seems to gives the same result.

Regards

[Dave Yeo]

Try it with %lX (that's a lower case L). Also remember that the original is displaying 16 bit addresses, 0000:0000, segment:offset while the new build displays flat 32 bit addresses.