OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Martin Iturbide on April 22, 2023, 03:40:46 am
-
Hi
I had setup a new Dev ArcaOS 5.0.7 VM to keep going with the "fun" of trying to compile some old Presentation Manager samples with GCC and other open source tools.
This is my Vanilla ArcaOS VM with:
- yum install git gcc make libc-devel binutils watcom-wrc watcom-wlink-hll
And I made sure that I have on the config.sys
SET INCLUDE=C:\usr\include
SET EMXOMFLD_LINKER=wl.exe
SET EMXOMFLD_TYPE=WLINK
I'm very happy that the samples we checked before are now compiling and working.
- https://github.com/OS2World/DEV-SAMPLES-PM-PMWalker2
- https://github.com/OS2World/DEV-SAMPLES-PM-BitCat
- https://github.com/OS2World/DEV-SAMPLES-PM-PMHello
My new compile attempts, questions and cry for help come next.
Regards
-
Hi
Now, I'm trying to compile VectFont
https://github.com/OS2World/DEV-SAMPLES-PM-VectFont
But checking the included makefile (VECTFONT) against the makefile I did, I'm not sure if missing some source code here.
I'm attaching my build attempt and the errors on make.out. I don't care about the warnings yet, just the errors to try to compile the sample as it is includes first and later go after the warnings.
Regards
-
Missing code? Look at VECTFONT and VECTFONT.LNK, seems there are various vf**.c files expected.
-
Hi
Now, I'm trying to compile VectFont
https://github.com/OS2World/DEV-SAMPLES-PM-VectFont
But checking the cnluded makefile (VECTFONT) against the makefile I did, I'm not sure if missing some source code here.
I'm attaching my build attempt and the errors on make.out. I don't care about the warnings yet, just the errors to try to compile the sample as it is includes first and later go after the warnings.
Regards
Martin, I seem to remember that the Petzold book builds one example upon the other. As Dave said, you will need to find the missing source files on the floppy disk (?) and add them to the GitHub repo.
-
Hi
I found the full version:
https://archive.org/download/OS2BBS/08-Other.zip/S12219.ZIP
Now I have to check out how to recreate the makefile with all those.
Regards
-
Hi
Now vf00 to vf15 are compiling with a lot of warnigs that I will check later.
I'm stuck here:
gcc -Zomf vectfont.obj vectfont.def -o vectfont.exe
weakld: error: Unresolved symbol (UNDEF) '_Display_CharAngle'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_24Point'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_Stretch'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_Block'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_Mirror'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_Rotate'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_Spokes'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_Shadow'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_Hollow'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_Neon'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_CharShear'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_Fade'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_ModSpokes'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_DropShadow'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
weakld: error: Unresolved symbol (UNDEF) '_Display_Wavy'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj
Ignoring unresolved externals reported from weak prelinker.
Warning! W1058: file ldlF6kxQ.: line(19): protmode option not valid for an OS/2 EMX executable
Error! E2028: _Display_24Point is an undefined reference
Error! E2028: _Display_Mirror is an undefined reference
Error! E2028: _Display_Stretch is an undefined reference
Error! E2028: _Display_CharAngle is an undefined reference
Error! E2028: _Display_Rotate is an undefined reference
Error! E2028: _Display_CharShear is an undefined reference
Error! E2028: _Display_Shadow is an undefined reference
Error! E2028: _Display_Hollow is an undefined reference
Error! E2028: _Display_DropShadow is an undefined reference
Error! E2028: _Display_Block is an undefined reference
Error! E2028: _Display_Neon is an undefined reference
Error! E2028: _Display_Fade is an undefined reference
Error! E2028: _Display_Spokes is an undefined reference
Error! E2028: _Display_Wavy is an undefined reference
Error! E2028: _Display_ModSpokes is an undefined reference
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_24Point
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_Mirror
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_Stretch
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_CharAngle
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_Rotate
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_CharShear
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_Shadow
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_Hollow
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_DropShadow
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_Block
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_Neon
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_Fade
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_Spokes
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_Wavy
file C:\dev\DEV-SAMPLES-PM-VectFont\vectfont.obj(vectfont.obj): undefined symbol _Display_ModSpokes
make: *** [vectfont.exe] Error 1
Maybe I'm not doing something fine on the new makefile. (nake,out attached)
Regards
-
Hi
Checking my makefile I think I need to call all the .obj to create vectfont.exe.
I changed to this:
vectfont.exe : vectfont.obj vectfont.res vf00.obj vf01.obj vf02.obj vf03.obj vf04.obj vf05.obj vf06.obj vf07.obj vf08.obj vf09.obj vf10.obj vf11.obj vf12.obj vf13.obj vf14.obj vf15.obj vectfont.def
gcc -Zomf vectfont.obj vf00.obj vf01.obj vf02.obj vf03.obj vf04.obj vf05.obj vf06.obj vf07.obj vf08.obj vf09.obj vf10.obj vf11.obj vf12.obj vf13.obj vf14.obj vf15.obj vectfont.def -o vectfont.exe
wrc vectfont.res
Now the error changed to:
gcc -Zomf vectfont.obj vf00.obj vf01.obj vf02.obj vf03.obj vf04.obj vf05.obj vf06.obj vf07.obj vf08.obj vf09.obj vf10.obj vf11.obj vf12.obj vf13.obj vf14.obj vf15.obj vectfont.def -o vectfont.exe
weakld: error: Unresolved symbol (UNDEF) '_max'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vf00.obj
C:\dev\DEV-SAMPLES-PM-VectFont\vf14.obj
weakld: error: Unresolved symbol (UNDEF) '_min'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vf00.obj
C:\dev\DEV-SAMPLES-PM-VectFont\vf05.obj
C:\dev\DEV-SAMPLES-PM-VectFont\vf14.obj
Ignoring unresolved externals reported from weak prelinker.
Warning! W1058: file ldgVmPcu.: line(35): protmode option not valid for an OS/2 EMX executable
Error! E2028: _max is an undefined reference
Error! E2028: _min is an undefined reference
file C:\dev\DEV-SAMPLES-PM-VectFont\vf00.obj(vf00.obj): undefined symbol _max
file C:\dev\DEV-SAMPLES-PM-VectFont\vf00.obj(vf00.obj): undefined symbol _min
file C:\dev\DEV-SAMPLES-PM-VectFont\vf05.obj(vf05.obj): undefined symbol _min
file C:\dev\DEV-SAMPLES-PM-VectFont\vf14.obj(vf14.obj): undefined symbol _min
file C:\dev\DEV-SAMPLES-PM-VectFont\vf14.obj(vf14.obj): undefined symbol _max
make: *** [vectfont.exe] Error 1
-
os2tk45\h\libc\stdlib.h has,
#define max(a,b) (((a) > (b)) ? (a) : (b))
#define min(a,b) (((a) < (b)) ? (a) : (b))
-
Hi Dave
I haven't installed the OS2tk45.
I'm using this one:
[C:\usr\include]dir stdlib.h
The volume label in drive C is ARCAOS.
The Volume Serial Number is C470:B5BB.
Directory of C:\usr\include
4-22-23 7:24a 16,886 124 a--- stdlib.h
1 file(s) 16,886 bytes used
It does not has any max(a,b) or min(a,b). If I include those lines on stdlib.h I get the same error.
gcc -I. -Zomf vectfont.obj vf00.obj vf01.obj vf02.obj vf03.obj vf04.obj vf05.obj
vf06.obj vf07.obj vf08.obj vf09.obj vf10.obj vf11.obj vf12.obj vf13.obj vf14.ob
j vf15.obj vectfont.def -o vectfont.exe
weakld: error: Unresolved symbol (UNDEF) '_max'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vf00.obj
C:\dev\DEV-SAMPLES-PM-VectFont\vf14.obj
weakld: error: Unresolved symbol (UNDEF) '_min'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-VectFont\vf00.obj
C:\dev\DEV-SAMPLES-PM-VectFont\vf14.obj
Ignoring unresolved externals reported from weak prelinker.
Warning! W1058: file ldmdI0AW.: line(35): protmode option not valid for an OS/2
EMX executable
Error! E2028: _max is an undefined reference
Error! E2028: _min is an undefined reference
file C:\dev\DEV-SAMPLES-PM-VectFont\vf00.obj(vf00.obj): undefined symbol _max
file C:\dev\DEV-SAMPLES-PM-VectFont\vf00.obj(vf00.obj): undefined symbol _min
file C:\dev\DEV-SAMPLES-PM-VectFont\vf14.obj(vf14.obj): undefined symbol _min
file C:\dev\DEV-SAMPLES-PM-VectFont\vf14.obj(vf14.obj): undefined symbol _max
make: *** [vectfont.exe] Error 1
Now, I installed os2tk45, but I can not find stdlib.h to compare it with the one on "C:\usr\include".
Which package contains the os2tk45 stdlib.h ?
Regards
-
I found libc/stddef.h in os2tk45, the complete package. I guess Bitwise didn't add the conflicting libc to the rpm.
Simplest in this case is just to add the defines, with guards incase someone does use the toolkit or such where min and max are defined. VECTFONT.H seems like a good candidate, could create a header as well.
diff --git a/VECTFONT.H b/VECTFONT.H
index fcae64a..6fac9ca 100644
--- a/VECTFONT.H
+++ b/VECTFONT.H
@@ -48,3 +48,10 @@ VOID Display_Fade (HPS hps, LONG cxClient, LONG cyClient) ;
// VF12
VOID Display_Spokes (HPS hps, LONG cxClient, LONG cyClient) ; // VF13
VOID Display_Wavy (HPS hps, LONG cxClient, LONG cyClient) ; // VF14
VOID Display_ModSpokes (HPS hps, LONG cxClient, LONG cyClient) ; // VF15
+
+#ifndef max
+#define max(a,b) (((a) > (b)) ? (a) : (b))
+#endif
+#ifndef min
+#define min(a,b) (((a) < (b)) ? (a) : (b))
+#endif
This compiles but doesn't work as expected. Wrong max and min?
BTW, my makefile patch is this, more readable. I see you didn't commit the makefile :)
all : vectfont.exe
vectfont.exe : vectfont.obj vectfont.res vf00.obj vf01.obj vf02.obj vf03.obj \
vf04.obj vf05.obj vf06.obj vf07.obj vf08.obj vf09.obj vf10.obj \
vf11.obj vf12.obj vf13.obj vf14.obj vf15.obj vectfont.def
gcc -Zomf vectfont.obj vf00.obj vf01.obj vf02.obj vf03.obj vf04.obj \
vf05.obj vf06.obj vf07.obj vf08.obj vf09.obj vf10.obj vf11.obj \
vf12.obj vf13.obj vf14.obj vf15.obj vectfont.def -o vectfont.exe
wrc vectfont.res
-
Hi
Sorry, no answers to the above questions but they do cause me to ask: Why can I not see the text in the boxes marked as Code: [Select] using Daves current Dooble build? - see attached dooble_text.jpg
Regards
Pete
-
Bad font? What does "fc-match fixed" output? Could try "fc-match -v fixed | less" for more info on the font.
Long term I'd suggest installing some more fonts.
Edit: Also try closing Dooble, run "fc-cache -r", wait till it finishes and try Dooble again
Edit2: Did you install WinOS2 support?
-
Hi Dave
In my case the program compiled, with your suggested change to vectfont.h. The exe file seems to be working, it is showing different text with different styles, like the origina sample exe.
I'm attaching it.
My next step will be to go after the warnings.
Regards
-
OK, it looks like you fixed a few warnings and you're tree works here. Previous didn't show any of the different text's, just a blank window.
Edit: Seems that your changing a couple of USHORT's to ULONG's in VECTFONT.C fixed it.
@@ -7,13 +7,13 @@
#include <os2.h>
#include "vectfont.h"
-MRESULT EXPENTRY ClientWndProc (HWND, USHORT, MPARAM, MPARAM) ;
+MRESULT EXPENTRY ClientWndProc (HWND, ULONG, MPARAM, MPARAM) ;
HAB hab ;
...
WinDestroyWindow (hwndFrame) ;
@@ -46,7 +45,7 @@
return 0 ;
}
-MRESULT EXPENTRY ClientWndProc (HWND hwnd, USHORT msg, MPARAM mp1,
+MRESULT EXPENTRY ClientWndProc (HWND hwnd, ULONG msg, MPARAM mp1,
MPARAM mp2)
{
static struct {
-
Hi Dave
[L:\]fc-match fixed
HELV.PFB: "Helvetica" "Regular"
fc-cache -r seems to have fixed the problem.
Thanks
Pete
-
Hi Dave
[L:\]fc-match fixed
HELV.PFB: "Helvetica" "Regular"
fc-cache -r seems to have fixed the problem.
Thanks
Pete
Bad cache. fc-cache -r really forces all fontconfig caches to be rebuilt. fc-cache or fc-cache -f might have been good enough.
Edit: Helvetica isn't really a good choice for fixed, but must be the best that fontconfig can find.
-
OK, it looks like you fixed a few warnings and you're tree works here. Previous didn't show any of the different text's, just a blank window.
Edit: Seems that your changing a couple of USHORT's to ULONG's in VECTFONT.C fixed it.
Thanks Dave. I didn't notice that ULONG change will benefit the program in that way.
I need some help to try to get out the warnings, What do you suggest me with this " CHAR * {aka char *}" warning?
I had try to change the declaration to "unsigned char" but it generates more warning.
vf00.c: In function 'QueryStartPointInTextBox':
vf00.c:90:36: warning: pointer targets in passing argument 3 of 'GpiQueryTextBox' differ in signedness [-Wpointer-sign]
90 | GpiQueryTextBox (hps, cbText, szText, TXTBOX_COUNT, aptl) ;
| ^~~~~~
| |
| CHAR * {aka char *}
In file included from C:/usr/include/os2.h:39,
from vf00.c:7:
C:/usr/include/os2emx.h:9211:59: note: expected 'PCH' {aka 'unsigned char *'} but argument is of type 'CHAR *' {aka 'char *'}
9211 | BOOL APIENTRY GpiQueryTextBox (HPS hps, LONG lCount1, PCH pchString, LONG lCount2,
| ~~~~^~~~~~~~~
My goal is to leave this sample as good as possible to compile with GCC and the .h that we have on the RPM.
Regards
-
Hi
I had reduced the number of warnings of "szText".
I just have 9 warnings left, but I'm stuck there.
Regards
-
Try this one. Did some casts and added a bunch of curly brackets.
-
Thank you Dave for the casting lesson. It compiles beautifully now without any warnings.
I will prepare the file with a readme and upload it to github.
Regards
-
Here it goes.
And uploaded to github: https://github.com/OS2World/DEV-SAMPLES-PM-VectFont
-
Hi
Moving to the next one:
https://github.com/OS2World/DEV-SAMPLES-PM-Slider
This is an older sample, I recreated the makefile, since it looked in a format I don't know about.
I think I solved the warnings.
I'm still not sure how it looks, I'm getting this issue with the wrc.
[C:\DEV\DEV-SAMPLES-PM-SLIDER]make 2>&1 | tee make.out
gcc -Wall -Zomf -c -O2 slider.c -o slider.obj
wrc -r slider.rc
Open Watcom Windows and OS/2 Resource Compiler Version 2.0beta1 LA
Portions Copyright (c) 1993-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
slider.rc(30): Error! E049: Syntax error near "0x00000100L "
make: *** [slider.res] Error 8
Regards
-
Trying with rc instead of wrc, I get
Creating binary resource file slider.RES
RC: RCPP -E -D RC_INVOKED -W4 -f slider.rc -ef W:\OS2\RCPP.ERR -I W:\usr\include\os2tk45\inc -I W:\usr\include\os2tk45\gl -I W:\usr\include\os2tk45
slider.rc(36) : fatal error C1004: unexpected EOF
make: *** [makefile:17: slider.res] Error 3
Fixed by adding an EOL (blank line) at the end of the rc file. Wrc stll fails.
Was there a reason that you named the binary vectfont.exe? Seems it should be slider.exe.
Now the error is
Creating binary resource file slider.RES
RC: RCPP -E -D RC_INVOKED -W4 -f slider.rc -ef W:\OS2\RCPP.ERR -I W:\usr\includ
e\os2tk45\inc -I W:\usr\include\os2tk45\gl -I W:\usr\include\os2tk45
slider.rc
gcc -Zomf slider.obj slider.res slider.obj slider.def -o slider.exe
weakld: H:\tmp\DEV-SAMPLES-PM-Slider\slider.obj - error: Duplicate symbol '_main' ('_main').
weakld: H:\tmp\DEV-SAMPLES-PM-Slider\slider.obj - error: Symbol previosly defined in this module.
weakld: info: fFlags new 0x0001 fFlags old 0x0001 (PUBLIC).
weakld: info: The symbol is referenced by:
W:\usr\lib\crt0.obj
emxomfld: weak prelinker failed. (rc=-1)
make: *** [makefile:10: slider.exe] Error 1
-
Hi Dave
vectfont.exe was my mistake on the makefile. I fixed it, includes the EOL on the rc file and now I get this.
gcc -Wall -Zomf -c -O2 slider.c -o slider.obj
wrc -r slider.rc
Open Watcom Windows and OS/2 Resource Compiler Version 2.0beta1 LA
Portions Copyright (c) 1993-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
slider.rc(30): Error! E049: Syntax error near "0x00000100L "
make: *** [slider.res] Error 8
-
Yes, I'm still using rc.exe for now until I research.
You had two slider.obj in the linker line in the makefile causing the duplicate main() error.
Then need to remove the export in the DEF file to get rid of
weakld: error: Unresolved symbol (UNDEF) 'ClientWndProc
Then slider.exe works.
-
The rc file is missing a | after SLS_READONLY on line 30. Strange that rc is fine with that but not wrc.
-
Hi Dave
If I remove .DEF from the make file, and add the | after SLS_READONLY, it will compile. But my slider.exe just loads and quit without working.
I get this message now with RC:
[C:\DEV\DEV-SAMPLES-PM-SLIDER]make 2>&1 | tee make.out
gcc -Wall -Zomf -c -O2 slider.c -o slider.obj
gcc -Zomf slider.obj slider.res -o slider.exe
Compile ending.
RC is reading the binary resource file C:\dev\DEV-SAMPLES-PM-Slider\slider.res.
RC :Warning 3014: RC found a resource type equal to zero.
RC :Error 1003:RC had an I/O error with file .
make: *** [slider.exe] Error 1
-
Try this one.
-
Hi
slider.exe compiles.
[C:\DEV\DEV-SAMPLES-PM-SLIDER]make 2>&1 | tee make.out
gcc -Wall -Zomf -O2 -c slider.c -o slider.obj
gcc -Zomf slider.obj slider.res slider.def -o slider.exe
Compile ending.
RC is reading the binary resource file C:\dev\DEV-SAMPLES-PM-Slider\slider.res.
RC :Warning 3014: RC found a resource type equal to zero.
RC :Error 1003:RC had an I/O error with file .
make: *** [slider.exe] Error 1
When I run it it crash and gives this POPUPLOG.
04-27-2023 16:26:24 SYS3171 PID 111d TID 0001 Slot 00a7
C:\HOME\DESKTOP\SLIDER.EXE
c0000005
1fa0f452
P1=00000002 P2=0004fffc P3=XXXXXXXX P4=XXXXXXXX
EAX=000500a8 EBX=1b914ff8 ECX=5f1dc7d0 EDX=19e31bba
ESI=00000000 EDI=000503cc
DS=0053 DSACC=d0f3 DSLIM=5fffffff
ES=0053 ESACC=d0f3 ESLIM=5fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1fa0f452 CSACC=d0df CSLIM=5fffffff
SS:ESP=0053:00050000 SSACC=d0f3 SSLIM=5fffffff
EBP=000500a8 FLG=00010202
SOFTDRAW.DLL 0001:0007f452
-
Are you mixing rc.exe and wrc.exe? I used rc.exe to troubleshoot and then reverted to wrc, have to keep the environmental variables in sync with the makefile.
Here's the same package without doing make clean, slider.exe works here.
-
Hi Dave.
I tried your files, I removed the old files and just leave the files on "slider_b2.zip"
I tested first your "slider.exe" file and it works. Finally I saw how the program should look like.
I did a "make clean" and run compile.cmd. On this case I remain using wrc on the makefile.
It gave me this error and the generated slider.exe is not working.
[C:\DEV\DEV-SAMPLES-PM-SLIDER]make 2>&1 | tee make.out
gcc -Wall -Zomf -O2 -c slider.c -o slider.obj
gcc -Zomf slider.obj slider.res slider.def -o slider.exe
Compile ending.
RC is reading the binary resource file C:\dev\DEV-SAMPLES-PM-Slider\slider.res.
RC :Warning 3014: RC found a resource type equal to zero.
RC :Error 1003:RC had an I/O error with file .
make: *** [slider.exe] Error 1
FYI: I don't use ilink.exe, I'm using the wl.exe linker.
I thought that to change from wrc to rc.exe was just to change the makefile, is something else I need to change?
Should it be that I may be missing some .h file? I don't know why SLIDER.DEP makes reference to fclsldp.h. I don't have that .h on hard drive.
My enviroment is very simple and I just have this:
SET INCLUDE=C:\usr\include\os2tk45\inc;C:\usr\include\os2tk45\gl;C:\usr\include\os2tk45;C:\USR\INCLUDE
SET EMXOMFLD_LINKER=wl.exe
SET EMXOMFLD_TYPE=WLINK
Regards
-
Hi
FOUND MY ISSUE.
It was something with my environment. I removed the OS2TK45 (RPM) completely from my dev system.
My config.sys was.
SET LIB=C:\USR\LIB
SET INCLUDE=C:\USR\INCLUDE
SET EMXOMFLD_LINKER=wl.exe
SET EMXOMFLD_TYPE=WLINK
Tested all the other samples, WALKER2, BITCAT, VECTFONT. All compiled and worked without problems.
Returned to "SLIDER", compile it and I get this error:
[C:\DEV\DEV-SAMPLES-PM-SLIDER]make 2>&1 | tee make.out
gcc -Wall -Zomf -O2 -c slider.c -o slider.obj
gcc -Zomf slider.obj slider.res slider.def -o slider.exe
emxomfld: rc: No such file or directory
make: *** [slider.exe] Error 1
So, I guess that comparing SLIDER to the other samples, this one compiles in a way I need to specify the RC.
I added ...
SET EMXOMFLD_RC_TYPE=WRC
SET EMXOMFLD_RC=wrc.exe
Now it works.
Regards
-
Hi
I moved on with the next sample: PM Running Box.
- https://github.com/OS2World/DEV-SAMPLES-PM-PM_running_Box (https://github.com/OS2World/DEV-SAMPLES-PM-PM_running_Box)
It compiled very easy, it works as expected and warnings were removed.
I just got this warning that I don't know about:
gcc -Wall -Zomf -c -O2 run.c -o run.obj
gcc -Zomf run.obj run.def -o run.exe
Warning! W1058: file ldSBPZPt.: line(20): protmode option not valid for an OS/2 EMX executable
Regards
-
gcc -Wall -Zomf -c -O2 run.c -o run.obj
gcc -Zomf run.obj run.def -o run.exe
Warning! W1058: file ldSBPZPt.: line(20): protmode option not valid for an OS/2 EMX executable
Easy, it was the "protmode" that was on the .DEF, I just removed since it was empty.
No more warning for this one.
Regards
-
Yea, the protmode one is weird. Everyone used it with link386/ilink, which never complained and the documentation hints that it is needed for protected mode programs. Meanwhile wlink complains about it and it seems that it is actually an OS/2 1.x thing, or maybe 16 bit thing.
Syntax: PROTMODE
This statement specifies that the module runs only in protected mode and not in Windows or dual mode. This statement is always optional and permits a protected mode only application to omit some information from the executable file header.
If this statement is not included in the module definition file, LINK386 assumes the application can be run in either real or protected mode.
-
Thanks Dave
Now I want to try another sample.
https://github.com/OS2World/DEV-SAMPLES-PM-LBoxFont
I had corrected some warnings, did some changes (I hope I didn't break anything) but I'm stuck in these errors.
gcc -Wall -Zomf -c -O2 app.c -o app.obj
gcc -Wall -Zomf -c -O2 wndproc.c -o wndproc.obj
wndproc.c: In function 'APPWndProc':
wndproc.c:112:9: warning: returning 'int' from a function with return type 'MRESULT' {aka 'void *'} makes pointer from integer without a cast [-Wint-conversion]
112 | return TRUE;
| ^~~~
gcc -Wall -Zomf -c -O2 appcmd.c -o appcmd.obj
appcmd.c: In function 'APPCommand':
appcmd.c:22:7: warning: 'strncpy' output truncated before terminating nul copying 6 bytes from a string of the same length [-Wstringop-truncation]
22 | strncpy (temp, "Window", index2);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
appcmd.c:27:7: warning: 'strncpy' output truncated before terminating nul copying 7 bytes from a string of the same length [-Wstringop-truncation]
27 | strncpy (temp, "PM Land", index2);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc -Wall -Zomf -c -O2 apppaint.c -o apppaint.obj
gcc -Zomf app.obj app.def -o app.exe
weakld: error: Unresolved symbol (UNDEF) 'APPCommand'.
weakld: info: The symbol is referenced by:
C:/dev/DEV-SAMPLES-PM-LBoxFont/APP.DEF
weakld: error: Unresolved symbol (UNDEF) 'APPWndProc'.
weakld: info: The symbol is referenced by:
C:/dev/DEV-SAMPLES-PM-LBoxFont/APP.DEF
C:\dev\DEV-SAMPLES-PM-LBoxFont\app.obj
weakld: error: Unresolved symbol (UNDEF) 'EditDlg'.
weakld: info: The symbol is referenced by:
C:/dev/DEV-SAMPLES-PM-LBoxFont/APP.DEF
weakld: error: Unresolved symbol (UNDEF) 'About'.
weakld: info: The symbol is referenced by:
C:/dev/DEV-SAMPLES-PM-LBoxFont/APP.DEF
weakld: error: Unresolved symbol (UNDEF) '_FontMetrics'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-PM-LBoxFont\app.obj
Ignoring unresolved externals reported from weak prelinker.
emxomfld: ignoring SEGMENTS directive in .def-file
emxomfld: ignoring SEGMENTS directive in .def-file
emxomfld: ignoring SEGMENTS directive in .def-file
emxomfld: ignoring SEGMENTS directive in .def-file
Error! E2028: APPWndProc is an undefined reference
Error! E2028: About is an undefined reference
Error! E2028: APPCommand is an undefined reference
Error! E2028: EditDlg is an undefined reference
Error! E2028: _FontMetrics is an undefined reference
Error! E2044: exported symbol APPWndProc not found
Error! E2044: exported symbol About not found
Error! E2044: exported symbol APPCommand not found
Error! E2044: exported symbol EditDlg not found
make: *** [app.exe] Error 1
Regards
-
Well with these changes it compiles, but doesn't run, leaving an entry in popuplog
--- APP.DEF.orig 2023-04-28 18:29:06.000000000 -0700
+++ APP.DEF 2023-04-28 18:30:02.000000000 -0700
@@ -2,22 +2,10 @@
DESCRIPTION 'OS/2 Presentation Manager Application - Skeleton'
-STUB 'OS2STUB.EXE'
-
CODE MOVEABLE
DATA MOVEABLE MULTIPLE
-SEGMENTS
- APP_TEXT PRELOAD MOVEABLE DISCARDABLE
- WNDPROC_TEXT PRELOAD MOVEABLE DISCARDABLE
- APPCMD_TEXT LOADONCALL MOVEABLE DISCARDABLE
- APPPAINT_TEXT MOVEABLE DISCARDABLE
-
HEAPSIZE 2048
STACKSIZE 4096
-EXPORTS
- APPWndProc @1
- About @2
- APPCommand @3
- EditDlg @4
+
--- makefile.orig 2023-04-28 18:31:14.000000000 -0700
+++ makefile 2023-04-28 18:43:36.000000000 -0700
@@ -7,7 +7,8 @@
all : app.exe
app.exe : app.obj wndproc.obj appcmd.obj apppaint.obj app.res app.def
- gcc -Zomf app.obj app.def -o app.exe
+ gcc -Zomf app.obj wndproc.obj appcmd.obj apppaint.obj app.res \
+ app.def -o app.exe
wrc app.res
app.obj : app.c app.h
Being a 16 bit OS/2 program, perhaps it needs more porting?
Edit: This gets rid of one warning
--- WNDPROC.C.orig 2023-04-28 18:52:40.000000000 -0700
+++ WNDPROC.C 2023-04-28 18:51:42.000000000 -0700
@@ -109,7 +109,7 @@
break;
case WM_ERASEBACKGROUND:
- return TRUE;
+ return (MRESULT) TRUE;
break;
case WM_DRAWITEM:
-
OK, better def to make it not crash,
NAME APP WINDOWAPI
DESCRIPTION '@#OS2World:1.01#@##1## 28 Apr 2023 17:01:00 ARCAOS-507::::::v1.01@@App test'
HEAPSIZE 1024
STACKSIZE 8192
Bldlevel copied from one of your other defs
Edit: I think the truncated strings were truncated on purpose, probably there is a better way to code it.
Edit2: Or bad programming? This gets rid of the error but I'm not sure if it correct
--- APPCMD.C.orig 2023-04-28 19:12:48.000000000 -0700
+++ APPCMD.C 2023-04-28 19:12:02.000000000 -0700
@@ -18,12 +18,12 @@
{
- index2 = strlen ("Window");
+ index2 = strlen ("Window") + 1;
strncpy (temp, "Window", index2);
temp [index2] = '\0';
WinSendMsg (hwndList, LM_INSERTITEM, MPFROM2SHORT (LIT_SORTASCENDING, 0),
MPFROMP (temp));
- index2 = strlen ("PM Land");
+ index2 = strlen ("PM Land") + 1;
strncpy (temp, "PM Land", index2);
temp [index2] = '\0';
-
Thanks Dave
It compiles and runs now. Not sure if the program is doing all that it should, but it put strings on the list box.
I think Im publishing this one on github and move to other sample.
Regards
-
Hi
RandRect demo also compiles and runs as expected. I removed the warnings and it is available at:
https://github.com/OS2World/DEV-SAMPLES-PM-RANDRECT
Regards
-
Hi
After fixing the warnings I also have "Checkers Board" sample compiling on gcc 9.
An interesting remark here is that it used the old "Profile Manager" functions WinQueryProfileData and WinWriteProfileData that was changed for PrfQueryProfileData and PrfWriteProfileData
https://github.com/OS2World/DEV-SAMPLES-PM-Checkers_Board
Regards
-
Hi
I moved along with Air_Traffic_Control_Container
https://github.com/OS2World/DEV-SAMPLES-PM-Air_Traffic_Control_Container
After some fixing it compiles and runs, but I need a hand with these warnings.
gcc -Wall -Zomf -c -O2 atccnr.c -o atccnr.obj
atccnr.c: In function 'InsertContainerRecords':
atccnr.c:437:50: warning: pointer targets in initialization of 'unsigned char *' from 'char *' differ in signedness [-Wpointer-sign]
437 | static const PSZ apszCallSignPrefixes [] = { "AA", "DA", "UA", "TW" };
| ^~~~
atccnr.c:437:50: note: (near initialization for 'apszCallSignPrefixes[0]')
atccnr.c:437:56: warning: pointer targets in initialization of 'unsigned char *' from 'char *' differ in signedness [-Wpointer-sign]
437 | static const PSZ apszCallSignPrefixes [] = { "AA", "DA", "UA", "TW" };
| ^~~~
atccnr.c:437:56: note: (near initialization for 'apszCallSignPrefixes[1]')
atccnr.c:437:62: warning: pointer targets in initialization of 'unsigned char *' from 'char *' differ in signedness [-Wpointer-sign]
437 | static const PSZ apszCallSignPrefixes [] = { "AA", "DA", "UA", "TW" };
| ^~~~
atccnr.c:437:62: note: (near initialization for 'apszCallSignPrefixes[2]')
atccnr.c:437:68: warning: pointer targets in initialization of 'unsigned char *' from 'char *' differ in signedness [-Wpointer-sign]
437 | static const PSZ apszCallSignPrefixes [] = { "AA", "DA", "UA", "TW" };
| ^~~~
atccnr.c:437:68: note: (near initialization for 'apszCallSignPrefixes[3]')
atccnr.c:485:30: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'int' [-Wformat=]
485 | sprintf (szBuf, "%s%ld", apszCallSignPrefixes [rand() % cPrefixes],
| ~~^
| |
| long int
| %d
486 | rand() % 1000);
| ~~~~~~~~~~~~~
| |
| int
And as a extra thing, I want to also generte the .HLP file on the makefile, so I have some questions.
1) Is there any open source alternative to ipfc.exe
2) Is ipfc.exe available on the RPM? if so, which package has it?
Regards
-
Hi Martin, there is wipfc,
G:\WATCOM\binp>wipfc.exe
Open Watcom OS/2 Help Compiler Version 2.0beta4 Limited Availability by GKYMar2 2022
Copyright (c) 2010 Open Watcom Contributors. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
The 'WIPFC' environment variable needs to be set. It should contain the name of
the directory containing .nls and entity.txt
No experience with it besides that others use it and it mostly works fine.
Edit: os2tk45-ipfc.rpm contains all the files for ipfc, *.aps, ibmdic.dic and the nls files and of course ipfc.exe
-
This patch compiles the help file,
--- makefile.orig 2023-04-29 09:11:40.000000000 -0700
+++ makefile 2023-04-29 09:08:46.000000000 -0700
@@ -4,7 +4,7 @@
# Compile::Watcom Resource Compiler
# Compile::GNU C
# Make: nmake or GNU make
-all : atccnr.exe
+all : atccnr.exe atccnr.hlp
atccnr.exe : atccnr.obj help.obj atccnr.res atccnr.def
gcc -Zomf atccnr.obj help.obj atccnr.res atccnr.def -o atccnr.exe
@@ -19,5 +19,8 @@
atccnr.res : atccnr.rc jet.ico
wrc -r atccnr.rc
+atccnr.hlp: atccnr.ipf
+ ipfc atccnr.ipf
+
clean :
- rm -rf *exe *RES *obj
\ No newline at end of file
+ rm -rf *exe *RES *obj *HLP
And one warning down, not sure about the signedness ones.
--- atccnr.c.orig 2023-04-29 09:06:48.000000000 -0700
+++ atccnr.c 2023-04-29 09:07:00.000000000 -0700
@@ -482,7 +482,7 @@
pacrTraverse->AssignedHeading = rand() % 360 + 1;
pacrTraverse->Speed =
pacrTraverse->AssignedSpeed = rand() % 20 + 10;
- sprintf (szBuf, "%s%ld", apszCallSignPrefixes [rand() % cPrefixes],
+ sprintf (szBuf, "%s%d", apszCallSignPrefixes [rand() % cPrefixes],
rand() % 1000);
pacrTraverse->pszCallsign = (PSZ) strdup (szBuf);
-
And one warning down, not sure about the signedness ones.
All these signed/unsigned character warnings can be resolved by adding "-DOS2EMX_PLAIN_CHAR" to the compiler flags. See 'os2emx.h' for details.
-
Thanks Dave, Rich
The warnings are now gone, and I think I'm done with this sample.
I had choose to use wipfc (watcom-wipfc package) on this case and the INF file is also included on the makefile. It worked fine as far as I can notice.
I uploaded the files to:
https://github.com/OS2World/DEV-SAMPLES-PM-Air_Traffic_Control_Container
Thanks
-
Hello again.
Now I want to try this one:
https://github.com/OS2World/DEV-SAMPLES-PM-AVBrowse
It is a OS/2 File Browser sample, but this one has a dependency on opendlg.h, so I grabbed it from a another sample, but I'm not sure if I'm doing it right. Should I try to find OPENDLG.LIB? not sure where to find it.
Update: I found an old discussion about OpenDLG (https://www.os2world.com/forum/index.php?topic=2888.0), but not sure if we solve it.
I have this errors that I don't know how to solve:
gcc -Wall -Zomf -c -O2 browse.c -o browse.obj
In file included from browse.c:15:
browse.h:18:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'RetrieveLine'
18 | const char * _loadds RetrieveLine(USHORT);
| ^~~~~~~~~~~~
browse.c: In function 'main':
browse.c:83:30: error: 'RetrieveLine' undeclared (first use in this function)
83 | lbiData.pfnQL = (PFNQL) RetrieveLine;
| ^~~~~~~~~~~~
browse.c:83:30: note: each undeclared identifier is reported only once for each function it appears in
browse.c: At top level:
browse.c:191:16: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'RetrieveLine'
191 | char * _loadds RetrieveLine(USHORT usLineNum) {
| ^~~~~~~~~~~~
make: *** [browse.obj] Error 1
Regards
-
There's something missing, likely an include, possibly a different opendlg.h. There should also be a (sibling?) VBROWSE directory according to the readme, and it seems old enough to use the msc compiler.
If no one else has any ideas, might be best to move on.
-
Hi
I also remove the warnings and compile with gcc the Slider2 sample (not to confuse with Slider).
https://github.com/OS2World/DEV-SAMPLES-PM-Slider_2
Only the Horizontal Slider works, the vertical one was not implemented.
It does not look like good, even the older executable, but I think it may be some work in progress.
Regards
-
Hi
And ZoomBMP was also an easy fix to compile with gcc 9. All warnings were removed.
- https://github.com/OS2World/DEV-SAMPLES-C-PM-ZoomBMP
The only thing that I see is that it seems to be some display error on the program when it loads the image for the first time, then the zoom out and zoom in with the mouse buttons works fine.
Regards
-
Hi Again
I have an issue with this one. It is supposed to be a very simple and short sample of a PM Window (I guess), it compiles, no warning, no errors, but the exe produce an error on popuplog.
https://github.com/OS2World/DEV-SAMPLES-C-PM-WindowTemplate
Any help is welcome.
Thanks
-
Too small of a stack, increasing it to 8192 in the def file fixes the crash. Works with a smaller heap too.
There must be a way to calculate the needed sizes but have no idea how besides trial and error.
DLG.DEF
NAME dlg WINDOWAPI
DESCRIPTION 'dlg - Data Window and Control Uitility'
STACKSIZE 8192
HEAPSIZE 1024
-
Thanks Dave, it worked.
Just one question, do you know where do you set the window size on the PM? The program runs small and you have to rezise the window to see it.
Do you know where can I change that?
Regards
-
Seems to be a resource as DLG.C has no WinCreateWindow() function. Perhaps it could be added?
Hopefully someone else understands how to.
-
Just one question, do you know where do you set the window size on the PM? The program runs small and you have to rezise the window to see it.
Do you know where can I change that?
Looks like the WinSetWindowPos() on line 61 of DLG.C is setting the window size to 150,150 (fifth & sixth arguments). Increase those numbers if you want a bigger window.
-
Hi Rich
Martin, I know you think you are being "helpful" ...
"You know?": Wrong assumption, I'm learning and having fun.
Maybe "you think" I know OS/2 programming, but I don't. It would be awesome if someone explain me and document how to indentify quick and easly the 16bit software. Feel free to write articles and blog post about it, I can post it on the EDM/2.
I also pity the poor person who wants to learn OS/2 programming with ArcaOS because there is no order or suggested tutorials on where to start, which samples to use and how to avoid the 1.x legacy.
BTW... I'm at a loss to understand why using the open-source 'wrc' which you have to find and install is somehow "better" than using 'rc' which is part of the OS and always available. It strikes me as a triumph of ideology over practicality.
I have this policy. Close source software is good, but open source software is better. why? Because you can improve open source software, while close source software's source code is inside someone's drawer. As far as a I know rc.exe is not open source, and it will never be improved, no matter how good or free of charge it is.
"Good close source software is future abandonware, bad open source software can be improved with time."
I'm just going forward to compile the stuff I find, but everybody is welcome to identify which things are interesting and which things should be archived only for historical reference only.
I aprecciate your point of view that 'PM Window Template' and 'AV Browse' are no useful material. It will be a good thing to indentify the "non useful samples" and put some disclaimer or suggestion for an "hypothetical person who wants to learn OS/2 programming" to read that.
Rich, feel free to give your opinon if a sample is worthwhile or not, since "I DON'T KNOW".
Regards
-
(Hint: looking up HEAPSIZE in any linker's reference manual would have clued you in - if only you had RTFM).
I just looked. The toolkits tools reference infers it is only for 16bit as there is MAXVAL which equals 64k.
The OW Linker guide says,
...
n specifies the size of the heap. The default heap size is 0 bytes. The maximum value of n is 65536 (64K) for 16-bit applications and 4G for 32-bit applications which is the maximum size of a physical segment. Actually, for a particular application, the maximum value of n is 64K or 4G less the size of group "DGROUP".
Testing with GCC, it does seem to be ignored with the DGROUP =250H in the map file. The documentation is not clear.
-
Hi Rich
What is your problem? Why are you being this way today?
This is a forum, and I'm asking for help on something I don't know. You are a prolific WPS developer, but that does not give you the right to undermine my little effort to do something with people that actually want to help me.
RFTM (Read The Fucking Manual) is a rude answer which tells me a lot of your personality.
Bottom line, Martin: why should I put forth the effort if it looks like you won't even try (and asking other people to solve every problem you encounter is definitely _not_ "trying").
Move on, relax, go watch some birds outside and try to help other people on different threads. Please don't put any efforts, I don't want your help.
Regards
-
(Hint: looking up HEAPSIZE in any linker's reference manual would have clued you in - if only you had RTFM).
I just looked. The toolkits tools reference infers it is only for 16bit as there is MAXVAL which equals 64k.
OK, I apologize for overstating my case. I was remembering the details from the 'ilink' reference which states "The HEAPSIZE statement has no effect on a 32-bit OS/2 program.". This is something that Martin would certainly not have access to. In contrast, the ref for 'link386' says nothing about it being 16-bit only.
It simply confirms what I always say: if I don't look something up and/or test exactly what I'm saying, I always get it wrong. It applies to me, and sadly, a great many of other forum participants as well.
-
Maybe "you think" I know OS/2 programming, but I don't. It would be awesome if someone explain me and document how to indentify quick and easly the 16bit software. Feel free to write articles and blog post about it, I can post it on the EDM/2.
You are asking, here is the answer: an application is very likely a 16-bit application if:
1) the documentation mentions that it is for OS/2 1.3
2) the DEF file uses the HEAPSIZE keyword. That is completely ignored by any 32-bit linker
3) the makefile is calling "link.exe". That is a 16-bit linker from Microsoft. A 16-bit linker cannot create 32-bit executables
4) the suspiciously frequent use of USHORT/SHORT/unsigned short/signed short variables. A 32-bit application typically uses 32-bit variables which show as ULONG/LONG/unsigned long/signed long/int (where "int" is ambiguous: it`s 16-bit for a 16-bit compiler and 32-bit for a 32-bit compiler ...)
5) a window function with a signature of (HWND hwnd,USHORT msg,MPARAM mp1,MPARAM mp2): a 32-bit window function uses (HWND hwnd,ULONG msg,MPARAM mp1,MPARAM mp2)
6) the use of the _loadds keyword in code: the _loadds keyword explicitely loads the data selector of the application's data segment into the DS register. That is completely superfluous for a 32-bit application as the program loader loads the flat selector into DS before it starts the application and the application will never ever change that selector, it is completely opaque to the application.
As you can see, gcc.exe even gets confused about this keyword which it does not even know, it thinks it's a syntax error ...
In fact, the only code that still requires 16-bit are drivers, where "drivers" include physical/storage device drivers (.SYS, .ADD, .FLT, .DMD, .OS2) and file system drivers (.IFS). That's because the main entry points into these drivers are still all 16-bit. If someone talks about a 32-bit device driver then in reality, it's a hybrid of 16-bit and 32-bit code where you need "thunking" (the process of jumping from a 16-bit code segment to a 32-bit code segment or the other way around) to call 32-bit code from 16-bit code.
-
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.
-
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
-
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 (http://Control Program Functions List)", 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
-
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.
-
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
-
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
-
Off topic I guess but I converted the mousdemo version to compile with Virtual Pascal:
-
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
-
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.
-
Hi Again
I have an issue with this old 1.x sample:
https://github.com/OS2World/DEV-SAMPLES-C-WinTree
I got this:
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
-
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.
--- 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)
);
-
Use %u instead of %p. Or, if you want hex output, use %x.
-
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()
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.
-
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
-
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.
-
Thanks Dave.
I had uploaded the changes to https://github.com/OS2World/DEV-SAMPLES-C-PM-WinTree
Regards
-
I'd suggest always adding -DOS2EMX_PLAIN_CHAR to CFLAGS.
-
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()
(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.
"l" stands explicitely for "long" as "h" explicitely stands for "short". For a 32-bit compiler you do not need to state "l" because that's the default. Likewise, for a 16-bit compiler, you do not need to state "h" as that's the default.
-
GCC disagrees, without the l,
gcc -Wall -Zomf -DOS2EMX_PLAIN_CHAR -c -O2 wintree.c -o wintree.obj
wintree.c: In function 'TraverseWindows':
wintree.c:150:26: warning: format '%X' expects argument of type 'unsigned int',
but argument 4 has type 'HWND' {aka 'long unsigned int'} [-Wformat=]
150 | sprintf(szLine,"%s%X...%s...%s",szLeader, hwndNext, szTitle, szClass);
| ~^ ~~~~~~~~
| | |
| unsigned int HWND {aka long unsigned int}
| %lX
The warning goes away with %lX.
-
Hi
Now I'm going after PMColour.
https://github.com/OS2World/DEV-SAMPLES-PM-PMColour
It compiled and works with the tools I decided to use. I just have this warning about a pointer that I don't know how to solve it.
gcc -Wall -Zomf -c -O2 pmcolour.c -o pmcolour.obj
pmcolour.c: In function 'DlgProc':
pmcolour.c:116:23: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
116 | *cwdata->rgb = *((RGB *) &mp1);
| ~^~~~~~~~~~~~~
gcc -Zomf pmcolour.obj pmcolour.res pmcolour.def -o pmcolour.exe
wrc pmcolour.res
Open Watcom Windows and OS/2 Resource Compiler Version 2.0beta1 LA
Portions Copyright (c) 1993-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Any tip is welcome.
Regards
-
Less optimization? Removing the -O2 from CFLAGS does remove the warning with the exe being the same size though likely slightly slower. Otherwise the fixes seem complex from searching the error.
Edit: reducing the optimization to -O1 also removes the warning. Or simply not doing the strict aliasing,
pmcolour.obj : pmcolour.c pmcolour.h
gcc -Wall -Zomf -c -O2 -Wno-strict-aliasing pmcolour.c -o pmcolour.obj
-
GCC disagrees, without the l,
gcc -Wall -Zomf -DOS2EMX_PLAIN_CHAR -c -O2 wintree.c -o wintree.obj
wintree.c: In function 'TraverseWindows':
wintree.c:150:26: warning: format '%X' expects argument of type 'unsigned int',
but argument 4 has type 'HWND' {aka 'long unsigned int'} [-Wformat=]
150 | sprintf(szLine,"%s%X...%s...%s",szLeader, hwndNext, szTitle, szClass);
| ~^ ~~~~~~~~
| | |
| unsigned int HWND {aka long unsigned int}
| %lX
The warning goes away with %lX.
Then gcc is a picky smartass.
-
Hi
Now I'm going after PMColour.
https://github.com/OS2World/DEV-SAMPLES-PM-PMColour
It compiled and works with the tools I decided to use. I just have this warning about a pointer that I don't know how to solve it.
gcc -Wall -Zomf -c -O2 pmcolour.c -o pmcolour.obj
pmcolour.c: In function 'DlgProc':
pmcolour.c:116:23: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
116 | *cwdata->rgb = *((RGB *) &mp1);
| ~^~~~~~~~~~~~~
gcc -Zomf pmcolour.obj pmcolour.res pmcolour.def -o pmcolour.exe
wrc pmcolour.res
Open Watcom Windows and OS/2 Resource Compiler Version 2.0beta1 LA
Portions Copyright (c) 1993-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Any tip is welcome.
Regards
First, try this: *cwdata->rgb = (RGB)mp1;
If that still does not work, then consult the gcc Compiler's manual and see how you can disable the "strict-aliasing" warning.
"-Wstrict-aliasing" enables it so maybe "-Wno-strict-aliasing" disables it. You will have to find out.
The story behind this warning: first you tell gcc that mp1 is of type MPARAM which effectively evaluates to ULONG aka unsigned long int.
That would mean that &mp1 is a pointer to unsigned long int. Then all of a sudden you tell it that &mp1 is a pointer to an RGB.
Since gcc is a picky smartass it tells you that it's not ok to first claim it is a pointer to an unsigned long int and later claim it is a pointer to an RGB.
-
Thanks for the reply and explanation of the warning.
First, try this: *cwdata->rgb = (RGB)mp1;
If I change it I get an error:
gcc -Wall -Zomf -c -O2 pmcolour.c -o pmcolour.obj
pmcolour.c: In function 'DlgProc':
pmcolour.c:117:3: error: conversion to non-scalar type requested
117 | *cwdata->rgb = (RGB)mp1;
| ^
make: *** [pmcolour.obj] Error 1
FYI: If I change the -02 to 01 or enable "-Wno-strict-aliasing", the warning is gone.
Regards
-
Hi
I'm trying the Wheel Sample: https://github.com/OS2World/DEV-SAMPLES-C-PM-Wheel
I wanted to try a sample with some DLLs. Even that I like the executable sample, it seems too old (compiled with Microsoft C ?) and too confusing with all DLLs and LIB that it includes.
I tried to create a make file to consolidate all the single makefiles, but I'm not sure if I'm doing it right.
I'm attaching my failed try.
[C:\DEV\DEV-SAMPLES-C-WHEEL]make 2>&1 | tee make.out
gcc -Wall -Zomf -c -O2 test.c -o test.obj
gcc -Zomf test.obj test.res test.def -o test.exe
weakld: error: Unresolved symbol (UNDEF) 'ColorWheelInitialize'.
weakld: info: The symbol is referenced by:
C:\dev\DEV-SAMPLES-C-Wheel\test.obj
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: ColorWheelInitialize is an undefined reference
file C:\dev\DEV-SAMPLES-C-Wheel\test.obj(test.obj): undefined symbol ColorWheelI
nitialize
make: *** [test.exe] Error 1
Regards.
-
Fixed your makefile (needs more work) but still get the unresolved symbol error for some reason, calling convention? The symbol is there.
--- makefile.orig 2023-05-10 15:37:46.000000000 -0700
+++ makefile 2023-05-10 16:03:22.000000000 -0700
@@ -6,18 +6,24 @@
# Make: nmake or GNU make
all : test.exe
-test.exe : test.obj test.res test.def
- gcc -Zomf test.obj test.res test.def -o test.exe
+test.exe : test.obj test.res test.def wheel.lib
+ gcc -Zomf -L. -lwheel test.obj test.res test.def -o test.exe
wrc test.res
wheel.dll : wheel.def wheel.dll
- gcc -Zomf wheel.obj wheel.res wheel.def -o wheel.dll
+ gcc -Zdll -Zomf wheel.obj wheel.res wheel.def -o wheel.dll
+
+wheel.lib : $(shell emximp -o wheel.lib wheel.def)
AllocMem.DLL : AllocMem.def AllocMem.obj AllocMem.res
- gcc -Zomf AllocMem.obj AllocMem.res AllocMem.def -o AllocMem.dll
+ gcc -Zdll -Zomf AllocMem.obj AllocMem.res AllocMem.def -o AllocMem.dll
+
+AllocMem.lib : $(shell emximp -o AllocMem.lib AllocMem.def)
telluser.dll : telluser.def telluser.obj
- gcc -Zomf telluser.obj telluser.def -o telluser.dll
+ gcc -Zdll -Zomf telluser.obj telluser.def -o telluser.dll
+
+telluser.lib : $(shell emximp -o telluser.lib telluser.def)
test.obj : test.c test.h wheel.h
gcc -Wall -Zomf -c -O2 test.c -o test.obj
@@ -38,4 +44,4 @@
wrc -r test.rc
clean :
- rm -rf *exe *RES *obj *hlp
+ rm -rf *exe *RES *obj *hlp *lib *LIB
Notes, need -Zdll when building a dll. $(shell runs a cmd. -L. search for libraries in these directories, dot in this case. -lwheel use the wheel library.
This is also fine,
-test.exe : test.obj test.res test.def
- gcc -Zomf test.obj test.res test.def -o test.exe
+test.exe : test.obj test.res test.def wheel.lib
+ gcc -Zomf wheel.lib test.obj test.res test.def -o test.exe
wrc test.res
-
OK, fixed the makefile to get further, lots of errors and warnings while compiling wheel.obj,
[code]
--- makefile.orig 2023-05-10 15:37:46.000000000 -0700
+++ makefile 2023-05-10 16:24:36.000000000 -0700
@@ -6,18 +6,24 @@
# Make: nmake or GNU make
all : test.exe
-test.exe : test.obj test.res test.def
- gcc -Zomf test.obj test.res test.def -o test.exe
+test.exe : test.obj test.res test.def wheel.lib wheel.dll
+ gcc -Zomf wheel.lib test.obj test.res test.def -o test.exe
wrc test.res
-wheel.dll : wheel.def wheel.dll
- gcc -Zomf wheel.obj wheel.res wheel.def -o wheel.dll
+wheel.dll : wheel.def wheel.obj
+ gcc -Zdll -Zomf wheel.obj wheel.res wheel.def -o wheel.dll
+
+wheel.lib : $(shell emximp -o wheel.lib wheel.def)
AllocMem.DLL : AllocMem.def AllocMem.obj AllocMem.res
- gcc -Zomf AllocMem.obj AllocMem.res AllocMem.def -o AllocMem.dll
+ gcc -Zdll -Zomf AllocMem.obj AllocMem.res AllocMem.def -o AllocMem.dll
+
+AllocMem.lib : $(shell emximp -o AllocMem.lib AllocMem.def)
telluser.dll : telluser.def telluser.obj
- gcc -Zomf telluser.obj telluser.def -o telluser.dll
+ gcc -Zdll -Zomf telluser.obj telluser.def -o telluser.dll
+
+telluser.lib : $(shell emximp -o telluser.lib telluser.def)
test.obj : test.c test.h wheel.h
gcc -Wall -Zomf -c -O2 test.c -o test.obj
@@ -38,4 +44,4 @@
wrc -r test.rc
clean :
- rm -rf *exe *RES *obj *hlp
+ rm -rf *exe *RES *obj *hlp *lib *LIB *dll *DLL
look better at it later.
-
Looking better, it seems that it will take some knowledge to port to 32 bit. Things like the semaphore far type I have no idea :)
-
Thanks for the makefile help.
Now I'm stuck is that "DOSFSRSEM"
gcc -Wall -Zomf -c -O2 wheel.c -o wheel.obj
wheel.c: In function 'ColorWheelInitialize':
wheel.c:401:14: error: unknown type name 'DOSFSRSEM'
401 | {static DOSFSRSEM dosfsrs; // Semaphore to block registratio
n
| ^~~~~~~~~
wheel.c:402:12: error: unknown type name 'DOSFSRSEM'
402 | typedef DOSFSRSEM FAR *PDOSFSRSEM;
| ^~~~~~~~~
wheel.c:408:7: warning: implicit declaration of function 'DosFSRamSemRequest' [-
Wimplicit-function-declaration]
408 | DosFSRamSemRequest (&dosfsrs, SEM_INDEFINITE_WAIT);
| ^~~~~~~~~~~~~~~~~~
wheel.c:429:7: warning: implicit declaration of function 'DosFSRamSemClear' [-Wi
mplicit-function-declaration]
429 | DosFSRamSemClear (&dosfsrs);
| ^~~~~~~~~~~~~~~~
make: *** [wheel.obj] Error 1
Regards
-
This is one of the points where it needs engineering judgement. DOSFRSEM (the various API functions: DosFSRamSemRequest etc.) implements a RAM semaphore and this is no longer supported with 32-bit OS/2 (the OS does no longer offer this, I guess this was decided in order to prevent undermining memory protection).
You will need to use Mutex semaphore instead. See Control Programming reference, search for "Mutex".
-
Thanks Lars. Seems that this sample will be hard for me to compile or even to try to port it to 32bits.
On a general thing I would like to have more documentation of which is the old API and which is the new one, to try to document it clearly on the EDM/2 wiki.
For the moment my reference is the EDM/2 wiki where I tried to separate the current CPI API from the 1.x one. http://www.edm2.com/index.php/Control_Program_Functions_(Summary)
But it would be very useful to have some source that says something like XXXX function had been replaced by xxxx function. I remember some old Magazine article with some partial documentation when OS/2 2.0 was released, but it was not much. Maybe it is under my nose, but I can not see it.
This article for example shows Semaphores functions on 1.x and 2.0: https://books.google.com.ec/books?id=NsgmyHnvDmUC&pg=PA428&redir_esc=y#v=onepage&q&f=false
Regards
-
One thing I have been doing is searching for these functions in WATCOM\h. For example, from WATCOM\h\os21x\bsedos.h
typedef struct _DOSFSRSEM {
USHORT cb;
PID pid;
TID tid;
USHORT cUsage;
USHORT client;
ULONG sem;
} DOSFSRSEM, FAR *PDOSFSRSEM;
Not the best documentation but at least it shows a function only exists in the 1.x API.
Also, I'd assume that Watcom could build the 16 bit examples.
-
Thanks Lars. Seems that this sample will be hard for me to compile or even to try to port it to 32bits.
On a general thing I would like to have more documentation of which is the old API and which is the new one, to try to document it clearly on the EDM/2 wiki.
For the moment my reference is the EDM/2 wiki where I tried to separate the current CPI API from the 1.x one. http://www.edm2.com/index.php/Control_Program_Functions_(Summary)
The 16-bit functions are all listed here: http://www.edm2.com/index.php/Category:Dos16
There might not be a staight 1:1 match between old 16-bit and new 32-bit.
Of course, you can still build the 16-bit examples. But you would not want to. If at all possible, convert them all to 32-bit. The only thing that comes to mind where you have to go through hoola hoops is when you try to run IOPL code (straight reads/write from/to IO ports). That still requires the core code to be 16-bit. And that in turn requires thunking so that you can call that from 32-bit code. But that's for another day (and I can provide example code as have done others).
-
The 16-bit functions are all listed here: http://www.edm2.com/index.php/Category:Dos16
Thanks Lars, in fact it was under my nose. I will check the samples and try to compare the DOS functions calls to see if something can be improved.
Regards
-
Hi
I'm trying to do a different thing now, instead of sample I want to compile a little PM game. I also want to compile it with gcc and see if it keeps working.
- https://github.com/OS2World/GAME-PUZZLE-PM_Robots
If I use wrc, it does not end the procedure. I have only this three warnings left that I don't know how to solve.
gcc -Wall -Zomf -c -O2 robots.c -o robots.obj
robots.c: In function 'ClientWndProc':
robots.c:77:27: warning: unused variable 'hwndScore' [-Wunused-variable]
77 | static HWND hwndMenu, hwndScore;
| ^~~~~~~~~
At top level:
robots.c:77:27: warning: 'hwndScore' defined but not used [-Wunused-variable]
gcc -Wall -Zomf -c -O2 game.c -o game.obj
game.c: In function 'NewLevel':
game.c:70:17: warning: implicit declaration of function 'AvailableMoves' [-Wimplicit-function-declaration]
70 | pgs->moves = AvailableMoves(*pgs);
| ^~~~~~~~~~~~~~
game.c: In function 'Direction':
game.c:244:1: warning: control reaches end of non-void function [-Wreturn-type]
244 | }
| ^
gcc -Wall -Zomf -c -O2 hiscores.c -o hiscores.obj
wrc -r robots.rc
Open Watcom Windows and OS/2 Resource Compiler Version 2.0beta4 LA GKYMar 2 2022
Portions Copyright (c) 1993-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
robots.rc(73): Error! E049: Syntax error near "CTEXT"
robots.rc(91): Error! E049: Syntax error near "CTEXT"
make: *** [robots.res] Error 8
If I switch to rc.exe it compiles, but the executable does gives a POPUPLOG error.
05-15-2023 12:18:41 SYS3171 PID 0250 TID 0001 Slot 0082
C:\DEV\GAME-PUZZLE-PM_ROBOTS\ROBOTS.EXE
c0000005
000104db
P1=00000002 P2=0002fffc P3=XXXXXXXX P4=XXXXXXXX
EAX=0000000d EBX=80000170 ECX=00010250 EDX=00000001
ESI=1b32e89c EDI=00031c80
DS=0053 DSACC=d0f3 DSLIM=9fffffff
ES=0053 ESACC=d0f3 ESLIM=9fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:000104db CSACC=d0df CSLIM=9fffffff
SS:ESP=0053:00030000 SSACC=d0f3 SSLIM=9fffffff
EBP=00030bc8 FLG=00010206
ROBOTS.EXE 0001:000004db
Any tip is welcome to see if this can compile. It seems that is also something that was from the 1.x era, i just want to see if it can easily be working under these conditions (gcc), otherwise I will move on.
Regards
-
These sys3171's seem to be caused by too small of a stack. Remove the stack directive from the def file and it uses the default of a 1MB stack and seems to run fine. I'd suggest usually going with the default stack size. Adding -Zmap to the LDFLAGS will show the stack size at the bottom,
+-----------------------+
| Linker Statistics |
+-----------------------+
Stack size: 00100000 (1048576.)
Memory size: 00103ab0 (1063600.)
Entry point address: 0001:00000000
Link time: 00:00.06
Not sure about the problem with wrc.
-
The rc needs some commas according to the help, under differences from the IBM Resource Compiler,
--- ROBOTS.RC.orig 2023-05-15 10:54:30.000000000 -0700
+++ ROBOTS.RC 2023-05-15 10:54:44.000000000 -0700
@@ -70,7 +70,7 @@
DIALOG "Help for Presentation Manager Robots",0,16,12,320,124,, FCF_TITLEBAR|FCF_DLGBORDER
{
CTEXT "Presentation Manager Robots" -1, 60, 108, 200, 8
- ICON ID_RESOURCE -1, 60, 100, 0, 0
+ ICON ID_RESOURCE, -1, 60, 100, 0, 0
CTEXT "Keep Smiley alive by keeping" -1, 10, 92, 300, 8
CTEXT "him away from the Killer Robots." -1, 10, 84, 300, 8
CTEXT "The left mouse button moves Smiley in the direction of the pointer
." -1, 10, 68, 300, 8
@@ -88,7 +88,7 @@
DIALOG "About Presentation Manager Robots",0,32,24,240,100,, FCF_TITLEBAR|FCF_DLGBORDER
{
CTEXT "Presentation Manager Robots v1.3" -1, 30, 84, 180, 8
- ICON ID_RESOURCE -1, 16, 76, 0, 0
+ ICON ID_RESOURCE, -1, 16, 76, 0, 0
CTEXT "This game is free software." -1, 30, 68, 180, 8
CTEXT "Copyright (c) 1993,1994 by Kent Lundberg" -1, 30, 58, 180, 8
CTEXT "Freely copy and distribute this program." -1, 20, 44, 200, 8
-
Thanks Dave
With you two suggestions, the game compiled.
It runs but sadly the functionality is not fully working. The smiley only goes to the left and the buttons on the menu are not working. (even if I tried the original source code without my changes to remove the warnings). So, this game requires more work to come from the 16bits world to be compiled with a 32bits gcc.
I will keep checking it out to see if something can be worked out, otherwise I will move on.
Thanks a lot.
-
...wait...wait... changing the USHORT for ULONG made the game work.
Seems to be working fine, the movement and the menus. I'm testing it right now. Nice.
Regards
-
Hi
I need some help to know how to remove this two warnings:
game.c:70:17: warning: implicit declaration of function 'AvailableMoves' [-Wimplicit-function-declaration]
70 | pgs->moves = AvailableMoves(*pgs);
| ^~~~~~~~~~~~~~
game.c: In function 'Direction':
game.c:244:1: warning: control reaches end of non-void function [-Wreturn-type]
244 | }
| ^
And also, I don't know why the game renders the "smiley face" and the "diamond" image wrong. If I open the BMP with PMView it looks fine, if I open it with the regular viewer, it looks wrong.
Regards
-
Using rc instead of wrc seems to fix it, though I'm not sure how the original looked.
One warning fix,
--- GAME.C.orig 2023-05-15 13:33:18.000000000 -0700
+++ GAME.C 2023-05-15 13:32:30.000000000 -0700
@@ -242,6 +242,7 @@
return (gs.moves&MOVE_DR ? IDP_DOWNRIGHT : IDP_NOMOVE);
}
+ return 0;
}
int AvailableMoves(GAMESTATE gs) {
-
Hi Dave
The one in the left is compiled by me, the one on the right is the original one.
The smiley face (and diamonds that around it) should be in color, but I don't know why they are downscale to two colors.
Regards
-
Almost seems like a different pallette is being used. Open the diamond.bmp or player.bmp and they're in black and white with 2 colours.
-
Almost seems like a different pallette is being used. Open the diamond.bmp or player.bmp and they're in black and white with 2 colours.
But if you open those files with PMView, they look in color, just like the image on the right.
Regards
-
Yes, when I open the folder, the colours are correct, if I then open them with the Picture Editor, they're in black and white.
I don't have PMView but IIRC, you can convert the images from OS/2 v1 bmp to OS/2 v2 bmp, might be worth trying, or changing the palette. I tried with Embelish but it crashed with a sys3175.
-
Hi
I still need to know why PM Robots does not want to show colors on some BMP files. I need to play with it further.
But for the moment I had compiled PM Maze.
https://github.com/OS2World/GAME-PUZZLE-PM_Maze
And Racer, but that is a command line app
https://github.com/OS2World/GAME-SPORTS-Racer
I fixed all errors and warning according to what I had learn here, and, in PM Maze, also by changing the USHORT to ULONG the program and the menus started working. It is working and the new binary is also on the github.
Regards
-
Hi
I'm trying this sample:
https://github.com/OS2World/DEV-SAMPLES-C-PM-Chain
But now I get this error with "chain.res". I checked the makefile but I'm not sure what I'm doing wrong.
gcc -Wall -Zomf -c -O2 chain.c -o chain.obj
chain.c: In function 'ClientWndProc':
chain.c:265:17: warning: implicit declaration of function 'SetupChain' [-Wimplicit-function-declaration]
265 | SetupChain();
| ^~~~~~~~~~
chain.c:285:50: warning: passing argument 1 of '_beginthread' from incompatible pointer type [-Wincompatible-pointer-types]
285 | if ( -1 == (tid = _beginthread ( runThread,
| ^~~~~~~~~
| |
| void (*)(CALCPARM *) {aka void (*)(struct <anonymous> *)}
In file included from chain.c:8:
C:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/stdlib.h:515:19: note: expected 'void (*)(void *)' but argument is of type 'void (*)(CALCPARM *)' {aka 'void (*)(struct <anonymous> *)'}
515 | int _beginthread (void (*)(void *), void *, unsigned, void *);
| ^~~~~~~~~~~~~~~~
chain.c: In function 'SetupDlgProc':
chain.c:488:16: warning: returning 'int' from a function with return type 'MRESULT' {aka 'void *'} makes pointer from integer without a cast [-Wint-conversion]
488 | return 1;
| ^
chain.c: In function 'SetupChain':
chain.c:448:1: warning: control reaches end of non-void function [-Wreturn-type]
448 | }
| ^
gcc -Wall -Zomf -c -O2 minsubs.c -o minsubs.obj
gcc -Zomf chain.obj minsubs.obj chain.def -o chain.exe
wrc chain.res
Error! E060: Can't find file "chain.res".
make: *** [chain.exe] Error 9
Some time with the final warnings will be appreciated too.
Regards
-
You forgot to add chain.res as a prerequisite for chain.exe.
chain.exe: chain.obj minsubs.obj chain.def chain.res
Now it trps with a sigsegv. The trp gets more informative with adding -g to CFLAGS and LDFLAGS. Fixing the warnings might be enough to fix it. Look later.
-
Thanks Dave, now it compiles, but like you said, it also traps here. Not sure if it can be possible to make it work :'(
-
I think the wrong parameters are fed to _beginthread(), mainly the pointer to runThread(PCALCPARM), but I'm not knowledgeable enough to know the fix.
-
Hi
I did a quick summary of the projects I was able to compile, and I took some time to include a screenshot of the samples I compiled. Here it is the list.
https://github.com/OS2World/DEV-SAMPLES-C-PM-MetaTest
https://github.com/OS2World/DEV-SAMPLES-C-PM-NBEZ
https://github.com/OS2World/DEV-SAMPLES-C-PM-Bug
https://github.com/OS2World/DEV-SAMPLES-C-PM-WindowTemplate
https://github.com/OS2World/DEV-SAMPLES-C-PM-Slider
https://github.com/OS2World/DEV-SAMPLES-C-PM-GPI-Bezier
https://github.com/OS2World/DEV-SAMPLES-C-PM-FastGPI
https://github.com/OS2World/DEV-SAMPLES-C-PM-PMColour
https://github.com/OS2World/DEV-SAMPLES-C-PM-MousDemo
https://github.com/OS2World/DEV-SAMPLES-C-PM-GPI-Revolve
https://github.com/OS2World/DEV-SAMPLES-C-PM-AirTrafficControlContainer
https://github.com/OS2World/DEV-SAMPLES-C-PM-CheckersBoard
https://github.com/OS2World/DEV-SAMPLES-C-PM-LBoxFont
https://github.com/OS2World/DEV-SAMPLES-C-PM-RandRect
https://github.com/OS2World/DEV-SAMPLES-C-PM-RunningBox
https://github.com/OS2World/DEV-SAMPLES-C-PM-PMHello
https://github.com/OS2World/DEV-SAMPLES-C-PM-VectFont
https://github.com/OS2World/DEV-SAMPLES-C-PM-PMWalker2
https://github.com/OS2World/DEV-SAMPLES-C-PM-BitCat
https://github.com/OS2World/DEV-SAMPLES-C-PM-WinTree
https://github.com/OS2World/DEV-SAMPLES-C-PM-ZoomBMP
https://github.com/OS2World/DEV-SAMPLES-C-PM-Slider_2
https://github.com/OS2World/GAME-PUZZLE-PM_Maze
https://github.com/OS2World/GAME-SPORTS-Racer (This is not PM)
Just in case, I saved on github's Releases, the old original version (source code and binaries if apply) and the new release that is compiled under my conditions (gcc, wrc, wl, make), so I'm not deleting any old material if someone wants to go back to different OS/2 version or tools.
I had been fun for the moment. I will check out some other samples.
Regards
-
Hi again
I moved on to this sample: https://github.com/OS2World/DEV-SAMPLES-C-PM-ctrldes
It compiles and runs, but I'm think I'm cheating here.
Seems like the goal of the sample is to generate a "controls.dll" file and "driver.exe" that should use that DLL. But I'm compiling driver.exe with everything inside it.
It seems that I don't know how to correctly generate a DLL with the makefile, and make the "exe" to link that.
Help with the makefile is appreciated on this case.
Regards
-
--- makefile.orig 2023-05-22 12:59:54.000000000 -0700
+++ makefile 2023-05-22 13:25:20.000000000 -0700
@@ -6,11 +6,14 @@
# Make: nmake or GNU make
all : driver.exe
-driver.exe : driver.obj Controls.obj driver.def
- gcc -Zomf driver.obj Controls.obj driver.def -o driver.exe
+driver.exe : driver.obj controls.lib driver.def
+ gcc -Zomf -Zmap -lcontrols driver.obj driver.def -o driver.exe
controls.dll : Controls.obj Controls.def
- gcc -Zdll -Zomf Controls.obj Controls.def -o Controls.DLL
+ gcc -Zdll -Zomf -Zmap Controls.obj Controls.def -o Controls.DLL
+
+controls.lib : Controls.obj Controls.def controls.dll
+ $(shell emximp -o controls.lib Controls.def)
driver.obj : driver.c Controls.h
gcc -Wall -Zomf -c -O2 driver.c -o driver.obj
@@ -19,4 +22,4 @@
gcc -Wall -Zomf -c -O2 Controls.c -o Controls.obj
clean :
- rm -rf *exe *RES *obj
\ No newline at end of file
+ rm -rf *exe *RES *obj *lib *dll
The -Zmap is optional. The -lcontrols can also be simply controls.lib
Controls.def file also needs
exports
InitControls
Still seems somewhat broken when executed
Edit: the def file also could be like the original,
EXPORTS InitControls @ 1
if you'd rather export by ordinal
-
Thanks Dave.
It compiled, created the DLL, LIB, EXE files and runs.
Does it looks broken? Maybe, the picture on the article shows the items on the PM window from left to right (Attached).
The article is here: https://archive.org/details/os2devmag/OS2DevMag-V5N2/page/n73
The only issue now when I compile is that "Circular driver.exe <- driver.exe dependency dropped."
[C:\DEV\DEV-SAMPLES-PM-CRTLDES]make 2>&1 | tee make.out
make: Circular driver.exe <- driver.exe dependency dropped.
gcc -Wall -Zomf -c -O2 driver.c -o driver.obj
gcc -Wall -Zomf -c -O2 controls.c -o controls.obj
gcc -Zdll -Zomf -Zmap controls.obj controls.def -o controls.dll
gcc -Zomf -Zmap -lcontrols driver.obj driver.def -o driver.exe
It is also interesting that it generates now a control.map and driver.map, which I guess it is some automatic documentation by the Open Watcom Linker.
Regards
-
OK, I guess it is correct. You must have left driver.exe in the prerequisites for driver.exe, at least I had to add it to get the circular dependency.
The map files come about from adding -Zmap. Handy for doing things like checking exports, which I added them for, other type of debugging or creating xqs files,
mapxqs driver.map
mapxqs Controls.map
Here's my full makefile, renamed to have .txt
-
Thanks Dave
I found the silly issue on the makefile comparing it to your file.
It is now done here: https://github.com/OS2World/DEV-SAMPLES-C-PM-ctrldes
Regards
-
Hi
I'm trying this sample:
https://github.com/OS2World/DEV-SAMPLES-C-PM-Chain
Hi Martin,
this is a perfect example where it sometimes makes sense to rewrite the whole thing. This thing was full of bugs (which had nothing to do with being a 16-bit application ...).
Find attached, it should now work.
Lars
-
Thanks Lars. Now it compiles and the program is hypnotic. ;D
I will put it on the github. Thanks.
Regards
-
Hi
CNRMENU sample compiled and runs without any major issues.
https://github.com/OS2World/DEV-SAMPLES-C-PM-CNRMENU
I just need some help with these warnings.
gcc -Wall -Zomf -c -O2 cnrmenu.c -o cnrmenu.obj
wrc -r cnrmenu.rc
Open Watcom Windows and OS/2 Resource Compiler Version 2.0beta4 LA GKYMar 2 2022
Portions Copyright (c) 1993-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
gcc -Wall -Zomf -c -O2 common.c -o common.obj
gcc -Wall -Zomf -c -O2 create.c -o create.obj
gcc -Wall -Zomf -c -O2 ctxtmenu.c -o ctxtmenu.obj
ctxtmenu.c: In function 'CtxtmenuSetView':
ctxtmenu.c:375:12: warning: 'strcat' accessing 281 or more bytes at offsets 412 and 692 may overlap 1 byte at offset 692 [-Wrestrict]
375 | (void) strcat( pi->szCnrTitle, pi->szDirectory );
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ctxtmenu.c:375:12: warning: 'strcat' accessing 281 or more bytes at offsets 412 and 692 may overlap 1 byte at offset 692 [-Wrestrict]
gcc -Wall -Zomf -c -O2 edit.c -o edit.obj
gcc -Wall -Zomf -c -O2 populate.c -o populate.obj
gcc -Wall -Zomf -c -O2 sort.c -o sort.obj
sort.c: In function 'DateCompare':
sort.c:192:38: warning: '%02u' directive writing between 2 and 3 bytes into a region of size between 1 and 3 [-Wformat-overflow=]
192 | (void) sprintf( szDate1,"%04u%02u%02u",date1.year, date1.month, date1.day );
| ^~~~
sort.c:192:29: note: directive argument in the range [0, 255]
192 | (void) sprintf( szDate1,"%04u%02u%02u",date1.year, date1.month, date1.day );
| ^~~~~~~~~~~~~~
sort.c:192:12: note: 'sprintf' output between 9 and 12 bytes into a destination of size 9
192 | (void) sprintf( szDate1,"%04u%02u%02u",date1.year, date1.month, date1.day );
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sort.c:193:38: warning: '%02u' directive writing between 2 and 3 bytes into a region of size between 1 and 3 [-Wformat-overflow=]
193 | (void) sprintf( szDate2,"%04u%02u%02u",date2.year, date2.month, date2.day );
| ^~~~
sort.c:193:29: note: directive argument in the range [0, 255]
193 | (void) sprintf( szDate2,"%04u%02u%02u",date2.year, date2.month, date2.day );
| ^~~~~~~~~~~~~~
sort.c:193:12: note: 'sprintf' output between 9 and 12 bytes into a destination of size 9
193 | (void) sprintf( szDate2,"%04u%02u%02u",date2.year, date2.month, date2.day );
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc -Zomf cnrmenu.obj common.obj create.obj ctxtmenu.obj edit.obj populate.obj sort.obj cnrmenu.def -o cnrmenu.exe
Warning! W1058: file lduyj05H.: line(26): protmode option not valid for an OS/2 EMX executable
wrc cnrmenu.res
Open Watcom Windows and OS/2 Resource Compiler Version 2.0beta4 LA GKYMar 2 2022
Portions Copyright (c) 1993-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Regards
-
Hi
This one compiled nice. I was able to remove the warnings.
https://github.com/OS2World/DEV-SAMPLES-C-PM-CNRDTL
Regards
-
Hello
On this one I'm not sure what I did wrong.
In file included from C:/usr/include/os2.h:39,
from cnrez.c:59:
C:/usr/include/os2emx.h:10843:3: error: unknown type name 'PDLGTEMPLATE'
10843 | PDLGTEMPLATE pdlgtPage;
| ^~~~~~~~~~~~
Here it is the original one just in case: https://github.com/OS2World/DEV-SAMPLES-C-PM-Containers/tree/master/cnrez
Regards
-
Looking at os2emx.h, the typedef is guarded by #if defined (INCL_WINDIALOGS) so the fix is,
--- CNREZ.C.orig 2023-05-26 17:16:48.000000000 -0700
+++ CNREZ.C 2023-05-26 17:16:14.000000000 -0700
@@ -51,6 +51,7 @@
#define INCL_WINSTDCNR
#define INCL_WINSTDDLGS
#define INCL_WINWINDOWMGR
+#define INCL_WINDIALOGS
/**********************************************************************/
/*----------------------------- INCLUDES -----------------------------*/
-
Thanks
It's done at: https://github.com/OS2World/DEV-SAMPLES-C-PM-CNREZ
Regards
-
Hi
Now I'm moving forward with the C PM Samples from the IBM toolkit (version 4.5).
I started with CLIPBDR.
I have this warnings that I'm not sure how to solve.
gcc -Wall -Zomf -c -O2 clipbrd.c -o clipbrd.obj
clipbrd.c:160:25: warning: missing braces around initializer [-Wmissing-braces]
160 | DRIVDATA drvdata[] = {44L, 0L, "DISPLAY", 0L};
| ^
| { { }}
clipbrd.c: In function 'PaintRoutine':
clipbrd.c:1042:12: warning: variable 'RC' set but not used [-Wunused-but-set-variable]
1042 | BOOL RC;
| ^~
clipbrd.c: In function 'SetSysMenu':
clipbrd.c:1580:7: warning: case label value exceeds maximum value for type
1580 | case SC_MOVE:
| ^~~~
clipbrd.c:1581:7: warning: case label value exceeds maximum value for type
1581 | case SC_CLOSE:
| ^~~~
Regards
-
Some of these warnings seem bogus. I played with the braces in the first warning, the warning only changed. The RC warning is obviously wrong as it is used a few lines down and removing it results in an error about it missing.
The case ones I don't understand, thought case was a keyword. They're the only warnings that show if -Wall is removed from CFLAGS.
-
Not having tried to compile this:
- 'drvdata' is declared as an array. So the initialisation should be something like {{44, 0, "DISPLAY", ""}} or {{44, 0, "DISPLAY", {0}}} I fail to see, why they use 'L' suffixes in the original source though.
- 'RC' is indeed not used. In line 1076 a value gets assigned, but nobody bothers to do something with it.
- 'SC_MOVE' and 'SC_CLOSE' have values of 0x800X. They are propagated to (signed)integers by the compiler. Thus they indeed exceed that range of variable 'id' in the switch statement, which is (signed) short.
Modern compilers like the gcc rarely produce bogus warnings. In almost any case these warnings have a reason. And -Wall should be considered as your friend, not your enemy. Old code like this will often trigger warnings when using recent tools.
-
Thanks Flashback.
- {{44, 0, "DISPLAY", {0}}} - Fixed the warning.
- I commented the RC declaration and assignation - Fixed the warning
I'm not sure what can I change for 'SC_MOVE' and 'SC_CLOSE' warnings.
Regards
-
Changing Id to a LONG at line 1562 is one solution.
As for the RC, ideally there should be some error checking there.
Edit: while the documentation shows using rc, the example doesn't and considering the possible errors, guess it isn't really needed to do error checking
-
The warning about RC is perfectly ok. It is being assigned a value, removing it will obviously lead to an error. But the assignment does not result in any consequences, hence the warning.
However, I often also do that in order to ease source code debugging and if an error would be very unlikely. It's easier to look at a variable then to look at registers (a function always places its result in EAX).
-
Thanks for your help
CLIPBRD now compiles without warnings.
https://github.com/OS2World/DEV-SAMPLES-C-PM-CLIPBRD
Regards
-
Also...
https://github.com/OS2World/DEV-SAMPLES-C-PM-Dialog
Removed warnings and works with gcc.
Regards
-
Hi
https://github.com/OS2World/DEV-SAMPLES-C-PM-STDWND-Hello
This one was also easy to remove the warnings.
Regards
-
Hello again.
Now I'm trying https://github.com/OS2World/DEV-DIVE-Show
It compiles, but when I run it, it close without any message on popuplog.
Regards
-
It's weird, supposed to show the help with no parameters,
int main ( int argc, char *argv[] )
{
HFILE hFile;
ULONG ulNumBytes, ulFileLength;
PBYTE pbImageBottom, pbBMP;
ULONG rc;
PBITMAPFILEHEADER2 pbmfHeader;
/* Check the number of command line arguments. */
if ( argc != 2 )
{
printf ( "usage: SHOW filein.bmp\n" );
printf ( " Jams ab 8-bit bitmap image directly to the upper\n" );
printf ( " left corner of the screen. Clipping is not exemplified.\n" )
;
printf ( " Note this code example works only if:\n" );
printf ( " 1) SMVDD.SYS is installed propery in four CONFIG.SYS\n" );
printf ( " (You can get this from the MMPM/2 install disks), and\n" );
printf ( " 2) Your adapter has an aperture enabled, and\n" );
printf ( " 3) Your adapter is in 8, 16, or 24 bit bit color mode, and\n" );
printf ( " 4) Your bitmap is 8-bit only (i.e. this does no color conv
ersion).\n" );
return ( 0 );
}
Looks like it also depends on SMVDD.SYS, which I don't see on my system
-
Hi.
I also don't have "SMVDD.SYS"
I found a reference on this book: https://komh.github.io/os2books/pdf/sg244627.pdf
(The Guide to OS/2 Warp Device Drivers. December 1995)
"This driver provides DOS and WIN-OS/2 digital video support. If you do not use DOS or WIN-OS/2 that require digital video support you can remove this driver from CONFIG.SYS."
Checking the readme it says:
SHOW.ZIP is an exectuable and source code which shows you how to
use DIVE (Direct Interface to Video Extensions) to directly
access the video display. It is useful for games and other apps
which need SPEED! You actually write directly to video memory.
It contains the following items:
L CMD sample linker file
DIRECT H fucntion prototypes
SHOW EXE program to display a bitmap
SHOW C source code for DIVE interface
SMVDD SYS Device driver to map addresses
CHICK BMP Bitmap
DIRECT C More DIVE code
C CMD Compiler batch file.
SMVDD.SYS - Device driver to map addresses ? uhm?? It does not mach the description.
Regards
-
Now the classic Hanoi Tower.
https://github.com/OS2World/DEV-SAMPLES-IBM_OS2_2-0_Toolkit/tree/master/C/SAMPLES/HANOI
It compiles and run fine. Removed all warnings.
But I lack experience with wipf to generate the .hlp file.
I get this error:
wipfc hanoi.ipf
Open Watcom OS/2 Help Compiler Version 2.0beta4 Limited Availability by GKYMar 2 2022
Copyright (c) 2010 Open Watcom Contributors. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
<hanoi.ipf:0:0> Fatal Error 10: Invalid language code
make: *** [hanoi.hlp] Error 255
Any tip of what may be wrong with wipfc or the .ipf file?
Regards
-
Try to force a localization of en_US (I suppose your LANG env var is set to something that wipfc does not understand):
wipfc -l en_US ....
-
Hi Lars
It gives me the same error with wipfc -l en_US.
wipfc -l en_US hanoi.ipf
Open Watcom OS/2 Help Compiler Version 2.0beta4 Limited Availability by GKYMar 2 2022
Copyright (c) 2010 Open Watcom Contributors. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
<hanoi.ipf:0:0> Fatal Error 10: Invalid language code
make: *** [hanoi.hlp] Error 255
Regards
-
Here, I got,
wipfc hanoi.ipf
Open Watcom OS/2 Help Compiler Version 2.0beta1 Limited Availability
Copyright (c) 2010 Open Watcom Contributors. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
<hanoi.ipf:125:1> Warning 31: Unable to find the id or name for this reference
<hanoi.ipf:133:1> Warning 31: Unable to find the id or name for this reference
<hanoi.ipf:141:1> Warning 31: Unable to find the id or name for this reference
<hanoi.ipf:149:1> Warning 31: Unable to find the id or name for this reference
<hanoi.ipf:157:1> Warning 31: Unable to find the id or name for this reference
<hanoi.ipf:165:1> Warning 31: Unable to find the id or name for this reference
and a hanoi.hlp file.
Note that I had to install watcom-wipfc with ANPM and it wanted a reboot before it worked. It added
SET WIPFC=W:\usr\share\os2\wipfc
to my config.sys.
Using ipfc, I see the warning,
Compiling document with following Country Code, Code Page:
1, 850
<hanoi.ipf:167> Warning 208: Missing tag [euserdoc]
Also I had to comment out this, as prodinfo.bmp is missing
/* BITMAP IDR_BITMAP "..\\prodinfo.bmp"*/
-
Hi Dave
You are right. I found an issue in my config.sys. I had a wipfc mess there.
Now it generates the .hlp and works, I also got the:
"<hanoi.ipf:125:1> Warning 31: Unable to find the id or name for this reference..."
..etc.
Regards
-
Hi Dave
You are right. I found an issue in my config.sys. I had a wipfc mess there.
Now it generates the .hlp and works, I also got the:
"<hanoi.ipf:125:1> Warning 31: Unable to find the id or name for this reference..."
..etc.
Regards
Probably should compare the wipf and ipfc help files. Wipf isn't 100% compatible and those warning might mean something. Not that it matters much with these example programs
-
Thanks Dave.
I need to read more about ipf file format.
Regards
-
Hi
I'm checking Jigsaw sample now.
https://github.com/OS2World/DEV-SAMPLES-C-PM-Jigsaw
It compiles, works and removed all warning, with the exception of this little one:
gcc -Wall -Zomf -c -O2 procs.c -o procs.obj
procs.c: In function 'WndProcPaint':
procs.c:205:10: warning: variable 'sRgnType' set but not used [-Wunused-but-set-variable]
205 | SHORT sRgnType;
| ^~~~~~~~
If I comment "SHORT sRgnType;" and "sRgnType = WinQueryUpdateRegion( hwndClient, hrgnUpdt); " the program gets unstable when opening a file. So, even if it tells me that it is "not used", if I remove it, the program will not work.
Regards
-
According to the Presentation Manager Programming Guide, sRgnType should be a long.
This call obtains an update region of a window.
#define INCL_WINWINDOWMGR /* Or use INCL_WIN, INCL_PM, */
#include <os2.h>
HWND hwnd; /* Handle of window whose update region is to be queried. */
HRGN hrgn; /* Handle of the window's update region. */
LONG lComplexity; /* Complexity of resulting region/error indicator. */
lComplexity = WinQueryUpdateRegion(hwnd, hrgn);
It's like the rc in a previous example, there could be "Complexity of resulting region/error indicator" checking later or can look at the variable in a debugger.
Considering the documentation shows the syntax shows using a variable like sRgnType, I'd leave it in even if it didn't hurt to remove it.
-
Hi.
I also don't have "SMVDD.SYS"
I found a reference on this book: https://komh.github.io/os2books/pdf/sg244627.pdf
(The Guide to OS/2 Warp Device Drivers. December 1995)
"This driver provides DOS and WIN-OS/2 digital video support. If you do not use DOS or WIN-OS/2 that require digital video support you can remove this driver from CONFIG.SYS."
Checking the readme it says:
SHOW.ZIP is an exectuable and source code which shows you how to
use DIVE (Direct Interface to Video Extensions) to directly
access the video display. It is useful for games and other apps
which need SPEED! You actually write directly to video memory.
It contains the following items:
L CMD sample linker file
DIRECT H fucntion prototypes
SHOW EXE program to display a bitmap
SHOW C source code for DIVE interface
SMVDD SYS Device driver to map addresses
CHICK BMP Bitmap
DIRECT C More DIVE code
C CMD Compiler batch file.
SMVDD.SYS - Device driver to map addresses ? uhm?? It does not mach the description.
Regards
One of the features of SMVDD.SYS is (or rather: was) to provide a function to map a physical address (in this case: the screen aperture) to a linear address valid in the caller's address space so that you can access the screen and write to it like you would write to memory. This functionality is also provided by SCREEN01.SYS and since SCREEN01.SYS is contained in any OS/2 system up to present day, SCREEN01.SYS is the correct pick.
It would take a bit of effort to adapt the code.
-
Thanks Lars.
In this case, I'm letting SHOW.ZIP to rest.
Regards
-
Hi
I thought I was done with JigSaw...
https://github.com/OS2World/DEV-SAMPLES-C-PM-Jigsaw
But I found that it has the "JIGHELP.RC" file that I'm not using in the makefile.
The program works, but I don't know what is the idea of the "JIGHELP.RC" file.
Regards
-
I change the jigsaw.res rule to,
jigsaw.res: jigsaw.rc jigsaw.h jigsaw.ico jighelp.rc jigsaw.dlg
wrc -r jigsaw.rc jighelp.rc
Based on JIGSAW.MAK.
I think it is to help open the help at the correct spot
-
Thanks Dave. Jigsaw now is fine with me.
https://github.com/OS2World/DEV-SAMPLES-C-PM-Jigsaw
I'm trying now this different "show" from the OS/2 Warp 4 Toolkit that works with DIVE.
https://github.com/OS2World/DEV-SAMPLES-IBM_Dev_Toolkit_Samples/tree/master/samples/mm/DIVE
I removed the warning, it compiles, but the image does not display on it.
Regards
-
Works fine here. I did have to adjust your compile.cmd (and a previous one) to be more portable. Basically changed all C: to %UNIXROOT%, which is W: here. Your binary also worked here
Do you have C:\mmos2\dll\dive.dll and is it on your libpath? I'm also running 64K colours if that makes a difference. What does Options-->Query Caps show?
BTW, the program really need slowing down on modern hardware, I'm getting over 18000 frames a second. It looks irritating.
-
Try "DosSleep(1)" instead of "DosSleep(0)" in the drawing thread. That should already slow down things considerably.
DosSleep(0) will only yield the CPU if there is another thread of same or higher prio in the ready state (ready and waiting to be doing work).
DosSleep(1) will yield the CPU if there is another thread of any prio in the ready state. Since you typically have a bunch of daemons etc. running in the background that also schedule threads of idle (very low) prio, that should always trigger a yield.
And yielding means to give away your time slice and it takes the OS ages (in computer terms) to regain a time slice/next chance to execute the thread.
Might still not be enough on a multi-core system (where you have multiple CPUs that could do work ...).
-
Yes, changing the DosSleep() to one at line 339 fixes the speed, about 33 frames/sec and can see the airplane on this 4 core I5.
-
Thanks for the feedback
Dave, I have DIVE.DLL on the libpath. I had tried in two enviroments, the development VM and a Thinkpad L420 and in both I can not see any image on the window.
I'm attaching the "Query Caps" of the Thinkpad L420. should I can try putting the colors on 64K?
Update: Indeed, I changed it to 64K and now I can see the image (very fast)
I will check Lars' suggestion to see if it slows down.
Regards
-
Hello
Thanks for the feedback. The show sample (Jet) is working fine.
https://github.com/OS2World/DEV-SAMPLES-C-PM-DIVE-ShowJet
My only question remains, why it does not work on 16M Colors? Is some limitation there that I don't know? I always used to set the colors to 16M and didn't have any problems that I can notice, until working with this sample.
Regards
-
Tested here with 16m colours, same results as you except one of the options, Dive Blitter I think it was, froze the system and after 10-15 seconds crashed,
06-05-2023 16:08:07 SYS3175 PID 0065 TID 0003 Slot 0080
H:\TMP\SHOW_DIVE_B1\SHOW.EXE
c0000005
1fe22505
P1=00000001 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX
EAX=02a83880 EBX=00000000 ECX=00000140 EDX=00000500
ESI=00000000 EDI=02a83880
DS=0053 DSACC=d0f3 DSLIM=9fffffff
ES=0053 ESACC=d0f3 ESLIM=9fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1fe22505 CSACC=d0df CSLIM=9fffffff
SS:ESP=0053:03271f20 SSACC=d0f3 SSLIM=9fffffff
EBP=03271ff4 FLG=00010202
LIBCN0.DLL 0001:00082505
Perhaps Lars has an idea.
-
My only question remains, why it does not work on 16M Colors?
Because support for 32bits per pixel is not fully implemented in DIVE. You may want to try the attached patch...
-
Thanks Flashback.
It run fine here with 16M Colors on the VM.
Regards
-
Hi
Now I'm trying framctlit is a nice sample.
https://github.com/OS2World/DEV-SAMPLES-C-PM-framctl
It compiles, and removed all warnings I can, but I still get this warning on framctl3.
gcc -Wall -Zomf -c -O2 framectl.c -o framectl.obj
framectl.c: In function 'FrameWndProc':
framectl.c:363:14: warning: unused variable 'rc' [-Wunused-variable]
363 | BOOL rc = (BOOL)DefFrameWndProc( hWnd, msg, mp1, mp2 );
| ^~
Even that is says the variable is unused, if I comment rc, the sample does not longer run. I need to keep this line and warning to have the sample working. Any ideas if there is something else I can do to remove this warning?
Regards
-
Add -Wno-unused-variable to the CFLAGS.
--- makefile.orig 2023-06-06 20:15:24.000000000 -0700
+++ makefile 2023-06-06 20:15:58.000000000 -0700
@@ -12,7 +12,7 @@
framectl.obj : framectl.c framectl.h
- gcc -Wall -Zomf -c -O2 framectl.c -o framectl.obj
+ gcc -Wall -Zomf -c -O2 -Wno-unused-variable framectl.c -o framectl.obj
framectl.res : framectl.rc
wrc -r framectl.rc
-
This works as well,
--- FRAMECTL.C.orig 2023-06-06 20:22:56.000000000 -0700
+++ FRAMECTL.C 2023-06-06 20:23:04.000000000 -0700
@@ -360,7 +360,7 @@
/******************************************************************/
/* Allow default proc to draw all of the frame. */
/******************************************************************/
- BOOL rc = (BOOL)DefFrameWndProc( hWnd, msg, mp1, mp2 );
+ DefFrameWndProc( hWnd, msg, mp1, mp2 );
/******************************************************************/
/* Get presentation space handle for drawing. */
But as Lars said, sometimes these variables should be left in as they may be needed for error checking at some point. The toolkit documentation often shows rc = foo()
-
Thanks Dave.
I made your changes and I think it is good enough for the sample.
It's done for me, and I posted it here to the public.
https://github.com/OS2World/DEV-SAMPLES-C-PM-framctl
Regards
-
Hi
Now I'm going after this one:
https://github.com/OS2World/DEV-SAMPLES-C-PM-ListBox2
I haven't fixed the warnings yet. I focused on having the program to compile first. After some effort DRIVER.EXE and LISTBOX.DLL are compiling, but DRIVER.EXE is not showing anything.
I get this on the POPUPLOG
06-07-2023 11:42:01 SYS2070 PID 017a TID 0001 Slot 0084
C:\DEV\DEV-SAMPLES-C-PM-LISTBOX2\DRIVER.EXE
DRIVER->LISTBOX.1
182
Any help to show the sample is welcome, if that can be possible, I will go after the warnings.
Regards
-
Your sys2070 says that there is something wrong with the 1st export, ordinal 1, in listbox.dll. Looking at LISTBOX.DEF, there are no exports. Looking at IBM.LNK, it references IBM.DEF which has this,
EXPORTS fRegisterListBox @ 1
solutions, add the above to the end of LISTBOX.DEF or copy IBM.DEF to LISTBOX.DEF or change the makefile to reference IBM.DEF. IBM.DEF will need the protmode option removed.
Personally I prefer using IBM.DEF, as it is for one of the IBM compilers.
-
I built the DLL with OW and then used it to link the GCC compiled driver.exe, worked fine except wmake did not like the backslash in the objs line. No warnings either.
Edit: the git patch. OS2World wouldn't let me upload the patch until I added a .txt. Seems patches should be allowed.
-
Thanks Dave
With your tip it compiles and the sample runs just using with gcc. I have a lot of warning that I have to check, I think I will turn crazy with the braces.
FYI: This little picture helps me with my English, I learned to code in C long time ago in Spanish. And it had been fun to re-learn that stuff.
-
Hi
I removed some of the warnings, and I think the sample is running as expected showing some listbox (I hope).
https://github.com/OS2World/DEV-SAMPLES-C-PM-ListBox2
I have these warnings that I need help to remove.
gcc -Wall -Zomf -c -O2 ListBox.c -o ListBox.obj
In file included from C:/usr/include/os2.h:39,
from ListBox.c:64:
ListBox.c: In function 'UpdateScrollBars':
ListBox.c:448:30: warning: operation on 'plbw->iVertScroll' may be undefined [-Wsequence-point]
448 | (plbw->iVertScroll = plbw->cVertScroll = 0) :
| ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
ListBox.c:472:27: warning: operation on 'plbw->iHorzScroll' may be undefined [-Wsequence-point]
472 | (plbw->iHorzScroll = plbw->iHorzScroll = 0) :
| ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
ListBox.c: In function 'ListBoxWndProc':
ListBox.c:2553:11: warning: suggest explicit braces to avoid ambiguous 'else' [-Wdangling-else]
2553 | if ( ((flStyle = WinQueryWindowULong(hWnd, QWL_STYLE)) & 0x0000ffffUL) != (plbw->flStyle & 0x0000ffffUL) )
| ^
Regards
-
Hi Again
These little animate samples compiled fine with gcc.
- https://github.com/OS2World/DEV-SAMPLES-C-PM-Animate
Also this "Select Font" window sample.
- https://github.com/OS2World/DEV-SAMPLE-C-PM-Font
Also this long listbox sample.
- https://github.com/OS2World/DEV-SAMPLES-C-PM-HugeLB
Regards
-
Hello
I tried this one,
https://github.com/OS2World/DEV-SAMPLES-C-PM-ShowBPM
It compiles but I get this error on POPUPLOG.
06-11-2023 20:38:56 SYS3175 PID 06ab TID 0001 Slot 0083
C:\DEV\4TRYING\DEV-SAMPLES-PM-SHOWBPM\SHOWBMP.EXE
c0000005
1fd2bb49
P1=00000002 P2=00032000 P3=XXXXXXXX P4=XXXXXXXX
EAX=fffffff2 EBX=00031d90 ECX=3fffff65 EDX=0000000b
ESI=1b36ca3d EDI=00031ffd
DS=0053 DSACC=d0f3 DSLIM=9fffffff
ES=0053 ESACC=d0f3 ESLIM=9fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1fd2bb49 CSACC=d0df CSLIM=9fffffff
SS:ESP=0053:00031cf4 SSACC=d0f3 SSLIM=9fffffff
EBP=00031d50 FLG=00010a07
PMMERGE.DLL 0004:0015bb49
Regards
-
Looking at the trp, I think this change you made is wrong,
@@ -76,8 +76,8 @@
if (pErr->offBinaryData) // Return code provided
{
- SELECTOROF (pRetCode) = SELECTOROF (pErr);
- OFFSETOF (pRetCode) = pErr->offBinaryData;
+ pRetCode = pErr ;
+ pRetCode = pErr->offBinaryData;
rc = *pRetCode; // Save return code
}
}
For the macros, os2def.h says,
/* Extract selector or offset from far pointer */
/* Warning:the selectorof macro should not be used*/
/* for 32 bit objects */
#define SELECTOROF(ptr) ((((ULONG)(ptr))>>13)|7)
#define OFFSETOF(p) (((PUSHORT)&(p))[0])
#endif /* !INCL_SAADEFS */
What the correct fix is, I don't have any idea. I assume the original was 16 bit
To create an informative trp, remove the def file from the link line and add -g to all the CFLAGS and LDFLAGS
Edit: The change was to UTILITY.C
-
I have not looked into the source code so I don't know what is already 32-bit flat pointer and what is still segmented, but try:
pRetcode = (PUSHORT)((PUCHAR)pErr + pErr->offBinaryData);
-
I have not looked into the source code so I don't know what is already 32-bit flat pointer and what is still segmented, but try:
pRetCode = (PUSHORT)((PUCHAR)pErr + pErr->offBinaryData);
Gets rid of the sigsegv but crashes with an error beep. Putting the def back results in the same sys3175 in popuplog.
Perhaps my guess was wrong or incomplete
-
That's not surprising as szFormat is not initialized which likely leads to a chrash in sprintf, all USHORTs should be converted to ULONGs and possibly some other minor probs.
-
Correction: szFormat is initialized dynamically via a resource (ridiculous). But because USHORTs are in use, the format string will likely not match the passed variables size. Therefore: convert the USHORT stuff to ULONG (rc and the like).
-
Hi
Sorry, I found a different issue with SHOWBPM that was confusing me. The "make clean" was not deleting the UTILITY.OBJ, and I was using an old one, that why I didn't get any warning/errors there, since it was linking the old one.
I will check on that and improve it replacing the SHORT for LONG and see what happens.
Regards
-
Here it is still crashing. Thinking about removing the def, the program no longer is a PM program. Forget how to morph a program, "exehdr /PMTYPE:PM showbmp.exe" does turn it back to a PM program.
-
Hi Again
This the far I can get with the SHOWBMP sample. I tried to remove the warnings I can, changed the SHORT for LONG.
It compiles, but it crashes on run.
Here is the POPUPLOG
06-12-2023 15:55:19 SYS3175 PID 0195 TID 0001 Slot 007d
C:\DEV\3NOSHOW\DEV-SAMPLES-PM-SHOWBPM\SHOWBMP.EXE
c0000005
1fd2bb49
P1=00000002 P2=00032000 P3=XXXXXXXX P4=XXXXXXXX
EAX=fffffff2 EBX=00031d90 ECX=3fffff65 EDX=0000000b
ESI=1b33ca3d EDI=00031ffd
DS=0053 DSACC=d0f3 DSLIM=9fffffff
ES=0053 ESACC=d0f3 ESLIM=9fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1fd2bb49 CSACC=d0df CSLIM=9fffffff
SS:ESP=0053:00031cf4 SSACC=d0f3 SSLIM=9fffffff
EBP=00031d50 FLG=00010a07
If you can suggest me something to make it run, it can be nice, otherwise if it is too much trouble and old, maybe it is time to move on.
Regards
-
Hello
Now I'm trying this BeeHive demo with gcc.
https://github.com/OS2World/DEV-SAMPLES-IBM_Dev_Toolkit_Samples/tree/b61beeafb1baec2d2ab3ff46ca90c0eb4d576986/samples/mm/BEEHIVE
It compiles, I removed some warnings, but the program crash on start without any popplog message.
I even tried, compiling before fixing the warnings and it didn't start also.
Dave, what is the trick to see the error? is that something specific the program should have to generate the .trp?
Regards
-
I tried running it in the debugger, seems that it tries to set up DIVE the way that other program did, which silently fails while seeming to succeed, then it cleanly exits.
Perhaps someone more knowledgeable can look at it, but I think it needs some rewriting to properly use DIVE in Warp
Previously I removed the def and got a trp, but not this time and really removing the def might need the program to morph to PM.
For getting the debug data, could just add -g to CFLAGS and LDFLAGS. I changed the makefile like so
--- makefile.orig 2023-06-14 15:22:06.000000000 -0700
+++ makefile 2023-06-14 15:47:28.000000000 -0700
@@ -4,23 +4,27 @@
# Compile::Resource Compiler
# Compile::GNU C
# Make: make
+
+CFLAGS=-Wall -Zomf -O2 -c
+DEBUGFLAGS=-g
+
all : beehive.exe
beehive.exe : beehive.obj animate.obj blitgen.obj pcxload.obj beehive.def beehi
ve.res
- gcc -Zomf -L. -lmmpm2 beehive.obj animate.obj blitgen.obj pcxload.obj beehive.def beehive.res -o beehive.exe
+ gcc $(DEBUGFLAGS) -Zomf -L. -lmmpm2 beehive.obj animate.obj blitgen.obj
pcxload.obj beehive.def beehive.res -o beehive.exe
wrc beehive.res
beehive.obj : beehive.c beehive.h
- gcc -Wall -Zomf -c -O2 beehive.c -o beehive.obj
+ gcc $(CFLAGS) $(DEBUGFLAGS) beehive.c -o beehive.obj
animate.obj : animate.c
- gcc -Wall -Zomf -c -O2 animate.c -o animate.obj
+ gcc $(CFLAGS) $(DEBUGFLAGS) animate.c -o animate.obj
blitgen.obj : blitgen.c
- gcc -Wall -Zomf -c -O2 blitgen.c -o blitgen.obj
+ gcc $(CFLAGS) $(DEBUGFLAGS) blitgen.c -o blitgen.obj
pcxload.obj : pcxload.c
- gcc -Wall -Zomf -c -O2 pcxload.c -o pcxload.obj
+ gcc $(CFLAGS) $(DEBUGFLAGS) pcxload.c -o pcxload.obj
beehive.res : beehive.rc
wrc -r beehive.rc
Usually the DEBUGFLAGS line can be commented out. This way it is easy to change the CFLAGS as well by passing CFLAGS/DEBUGFLAGS on the command line.
make 'DEBUGFLAGS=-Zmap -g' 2>&1 | tee make.out
In compile cmd gives a map file and debug data for example.
Edit: looking further, it does seem to load DIVE, though the code actually uses DosLoadModule to load GAMESRVR, which isn't on my system, yet the map file shows DIVE being used
-
Hi Dave
Edit: looking further, it does seem to load DIVE, though the code actually uses DosLoadModule to load GAMESRVR, which isn't on my system, yet the map file shows DIVE being used
The only thing that I found is that GAMESRVR (http://www.edm2.com/index.php/GameSrvr) is not longer available, seems that was embedded to DIVE since Warp 4.
DosLoadModule has two version the old 1.x and the newer one, but it seems to be called like the newer one.
Regards
-
Searching the os2tk45 toolkit, it is in samples\mm\fsdive as well as samples\mm\dll. dive.dll seems to pipe to it as well.
The "Help-Using Your Toolkit" (uselkt.inf) inf refers to it in the description of the FSDIVE Sample program.
-
FYI
These little samples compiled fine with gcc and the warnings were removed.
- https://github.com/OS2World/DEV-SAMPLES-C-PM-Wideline
- https://github.com/OS2World/DEV-SAMPLES-C-PM-Star
- https://github.com/OS2World/DEV-SAMPLES-C-PM-Pie
- https://github.com/OS2World/DEV-SAMPLES-C-PM-ClipPath
- https://github.com/OS2World/DEV-SAMPLES-C-PM-Rotline
I attached the screen shot on each repo.
Regards
-
Hi Again
Now I'm trying COLORS from:
https://github.com/OS2World/DEV-SAMPLES-The-IBM-Developer-Connection-Release-12/tree/893ec58ff58237281e533bff8f8bb26bc882674e/PMSAMPLE/COLORS
It didn't compiled because of a UNDEF of "WinWriteProfileData", and there was no documentation about it, I change it to "PrfWriteProfileData" (COLORS.C Line 151) and it compiled, but the application crash with...
06-17-2023 06:51:46 SYS3171 PID 0114 TID 0001 Slot 00a4
C:\DEV\DEV-SAMPLES-THE-IBM-DEVELOPER-CONNECTION-RELEASE-12\PMSAMPLE\COLORS\COLORS.EXE
c0000005
1fe0d1c8
P1=00000002 P2=0002fffc P3=XXXXXXXX P4=XXXXXXXX
EAX=00030e98 EBX=00000005 ECX=00030f4c EDX=00000000
ESI=00000002 EDI=00000000
DS=0053 DSACC=d0f3 DSLIM=9fffffff
ES=0053 ESACC=d0f3 ESLIM=9fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1fe0d1c8 CSACC=d0df CSLIM=9fffffff
SS:ESP=0053:00030000 SSACC=d0f3 SSLIM=9fffffff
EBP=00030ea8 FLG=00010246
LIBCN0.DLL 0001:0007d1c8
Any help is welcome.
Regards
-
Try the attached. I used VAC so you will need to replace with your own makefile.
-
Hi Dave
Edit: looking further, it does seem to load DIVE, though the code actually uses DosLoadModule to load GAMESRVR, which isn't on my system, yet the map file shows DIVE being used
The only thing that I found is that GAMESRVR (http://www.edm2.com/index.php/GameSrvr) is not longer available, seems that was embedded to DIVE since Warp 4.
DosLoadModule has two version the old 1.x and the newer one, but it seems to be called like the newer one.
Regards
Try the attached:
1) I compiled with VAC, you will need to use your makefile and maybe revert some stuff that VAC did not like but maybe gcc expects
2) the code tests for your OS version. If the version is WARP3, it uses GAMESRVR, if it is newer (true for us), it uses PMMERGE to find the same functionality that GAMESRVR offered. This is because Warp3 did not contain DIVE whereas >= Warp 4 did
3) the code computed time diff from one screen refresh to the next. It was so fast that the time diff was computed as 0 and then fps computation led to a trap because it tried to divide by time diff (being zero). I fixed that error and changed DosSleep(0) to DosSleep(1) and now it works ok
Lars
-
Hi Dave
Edit: looking further, it does seem to load DIVE, though the code actually uses DosLoadModule to load GAMESRVR, which isn't on my system, yet the map file shows DIVE being used
The only thing that I found is that GAMESRVR (http://www.edm2.com/index.php/GameSrvr) is not longer available, seems that was embedded to DIVE since Warp 4.
DosLoadModule has two version the old 1.x and the newer one, but it seems to be called like the newer one.
Regards
Try the attached:
1) I compiled with VAC, you will need to use your makefile and maybe revert some stuff that VAC did not like but maybe gcc expects
2) the code tests for your OS version. If the version is WARP3, it uses GAMESRVR, if it is newer (true for us), it uses PMMERGE to find the same functionality that GAMESRVR offered. This is because Warp3 did not contain DIVE whereas >= Warp 4 did
3) the code computed time diff from one screen refresh to the next. It was so fast that the time diff was computed as 0 and then fps computation led to a trap because it tried to divide by time diff (being zero). I fixed that error and changed DosSleep(0) to DosSleep(1) and now it works ok
Lars
Another fix.
-
Hi Lars.
Thanks for taking a look at it. I have compiled beehiveb3 with gcc, it compiles with warnings, but the .exe just keep crashing on execution.
Just in case here it is attached is your same code with my makefile. Even if I fix some of the warning, it still does not load.
Regards
-
Hi Lars.
About COLORS, your version worked with gcc, It was just missing on the DEF:
NAME COLORS WINDOWAPI
Seems to be working. I will check on the gcc warnings and upload it on the github.
Regards
-
Beehive doesn't actually crash here, trying to use a debugger, it sets up dive, reads the pcx files and then cleanly exits.
ULONG Initialize( VOID )
{
// Create a dive instance
//
ulrc = SetupDive();
if( ulrc )
return ulrc;
ulrc = ReadFile( (PSZ) "bee1.pcx", &bmpImage1 ); // bee moving right
ulrc += ReadFile( (PSZ) "bee1b.pcx", &bmpImage1b ); // bee moving right wit
ulrc += ReadFile( (PSZ) "bee2.pcx", &bmpImage2 ); // bee moving left
ulrc += ReadFile( (PSZ) "bee2b.pcx", &bmpImage2b ); // bee moving left with
ulrc += ReadFile( (PSZ) "honey.pcx", &bmpBackGround );
if( ulrc )
return ulrc;
Seems after the return ulrc it closes the dive instance, windows and cleanly exits.
Trying to trace into ReadFile() leads to CCLYDNOS2.5.S and idbug doesn't seem to want to step through the assembly.
Here's the debug build in case someone who knows debuggers wants to try figuring it out. Any native debugger should work
-
FYI
The gcc working version of COLORS is now on Github: https://github.com/OS2World/DEV-SAMPLES-C-PM-Colors
Thanks Lars.
Regards
-
Beehive doesn't actually crash here, trying to use a debugger, it sets up dive, reads the pcx files and then cleanly exits.
ULONG Initialize( VOID )
{
// Create a dive instance
//
ulrc = SetupDive();
if( ulrc )
return ulrc;
ulrc = ReadFile( (PSZ) "bee1.pcx", &bmpImage1 ); // bee moving right
ulrc += ReadFile( (PSZ) "bee1b.pcx", &bmpImage1b ); // bee moving right wit
ulrc += ReadFile( (PSZ) "bee2.pcx", &bmpImage2 ); // bee moving left
ulrc += ReadFile( (PSZ) "bee2b.pcx", &bmpImage2b ); // bee moving left with
ulrc += ReadFile( (PSZ) "honey.pcx", &bmpBackGround );
if( ulrc )
return ulrc;
Seems after the return ulrc it closes the dive instance, windows and cleanly exits.
Trying to trace into ReadFile() leads to CCLYDNOS2.5.S and idbug doesn't seem to want to step through the assembly.
Here's the debug build in case someone who knows debuggers wants to try figuring it out. Any native debugger should work
If you cannot debug into ReadFile, then something is going awfully wrong as it is part of the code.
WRC might be a problem: I ran into the problem that the VAC installation contained a very outdated version of RC that would create an invalid binary when binding the compiled resources to the executable. You can just use the toolkit supplied exehdr.exe to check the exe for the memory objects it contains.
Might be a prob with WRC also.
-
Hi Lars.
Thanks for taking a look at it. I have compiled beehiveb3 with gcc, it compiles with warnings, but the .exe just keep crashing on execution.
Just in case here it is attached is your same code with my makefile. Even if I fix some of the warning, it still does not load.
Regards
Try the exe that I built. If it works, you have a problem with compiling. If it does not work, then let me know how many colors your desktop uses. Mine uses 32-bit color resolution. Maybe you are using 256 colors (color palette) and that might be a problem with DIVE.
-
Hi Lars
I tried the compiled beehive.exe with different colors settings on my VM:
- with 16M does not run
- with 65K does not run
- with 256 does not run
What "does not run" means? it loads and exists quickly without showing anything on the screen. It does not produces any POPUPLOG. I don't know if I can take any other log.
Regards
-
Beehive doesn't actually crash here, trying to use a debugger, it sets up dive, reads the pcx files and then cleanly exits.
ULONG Initialize( VOID )
{
// Create a dive instance
//
ulrc = SetupDive();
if( ulrc )
return ulrc;
ulrc = ReadFile( (PSZ) "bee1.pcx", &bmpImage1 ); // bee moving right
ulrc += ReadFile( (PSZ) "bee1b.pcx", &bmpImage1b ); // bee moving right wit
ulrc += ReadFile( (PSZ) "bee2.pcx", &bmpImage2 ); // bee moving left
ulrc += ReadFile( (PSZ) "bee2b.pcx", &bmpImage2b ); // bee moving left with
ulrc += ReadFile( (PSZ) "honey.pcx", &bmpBackGround );
if( ulrc )
return ulrc;
Seems after the return ulrc it closes the dive instance, windows and cleanly exits.
Trying to trace into ReadFile() leads to CCLYDNOS2.5.S and idbug doesn't seem to want to step through the assembly.
Here's the debug build in case someone who knows debuggers wants to try figuring it out. Any native debugger should work
If you cannot debug into ReadFile, then something is going awfully wrong as it is part of the code.
WRC might be a problem: I ran into the problem that the VAC installation contained a very outdated version of RC that would create an invalid binary when binding the compiled resources to the executable. You can just use the toolkit supplied exehdr.exe to check the exe for the memory objects it contains.
Might be a prob with WRC also.
Using rc didn't help.
CCLYDNOS2.5.S is actually crt0.obj and things seem to hang with the debugger only responding to r (run) and the desktop frozen with only the one window of the debugger (idbug.exe) responsive.
It's possible it is a problem with the stack setup, GCC is not 100% compatible for debugging code. IIRC occasionally it uses the stack in a way the debugger doesn't expect.
Of course I am far from being knowledgeable about debugging.
-
Hi Lars
I tried the compiled beehive.exe with different colors settings on my VM:
- with 16M does not run
- with 65K does not run
- with 256 does not run
What "does not run" means? it loads and exists quickly without showing anything on the screen. It does not produces any POPUPLOG. I don't know if I can take any other log.
Regards
No popup complaining about not enough colours with 256 colours? Should be a WinMessageBox "usage: The sample program can not run on this system environment."
-
Hi Lars
I tried the compiled beehive.exe with different colors settings on my VM:
- with 16M does not run
- with 65K does not run
- with 256 does not run
What "does not run" means? it loads and exists quickly without showing anything on the screen. It does not produces any POPUPLOG. I don't know if I can take any other log.
Regards
Long story short: the executable that I attached works perfectly on my system. I am using eCS under Virtualbox. Even full screen support works but under Virtualbox, it does not make much sense (as it does not stretch across the full screen, of course).
I am using plain GENGRADD in the eCS guest (anything else will not improve performance anyways).
If you use Panorama: the problem is that Panorama and DIVE do not go together well. I think you will need to disable "shadow buffer". But of course, Panorama will then become totally unresponsive.
-
Just tried my built executable under Panorama: also works ok. Even with shadow buffer enabled. I am using 64k colors.
Also tried 16M colors, also works.
-
Hi Lars
I tried the compiled beehive.exe with different colors settings on my VM:
- with 16M does not run
- with 65K does not run
- with 256 does not run
What "does not run" means? it loads and exists quickly without showing anything on the screen. It does not produces any POPUPLOG. I don't know if I can take any other log.
Regards
The .PCX files need to be in the same directory as the EXE, of course.
-
Cannot get a working executable built with gcc. It just won't do whatever I try. VAC rules !
-
Ok, found the prob with gcc: the "fgetc" function as using in "ReadFile" seems to work differently in LIBC than for the VAC supplied library. It leads to an early abort when reading the file data. It might better be replaced by fread and reading only one character. Something is wrong with the "fgetc" function that LIBC provides ...
-
Hi Lars
I tried the compiled beehive.exe with different colors settings on my VM:
- with 16M does not run
- with 65K does not run
- with 256 does not run
What "does not run" means? it loads and exists quickly without showing anything on the screen. It does not produces any POPUPLOG. I don't know if I can take any other log.
Regards
Long story short: the executable that I attached works perfectly on my system. I am using eCS under Virtualbox. Even full screen support works but under Virtualbox, it does not make much sense (as it does not stretch across the full screen, of course).
I am using plain GENGRADD in the eCS guest (anything else will not improve performance anyways).
If you use Panorama: the problem is that Panorama and DIVE do not go together well. I think you will need to disable "shadow buffer". But of course, Panorama will then become totally unresponsive.
Actually, you didn't seem to attach an executable. Building your beehive_b3 with VACPP gives me a mostly working beehive.exe except the sprite isn't fully drawn, most noticeable when the sprite is moving left where it is just some dots. Full screen works as well.
What doesn't work is capturing a screen capture, get a grey screen.
I still see these warnings, which I'm not sure of the fix and may be the failure point, eg not reading the PCX files in binary mode would do it.
gcc -Wall -c -Zomf -g pcxload.c -o pcxload.obj
pcxload.c: In function 'ExtractPalette':
pcxload.c:61:26: warning: pointer targets in passing argument 1 of 'fopen' differ in signedness [-Wpointer-sign]
61 | if( ( pFile = fopen ( pszFile, "rb" ) ) == NULL )
| ^~~~~~~
| |
| PSZ {aka unsigned char *}
In file included from pcxload.c:28:
W:/usr/include/stdio.h:280:7: note: expected 'const char * restrict' but argument is of type 'PSZ' {aka 'unsigned char *'}
280 | FILE *fopen(const char * __restrict, const char * __restrict);
| ^~~~~
pcxload.c: In function 'ReadFile':
pcxload.c:246:26: warning: pointer targets in passing argument 1 of 'fopen' differ in signedness [-Wpointer-sign]
246 | if( ( pFile = fopen ( pszFile, "rb" ) ) == NULL )
| ^~~~~~~
| |
| PSZ {aka unsigned char *}
In file included from pcxload.c:28:
W:/usr/include/stdio.h:280:7: note: expected 'const char * restrict' but argument is of type 'PSZ' {aka 'unsigned char *'}
280 | FILE *fopen(const char * __restrict, const char * __restrict);
Here's the VACPP compiled binary, does it work for you Martin, might need to be run in the source directory
-
I did a final fix and now it correctly builds with gcc.
In the end, it was indeed a code error that needed to be fixed and funny enough it worked with VAC even though it should also have failed ...
Find the sources and the tweaked makefile attached.
-
Hi Lars
I tried the compiled beehive.exe with different colors settings on my VM:
- with 16M does not run
- with 65K does not run
- with 256 does not run
What "does not run" means? it loads and exists quickly without showing anything on the screen. It does not produces any POPUPLOG. I don't know if I can take any other log.
Regards
Long story short: the executable that I attached works perfectly on my system. I am using eCS under Virtualbox. Even full screen support works but under Virtualbox, it does not make much sense (as it does not stretch across the full screen, of course).
I am using plain GENGRADD in the eCS guest (anything else will not improve performance anyways).
If you use Panorama: the problem is that Panorama and DIVE do not go together well. I think you will need to disable "shadow buffer". But of course, Panorama will then become totally unresponsive.
Actually, you didn't seem to attach an executable. Building your beehive_b3 with VACPP gives me a mostly working beehive.exe except the sprite isn't fully drawn, most noticeable when the sprite is moving left where it is just some dots. Full screen works as well.
What doesn't work is capturing a screen capture, get a grey screen.
I still see these warnings, which I'm not sure of the fix and may be the failure point, eg not reading the PCX files in binary mode would do it.
gcc -Wall -c -Zomf -g pcxload.c -o pcxload.obj
pcxload.c: In function 'ExtractPalette':
pcxload.c:61:26: warning: pointer targets in passing argument 1 of 'fopen' differ in signedness [-Wpointer-sign]
61 | if( ( pFile = fopen ( pszFile, "rb" ) ) == NULL )
| ^~~~~~~
| |
| PSZ {aka unsigned char *}
In file included from pcxload.c:28:
W:/usr/include/stdio.h:280:7: note: expected 'const char * restrict' but argument is of type 'PSZ' {aka 'unsigned char *'}
280 | FILE *fopen(const char * __restrict, const char * __restrict);
| ^~~~~
pcxload.c: In function 'ReadFile':
pcxload.c:246:26: warning: pointer targets in passing argument 1 of 'fopen' differ in signedness [-Wpointer-sign]
246 | if( ( pFile = fopen ( pszFile, "rb" ) ) == NULL )
| ^~~~~~~
| |
| PSZ {aka unsigned char *}
In file included from pcxload.c:28:
W:/usr/include/stdio.h:280:7: note: expected 'const char * restrict' but argument is of type 'PSZ' {aka 'unsigned char *'}
280 | FILE *fopen(const char * __restrict, const char * __restrict);
Here's the VACPP compiled binary, does it work for you Martin, might need to be run in the source directory
Look here:
https://www.os2world.com/forum/index.php?action=dlattach;topic=3324.0;attach=9755
-
Hi Lars.
Your "beehive_b4.zip " compile fine here under gcc with some warnings (I will check on those later). Now it loads and works (VM with 16M colors). The only thing is that bee looks bad (Picture attached), which means the PCX of the bee are not rendering fine. If I go down to 64K colors, it is the same. Is that something in my machine?
But it is working now, that's good !!!
Regards
-
Hi
Here goes my beehive_b5.zip, removed the warnings.
I did something with this warning:
beehive.c:346:16: warning: variable 'hdc' set but not used [-Wunused-but-set-variable]
346 | static HDC hdc; // Device context for client window
| ^~~
hdc was used for:
hdc = WinOpenWindowDC( hwnd );
I just commented out "static HDC hdc;" leave it as
WinOpenWindowDC( hwnd );
It keeps running, but I'm not sure if I did something harmless.
Regards
-
reading the beehive readme, it sounded like the pictures are in fact "spotty".
There is another thing that showed up as a bug: the "rand" function is not reinitialized with the "seed" function. Which means, the "rand" function will always return the same result and therefore all bees will start to fly into the same direction.
Another fix to do ...
Funny enough, again, that worked with the VAC provided "rand". I assume that the VAC provided "rand" calls "seed" internally in case the programmer forgets ...
But the function definition of "rand" clearly states that you have to call "seed" every time before you call "rand" if you want to have random result.
-
Hi
Here goes my beehive_b5.zip, removed the warnings.
I did something with this warning:
beehive.c:346:16: warning: variable 'hdc' set but not used [-Wunused-but-set-variable]
346 | static HDC hdc; // Device context for client window
| ^~~
hdc was used for:
hdc = WinOpenWindowDC( hwnd );
I just commented out "static HDC hdc;" leave it as
WinOpenWindowDC( hwnd );
It keeps running, but I'm not sure if I did something harmless.
Regards
You can remove that whole call. The created hdc is not used anywhere in the code. A creating one without closing it is not a good idea anyways.
-
And here is the last shot. I fxed the "rand" problem. Now the bees start off in different directions (hit the "h" key ...).
Hit the "f" key for toggling between desktop and fullscreen mode.
-
Hello
I need a little help here with this TEMPLATE PM sample. It compiles with gcc and works, but with a trick, generating first the "main.res" and later compiling all together with the makefile.
I need to know how from main.rc can I generate template.res from the makefile (there is no template.rc).
I guess it is something very simple on the makefile that I don't know how to do.
Regards
-
Simple fix,
--- makefile.orig 2023-06-22 16:41:32.000000000 -0700
+++ makefile 2023-06-22 16:54:14.000000000 -0700
@@ -14,9 +14,9 @@
all : template.exe
-template.exe: $(OBJS)
- gcc -Zomf -Zmap $(OBJS) template.def main.res -o template.exe
- wrc main.res
+template.exe: $(OBJS) template.res
+ gcc -Zomf -Zmap $(OBJS) template.def template.res -o template.exe
+ wrc template.res
main.obj: main.c $(HEADER)
gcc $(CFLAGS) $(DEBUGFLAGS) main.c -o main.obj
@@ -45,8 +45,9 @@
thrd.obj: thrd.c $(HEADERS)
gcc $(CFLAGS) $(DEBUGFLAGS) thrd.c -o thrd.obj
-main.res: main.rc main.ico template.dlg help.rc prodinfo.bmp $(HEADERS)
+template.res: main.rc main.ico template.dlg help.rc prodinfo.bmp $(HEADERS)
wrc -r main.rc
+ mv main.res template.res
clean :
rm -rf *exe *res *obj *lib *.hlp
Perhaps better solution,
--- makefile.orig 2023-06-22 16:41:32.000000000 -0700
+++ makefile 2023-06-22 16:58:54.000000000 -0700
@@ -14,9 +14,9 @@
all : template.exe
-template.exe: $(OBJS)
- gcc -Zomf -Zmap $(OBJS) template.def main.res -o template.exe
- wrc main.res
+template.exe: $(OBJS) template.res
+ gcc -Zomf -Zmap $(OBJS) template.def template.res -o template.exe
+ wrc template.res
main.obj: main.c $(HEADER)
gcc $(CFLAGS) $(DEBUGFLAGS) main.c -o main.obj
@@ -48,5 +48,8 @@
main.res: main.rc main.ico template.dlg help.rc prodinfo.bmp $(HEADERS)
wrc -r main.rc
+template.res: main.res
+ $(shell mv main.res template.res)
+
clean :
rm -rf *exe *res *obj *lib *.hlp
Not sure if mv should have an argument or it could be cp instead, still might need an argument
Edit:fix typo
-
Reading up on it, we can make the makefile simpler,
# make makefile
#
# Tools used:
# Compile::Resource Compiler
# Compile::GNU C
# Make: make
CFLAGS=-Wall -Zomf -c -O2
DEBUGFLAGS=-g
#CFLAGS+=$(DEBUGFLAGS)
HEADERS = main.h xtrn.h help.c
OBJS = main.o user.o init.o pnt.o dlg.o help.o file.o edit.o thrd.o
ALL_IPF = template.ipf file.ipf edit.ipf help.ipf dlg.ipf menu.ipf
all : template.exe
template.exe: $(OBJS) template.res
gcc -Zomf -Zmap $(OBJS) template.def template.res -o $@
wrc template.res
main.res: main.rc main.ico template.dlg help.rc prodinfo.bmp $(HEADERS)
wrc -r main.rc
template.res: main.res
$(shell mv main.res template.res)
.PHONY : clean
clean :
rm -rf *exe *res *obj *.o *lib *.hlp *.map
The .PHONY thing is in case there is a file named clean and recommended.
To do is to have a debug target instead of commenting out the debugflags line.
Guess a help rule for the IPF's too
-
you can pick a different output name:
template.res: main.rc .....
wrc -q main.rc template.res
That would spare the additional file copy/rename.
-
Missed that, tried
-fo=name - set the output resource file to name
which seemed right but didn't work as expected.
wipfc seems to have a problem with importing ipf files.
This works as expected,
template.hlp: $(ALL_IPF)
ipfc template.ipf -o template.hlp
Can't get it to correctly import the ipf's with wipfc, lots of warnings and the help only shows the help for file, so it imports the first import and no more. Documentation is lacking
-
Thanks Dave, Lars
I changed the makefile (file attached) with the procedure and it works. I removed the gcc warnings.
Just these thing:
1)template.res: main.rc .....
wrc -q main.rc template.res
Did not work for me, not sure exactly what else to change.
2) wipfc also gave me the same issue..
Regards
-
Hello
About generating the HLP file, I was trying to get the most lazy way to update the IPF file so I can remove the warnings on wipfc.
Using "dlg.ipf", from the "Template sample", I imported it to VyperHelp (https://hobbes.nmsu.edu/download/pub/os2/dev/tools/help/VyperHelp_1-11.exe) (Open source) and exported it again as .IPF (like dlg2.ipf).
Check the difference picture attached. There are some interesting difference like it does not uses "name" and change it for "id"
If I run:
- wipfc dlg.ipf -o dlg.hlp
I get a lot of warnings and an error.
And running:
- wipfc dlg2.ipf -o dlg2.hlp
It works fine, no warnings, and generate the dlg2.hlp file.
Is there an old IPF format and newer one?
Regards
-
Hello
Here goes a funky one, the InkPS sample, it compiles, it works:
I got this warnings.
gcc -Wall -Zomf -c -O2 inkps.c -o inkps.obj
inkps.c: In function 'ClientWndProc':
inkps.c:244:35: warning: cast from pointer to integer of different size [-Wpoint
er-to-int-cast]
244 | newptlCur.x = (LONG) (SHORT) mp1;
| ^
inkps.c:292:35: warning: cast from pointer to integer of different size [-Wpoint
er-to-int-cast]
292 | newptlCur.x = (LONG) (SHORT) mp1;
| ^
If I fix it to "newptlCur.x = (LONG) mp1;"
The warnings are gone, the app will run, but the drawing mouse the area will not work.
Regards
-
This seems to work.
--- inkps.c.orig 2023-06-28 14:54:38.000000000 -0700
+++ inkps.c 2023-06-28 16:14:56.000000000 -0700
@@ -241,7 +241,7 @@
fButton1 = TRUE;
- newptlCur.x = (LONG) (SHORT) mp1;
+ newptlCur.x = (SHORT) (LONG) mp1;
newptlCur.y = (LONG) (SHORT) ((LONG) mp1 >> 16);
@@ -289,7 +289,7 @@
case WM_MOUSEMOVE:
if ( fButton1 && fInPath )
{
- newptlCur.x = (LONG) (SHORT) mp1;
+ newptlCur.x = (SHORT) (LONG) mp1;
newptlCur.y = (LONG) (SHORT) ((LONG) mp1 >> 16);
I'm not sure how casts actually work in C but it seems to me to be better to cast to a bigger variable, like SHORT to LONG then the other way where things might get truncated. Or in this case where the pointer is 32 bit, to cast to LONG, which IIRC is 32 bit whereas a SHORT is 16 bit and can't hold the whole pointer and gets truncated, high bits removed I assume.
Looking at the assembler output, my fix has the same assembler output as the original that GCC complained about. Your fix, were the mouse pointer stopped working resulted in somewhat different assembler output, here's the diff (attached) where inkps.new.S is the same as the original but with my patch and inkps.martin.S is your fix that broke the mouse.
Add -S to CFLAGS to get the assembly and change the name of the output if desired
-
Thanks Dave
The warnings are gone and the sample keeps working fine:
- https://github.com/OS2World/DEV-SAMPLES-C-PM-InkPS
I don't understand Assembly, but I didn't know you can produce that with gcc, good to know that. I will check to see what I can learn.
I also posted:
- https://github.com/OS2World/DEV-SAMPLES-C-PM-Template
- https://github.com/OS2World/DEV-SAMPLES-C-PM-DIVE-BeeHive
Thanks for your help.
-
Generally, C compilers create assembly and then assemble it, using as.exe in the case of GCC. Another handy thing is seeing the preprocessor output (cpp.exe), using -E, helps sometimes to see things like the include files or macro expansions.
-
Another problem is the use of C_INCLUDE_PATH in compile.cmd, after running it a few times,
[H:\tmp\inkps_b1]set C_INCLUDE_PATH
C_INCLUDE_PATH=W:/usr/include;W:\usr\include\os2tk45\inc;W:\usr\include\os2tk45\
gl;W:\usr\include\os2tk45;W:/usr/include;W:\usr\include\os2tk45\inc;W:\usr\inclu
de\os2tk45\gl;W:\usr\include\os2tk45;W:/usr/include;W:\usr\include\os2tk45\inc;W
:\usr\include\os2tk45\gl;W:\usr\include\os2tk45;W:/usr/include;W:\usr\include\os
2tk45\inc;W:\usr\include\os2tk45\gl;W:\usr\include\os2tk45;
Could remove the %C_INCLUDE_PATH% from the end but it is good practice to have it there. Could have a gccenv.cmd or such that is only run once and has the various SET commands. Or something like this,
--- makefile.orig 2023-06-28 19:35:40.000000000 -0700
+++ makefile 2023-06-28 19:45:14.000000000 -0700
@@ -11,7 +11,8 @@
wrc inkps.res
inkps.obj : inkps.c inkps.h
- gcc -Wall -Zomf -c -O2 inkps.c -o inkps.obj
+ gcc -Wall -Zomf -c -O2 -I/@unixroot/usr/include \
+ -I/@unixroot/usr/include/os2tk45 inkps.c -o inkps.obj
inkps.res : inkps.rc
wrc -r inkps.rc
So the makefile works standalone. The -I is the include search path and need to search usr/include first to avoid picking wrong include files, things break using the toolkits stdlib.h and such. The \ is a line continues thing to make it more readable.
-
This seems to work.
--- inkps.c.orig 2023-06-28 14:54:38.000000000 -0700
+++ inkps.c 2023-06-28 16:14:56.000000000 -0700
@@ -241,7 +241,7 @@
fButton1 = TRUE;
- newptlCur.x = (LONG) (SHORT) mp1;
+ newptlCur.x = (SHORT) (LONG) mp1;
newptlCur.y = (LONG) (SHORT) ((LONG) mp1 >> 16);
@@ -289,7 +289,7 @@
case WM_MOUSEMOVE:
if ( fButton1 && fInPath )
{
- newptlCur.x = (LONG) (SHORT) mp1;
+ newptlCur.x = (SHORT) (LONG) mp1;
newptlCur.y = (LONG) (SHORT) ((LONG) mp1 >> 16);
I'm not sure how casts actually work in C but it seems to me to be better to cast to a bigger variable, like SHORT to LONG then the other way where things might get truncated. Or in this case where the pointer is 32 bit, to cast to LONG, which IIRC is 32 bit whereas a SHORT is 16 bit and can't hold the whole pointer and gets truncated, high bits removed I assume.
Looking at the assembler output, my fix has the same assembler output as the original that GCC complained about. Your fix, were the mouse pointer stopped working resulted in somewhat different assembler output, here's the diff (attached) where inkps.new.S is the same as the original but with my patch and inkps.martin.S is your fix that broke the mouse.
Add -S to CFLAGS to get the assembly and change the name of the output if desired
Unfortunately, the handling of message WM_BUTTON1DOWN (as all the other WM_BUTTON... and WM_MOUSE... messages) is a bit convoluted as it did not go through "the shift from 16-bit to 32-bit".
And therefore:
POINTL newptlCur;
....
newptrlCur.x = (SHORT)SHORT1FROMMP(mp1);
newptlCur.y = (SHORT)SHORT2FROMMP(mp1);
The additional cast to (SHORT) is necessary because Dmitry Kuminov already found out that the SHORTnFROMMP macros do not properly cast the value to the signed type, that's why you have to do it.
The additional cast from SHORT to LONG should not be necessary as it is always ok to cast to a bigger type (unless you changed signedness !).
That's basically equivalent to what David has been doing but using the Macros gives a better clue of what you are actually accessing. They also properly cast from a pointer to an integer value (and therefore will avoid the gcc pointer cast warning).
Likewise for all the other WM_BUTTON... and WM_MOUSE.... messages.
-
Thanks for the corrections on InkPS. It is still working fine.
I followed Lars' advice with:
newptrlCur.x = (SHORT)SHORT1FROMMP(mp1);
newptlCur.y = (SHORT)SHORT2FROMMP(mp1);
Works fine with no warnings.
And Dave, you are right that sometime the INCLUDES on compile.cmd gave me problems on the CMD session. I didn't know that you can add the "INCLUDE" on the gcc calls, good learning for me.
I tried to use some variables on the makefile like:
# make makefile
#
# Tools used:
# Compile::Resource Compiler
# Compile::GNU C
# Make: make
CFLAGS=-Wall -Zomf -c -O2
DEBUGFLAGS=-g
INC=-I/@unixroot/usr/include -I/@unixroot/usr/include/os2tk45
all : inkps.exe
inkps.exe : inkps.obj inkps.def inkps.res
gcc -Zomf inkps.obj inkps.def inkps.res -o inkps.exe
wrc inkps.res
inkps.obj : inkps.c inkps.h
gcc $(CFLAGS) $(INC) inkps.c -o inkps.obj
inkps.res : inkps.rc
wrc -r inkps.rc
clean :
rm -rf *exe *res *obj *lib
Regards
-
Good, it is nice that running make standalone works. Could also do it this way, both work.
--- makefile.orig 2023-06-30 19:38:02.000000000 -0700
+++ makefile 2023-06-30 19:44:36.000000000 -0700
@@ -8,6 +8,7 @@
CFLAGS=-Wall -Zomf -c -O2
DEBUGFLAGS=-g
INC=-I/@unixroot/usr/include -I/@unixroot/usr/include/os2tk45
+CFLAGS += $(INC)
all : inkps.exe
@@ -16,7 +17,7 @@
wrc inkps.res
inkps.obj : inkps.c inkps.h
- gcc $(CFLAGS) $(INC) inkps.c -o inkps.obj
+ gcc $(CFLAGS) inkps.c -o inkps.obj
inkps.res : inkps.rc
wrc -r inkps.rc
Also see that DEBUGFLAGS is unused. Should be able to do "make debug" to get a debug version. This works.
--- makefile.orig 2023-06-30 19:38:02.000000000 -0700
+++ makefile 2023-06-30 19:41:08.000000000 -0700
@@ -6,11 +6,15 @@
# Make: make
CFLAGS=-Wall -Zomf -c -O2
-DEBUGFLAGS=-g
+DEBUGFLAGS=-g -Og
INC=-I/@unixroot/usr/include -I/@unixroot/usr/include/os2tk45
all : inkps.exe
+debug : CFLAGS += $(DEBUGFLAGS)
+
+debug : inkps.obj inkps.exe
+
inkps.exe : inkps.obj inkps.def inkps.res
gcc -Zomf inkps.obj inkps.def inkps.res -o inkps.exe
wrc inkps.res
GCC uses the last optimization flag on the command line, -Og for "make debug". -Og optimizes in a debugger friendly way.
-
Hi
This is a very basic question that I don't know. When you compile it as "make debug", does the exe file generate some kind of debug log? where is it stored?
Regards
-
Hi
This is a very basic question that I don't know. When you compile it as "make debug", does the exe file generate some kind of debug log? where is it stored?
Regards
It defaults to being stored in the binary, unless stripped. Lxlite is a good stripper,
H:\tmp\inkps_b2>lxlite inkps.exe
┌[ lxLite ]───────────────────────────────────┬[ Version 1.3.9 ]┐
├ Copyright 1996,97 by FRIENDS software ├ All rights ┤
├ Copyright 2001,03 by Max Alekseyev ├ reserved ┤
├ Copyright 2008-10 by OS/4 team ├ ┤
├ Copyright 2011 by Steven H. Levine ├ ┤
├ Copyright 2017-23 by bww bitwise works GmbH └─────────────────┘
├ The file inkps.exe contains 9992 bytes of debug information
├ inkps.exe initial: 23213 final: 6054 gain: 74.0%
├┤Total gain: 17159 bytes
It is possible to have a separate debug file, means messing with the linker cmd line. Need to remember how.
Generally there is no need for the debug version unless someone wants to use a debugger or if getting trps, the debug data makes the trps more informative.
Not sure why we hardly ever get trps, perhaps the PM exception handler gets first dibs when an exception happens.
-
OK, the symfile option is one way to do it, I think it only works with wlink and needs to invoked on the link command like this,
-Zlinker "option symfile=inkps.dbg"
A little harder to make it work with "make debug", more variables like this seems to work,
--- makefile.orig 2023-06-30 19:38:02.000000000 -0700
+++ makefile 2023-07-02 21:24:22.000000000 -0700
@@ -5,14 +5,24 @@
# Compile::GNU C
# Make: make
+EXEEXT=.exe
+PRGNAME=inkps
CFLAGS=-Wall -Zomf -c -O2
-DEBUGFLAGS=-g
+LDFLAGS=-Zomf
+DEBUGCFLAGS=-g -Og
+DEBUGLDFLAGS=-Zlinker "option symfile=$(PRGNAME).dbg"
INC=-I/@unixroot/usr/include -I/@unixroot/usr/include/os2tk45
-all : inkps.exe
+all : $(PRGNAME)$(EXEEXT)
-inkps.exe : inkps.obj inkps.def inkps.res
- gcc -Zomf inkps.obj inkps.def inkps.res -o inkps.exe
+debug : CFLAGS += $(DEBUGCFLAGS)
+
+debug : LDFLAGS += $(DEBUGLDFLAGS)
+
+debug : inkps.obj $(PRGNAME)$(EXEEXT)
+
+$(PRGNAME)$(EXEEXT) : inkps.obj inkps.def inkps.res
+ gcc $(LDFLAGS) inkps.obj inkps.def inkps.res -o $(PRGNAME)$(EXEEXT)
wrc inkps.res
inkps.obj : inkps.c inkps.h
@@ -22,4 +32,4 @@
wrc -r inkps.rc
clean :
- rm -rf *exe *res *obj *lib
\ No newline at end of file
+ rm -rf *exe *res *obj *lib *dbg
Seems simpler for these simple programs to leave the debug stuff in the binary
-
IMO for a most simple programs it's not worth to make a non-debug build. The difference in file size is often not worth thinking to remove debug stuff. During development you usually want to have debugging information. Of course when you fire up a debugger and want to do source code debugging. But even in release program versions it's often helpful to have debugging data to some extend in the .exe. F.i. line numbers in conjunction with the map file can often point directly to failing code line.
Suggestions - build and ship with full debugging code (compiler and linker). Only when the exe size becomes to big or you've some very time critical parts in your program, start playing with less debug settings.
-
Interestingly, the linker doesn't seem to need -g. Based on testing and also looking at the emxomfld source where unless -s is passed, the debug format is kept. Haven't looked at how GCC calls emxomfld lately but if I remember correctly, it does not pass the -s option.
-
Hello
I wanted to try to compile something bigger, but I think I have problems with the makefile.
https://github.com/OS2World/UTIL-FILE-NewFileManager
I get this issue:
gcc -Zomf -Zmap nfm.obj nfm.def nfm.res -o nfm.exe
weakld: error: Unresolved symbol (UNDEF) '_CSPCSTA4'.
weakld: info: The symbol is referenced by:
C:\dev\5TRYING\UTIL-FILE-NewFileManager\nfm.obj
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: _CSPCSTA4 is an undefined reference
file C:\dev\5TRYING\UTIL-FILE-NewFileManager\nfm.obj(nfm.c): undefined symbol _CSPCSTA4
make: *** [nfm.exe] Error 1
Help is appreciated to know what I'm doing wrong.
Regards
-
Hello
I wanted to try to compile something bigger, but I think I have problems with the makefile.
https://github.com/OS2World/UTIL-FILE-NewFileManager
I get this issue:
gcc -Zomf -Zmap nfm.obj nfm.def nfm.res -o nfm.exe
weakld: error: Unresolved symbol (UNDEF) '_CSPCSTA4'.
weakld: info: The symbol is referenced by:
C:\dev\5TRYING\UTIL-FILE-NewFileManager\nfm.obj
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: _CSPCSTA4 is an undefined reference
file C:\dev\5TRYING\UTIL-FILE-NewFileManager\nfm.obj(nfm.c): undefined symbol _CSPCSTA4
make: *** [nfm.exe] Error 1
Help is appreciated to know what I'm doing wrong.
Regards
Lots wrong, not linking to the DLLs, wrc options not pointing out that we're dealing with a dll are some.
Here's one solution linking against the export libs by name, could also do something like -lnfmlib etc.
--- makefile.orig 2023-07-13 22:25:30.000000000 -0700
+++ makefile 2023-07-13 22:45:26.000000000 -0700
@@ -10,13 +10,16 @@
HEADERS = caoj2i03.h caoj2i04.h csoj2i0a.h csoj2i0h.h csoj2i0i.h csoj2i0j.h csoj2i0k.h csoj2i0l.h cspcsta3.h cspcsta4.h nfm.h nfmlib.h perfutil.h
OBJS = nfm.obj nfmlib.obj csoj2i0a.obj csoj2i0k.obj csoj2i0j.obj csoj2i0h.obj caoj2i03.obj caoj2i04.obj csoj2i0i.obj cspcsta3.obj cspcsta4.obj
+LIBS = nfmlib.lib csoj2i0a.lib csoj2i0k.lib csoj2i0j.lib csoj2i0h.lib \
+ caoj2i03.lib caoj2i04.lib csoj2i0i.lib csoj2i0l.lib cspcsta4.lib \
+ cspcsta3.lib
ALL_IPF =
INC=-I/@unixroot/usr/include -I/@unixroot/usr/include/os2tk45
all : nfm.exe
-nfm.exe: nfm.obj nfm.res nfm.def $(HEADERS)
- gcc -Zomf -Zmap nfm.obj nfm.def nfm.res -o $@
+nfm.exe: nfm.obj nfm.res nfm.def $(HEADERS) $(LIBS)
+ gcc -Zomf -Zmap -L. $(LIBS) nfm.obj nfm.def nfm.res -o $@
wrc nfm.res
nfm.obj: nfm.c nfm.h nfm.def $(HEADERS)
@@ -29,9 +32,9 @@
nfmlib.obj : nfmlib.c nfmlib.h
gcc $(CFLAGS) $(DEBUGFLAGS) $(INC) nfmlib.c -o nfmlib.obj
-nfmlib.dll : nfmlib.obj nfmlib.def
+nfmlib.dll : nfmlib.obj nfmlib.def nfmlib.res
gcc -Zdll -Zomf -Zmap $(INC) nfmlib.obj nfmlib.def -o nfmlib.dll
- wrc nfmlib.res
+ wrc nfmlib.res nfmlib.dll
nfmlib.lib : nfmlib.obj nfmlib.def nfmlib.dll
$(shell emximp -o nfmlib.lib nfmlib.def)
@@ -42,9 +45,9 @@
csoj2i0a.obj : csoj2i0a.c csoj2i0a.h
gcc $(CFLAGS) $(DEBUGFLAGS) $(INC) csoj2i0a.c -o csoj2i0a.obj
-csoj2i0a.dll : csoj2i0a.obj csoj2i0a.def
- gcc -Zdll -Zomf -Zmap $(INC) csoj2i0a.obj csoj2i0a.def -o csoj2i0a.dll
- wrc csoj2i0a.res
+csoj2i0a.dll : csoj2i0a.obj csoj2i0a.def csoj2i0a.res
+ gcc -Zdll -Zomf -Zmap -lmmpm2 $(INC) csoj2i0a.obj csoj2i0a.def -o csoj2i0a.dll
+ wrc csoj2i0a.res csoj2i0a.dll
csoj2i0a.lib : csoj2i0a.obj csoj2i0a.def csoj2i0a.dll
$(shell emximp -o csoj2i0a.lib csoj2i0a.def)
Also need a leading underscore in the export in cspcsta4.def,
EXPORTS _CSPCSTA4 @1
After this I get a working nfm.exe
ps to patch, IIRC,
%UNIXROOT%\usr\bin\patch.exe -p0 < makefile.diff
Got to avoid the patch.exe in \os2.
Edit: PS, the header and obj lines should also use a backslash to split into multiple lines like I did with the libs line to be more readable.
--- makefile.orig 2023-07-13 23:15:08.000000000 -0700
+++ makefile 2023-07-13 23:15:56.000000000 -0700
@@ -8,8 +8,10 @@
CFLAGS=-Wall -Zomf -c -O2
DEBUGFLAGS=-g
-HEADERS = caoj2i03.h caoj2i04.h csoj2i0a.h csoj2i0h.h csoj2i0i.h csoj2i0j.h csoj2i0k.h csoj2i0l.h cspcsta3.h cspcsta4.h nfm.h nfmlib.h perfutil.h
-OBJS = nfm.obj nfmlib.obj csoj2i0a.obj csoj2i0k.obj csoj2i0j.obj csoj2i0h.obj caoj2i03.obj caoj2i04.obj csoj2i0i.obj cspcsta3.obj cspcsta4.obj
+HEADERS = caoj2i03.h caoj2i04.h csoj2i0a.h csoj2i0h.h csoj2i0i.h csoj2i0j.h \
+ csoj2i0k.h csoj2i0l.h cspcsta3.h cspcsta4.h nfm.h nfmlib.h perfutil.h
+OBJS = nfm.obj nfmlib.obj csoj2i0a.obj csoj2i0k.obj csoj2i0j.obj csoj2i0h.obj \
+ caoj2i03.obj caoj2i04.obj csoj2i0i.obj cspcsta3.obj cspcsta4.obj
LIBS = nfmlib.lib csoj2i0a.lib csoj2i0k.lib csoj2i0j.lib csoj2i0h.lib \
caoj2i03.lib caoj2i04.lib csoj2i0i.lib csoj2i0l.lib cspcsta4.lib \
cspcsta3.lib
-
Thanks Dave.
I followed your instructions with the makefile , and it also compiles and works here.
But I don't understand this part:
ps to patch, IIRC,
%UNIXROOT%\usr\bin\patch.exe -p0 < makefile.diff
Got to avoid the patch.exe in \os2.
To be honest I haven't used patch.exe never, I was changing the makefile at hand.
This is to automatically make the update/changes on the makefile, right?
What is your technique to generate the changes between makefile.orig and the current makefile as you are attaching on the forum ?
Regards
-
Thanks Dave.
I followed your instructions with the makefile , and it also compiles and works here.
But I don't understand this part:
ps to patch, IIRC,
%UNIXROOT%\usr\bin\patch.exe -p0 < makefile.diff
Got to avoid the patch.exe in \os2.
To be honest I haven't used patch.exe never, I was changing the makefile at hand.
This is to automatically make the update/changes on the makefile, right?
Yes, it could also be a patch for the whole directory. Options include --dry-run, to see what will happen with no actual changes. Git format patches need -p1 instead of -p0, it is related to the depth of the subdirectory. For large patches it doesn't hurt to capture the output by redirecting stdout and stderr. If the patch fails, it will leave files like makefile.org and makefile.rej so you can revert or fix by hand.
What is your technique to generate the changes between makefile.orig and the current makefile as you are attaching on the forum ?
Yes, to catch the changes, something like cp makefile makefile.orig (could be makefile.bak or whatever), then after making changes,
diff -u makefile.orig makefile > makefile.patch
Can also do whole directories, cp newfilemanager/ newfilemanager.orig or such, then from above the directory,
diff -ru newfilemanager/ newfilemanager.orig/ > newfilemanager.diff
Which made a huge patch here. Make clean did not clean everything is the big problem, in both directories. There's other options such as -w to ignore white space, which IIRC includes line endings
diff --help | less to see all the options
There's also git diff, svn diff and such to create similar patches that can be applied much the same way tasking care with the -p parameter. Patch will let you know if it can't find the files to patch or ask about a reversed patch if already applied. Reversed patching undoes a patch, see the help.
-
FYI:
I updated this two on github.
- https://github.com/OS2World/DEV-SAMPLES-C-PM-Simple
- https://github.com/OS2World/UTIL-FILE-NewFileManager
Both compiles and works with gcc. I will work slowly with NewFileManager to see if I can remove all warnings.
Regards
-
FYI
On this I also removed the warnings, compiled with gcc and keeps working
- https://github.com/OS2World/DEV-SAMPLES-C-PM-NBBASE
Regards
-
Hello
Now I'm with this sample: https://github.com/OS2World/DEV-SAMPLES-C-PM-CNRMENU
Can I have some suggestion on how to fix this warnings?
gcc -Wall -Zomf -c -O2 ctxtmenu.c -o ctxtmenu.obj
ctxtmenu.c: In function 'CtxtmenuSetView':
ctxtmenu.c:375:12: warning: 'strcat' accessing 281 or more bytes at offsets 412 and 692 may overlap 1 byte at offset 692 [-Wrestrict]
375 | (void) strcat( pi->szCnrTitle, pi->szDirectory );
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ctxtmenu.c:375:12: warning: 'strcat' accessing 281 or more bytes at offsets 412 and 692 may overlap 1 byte at offset 692 [-Wrestrict]
gcc -Wall -Zomf -c -O2 edit.c -o edit.obj
gcc -Wall -Zomf -c -O2 populate.c -o populate.obj
gcc -Wall -Zomf -c -O2 sort.c -o sort.obj
sort.c: In function 'DateCompare':
sort.c:192:38: warning: '%02u' directive writing between 2 and 3 bytes into a region of size between 1 and 3 [-Wformat-overflow=]
192 | (void) sprintf( szDate1,"%04u%02u%02u",date1.year, date1.month, date1.day );
| ^~~~
sort.c:192:29: note: directive argument in the range [0, 255]
192 | (void) sprintf( szDate1,"%04u%02u%02u",date1.year, date1.month, date1.day );
| ^~~~~~~~~~~~~~
sort.c:192:12: note: 'sprintf' output between 9 and 12 bytes into a destination of size 9
192 | (void) sprintf( szDate1,"%04u%02u%02u",date1.year, date1.month, date1.day );
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sort.c:193:38: warning: '%02u' directive writing between 2 and 3 bytes into a region of size between 1 and 3 [-Wformat-overflow=]
193 | (void) sprintf( szDate2,"%04u%02u%02u",date2.year, date2.month, date2.day );
| ^~~~
sort.c:193:29: note: directive argument in the range [0, 255]
193 | (void) sprintf( szDate2,"%04u%02u%02u",date2.year, date2.month, date2.day );
| ^~~~~~~~~~~~~~
sort.c:193:12: note: 'sprintf' output between 9 and 12 bytes into a destination of size 9
193 | (void) sprintf( szDate2,"%04u%02u%02u",date2.year, date2.month, date2.day );
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Regards
-
This works,
diff -ur cnrmenu_b1.orig/CNRMENU.H cnrmenu_b1/CNRMENU.H
--- cnrmenu_b1.orig/CNRMENU.H 2023-05-23 17:23:18.000000000 -0700
+++ cnrmenu_b1/CNRMENU.H 2023-07-20 16:35:18.000000000 -0700
@@ -125,7 +125,7 @@
// Used to keep track of frame windows associated with OtherWindow menuitems
HWND hwndFrame[ IDM_OTHERWIN_LASTITEM - IDM_OTHERWIN_ITEM1 + 1 ];
- CHAR szCnrTitle[ CCHMAXPATH + 20 ]; // Container title
+ CHAR szCnrTitle[ CCHMAXPATH + 19 ]; // Container title
CHAR szDirectory[ CCHMAXPATH + 1 ]; // Directory being displayed
CHAR achWorkBuf[ CCHMAXPATH + 1 ]; // Instance work buffer
diff -ur cnrmenu_b1.orig/SORT.C cnrmenu_b1/SORT.C
--- cnrmenu_b1.orig/SORT.C 2023-06-09 15:19:50.000000000 -0700
+++ cnrmenu_b1/SORT.C 2023-07-20 16:27:14.000000000 -0700
@@ -184,7 +184,7 @@
{
CDATE date1 = ((PCNRITEM) prc1)->date;
CDATE date2 = ((PCNRITEM) prc2)->date;
- CHAR szDate1[ 9 ], szDate2[ 9 ];
+ CHAR szDate1[ 12 ], szDate2[ 12 ];
INT iResult;
pv = pv; // to keep the compiler happy
But not really sure about making szCnrTitle smaller. Making the date larger should be fine, maybe waste 3 bytes *2. Running both I don't see a difference running the executables.
-
Thanks Dave
It compiles, it works. I just got this warning now:
gcc -Wall -Zomf -c -O2 ctxtmenu.c -o ctxtmenu.obj
ctxtmenu.c: In function 'CtxtmenuSetView':
ctxtmenu.c:375:12: warning: 'strcat' accessing 280 or more bytes at offsets 412
and 691 may overlap 1 byte at offset 691 [-Wrestrict]
375 | (void) strcat( pi->szCnrTitle, pi->szDirectory );
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ctxtmenu.c:375:12: warning: 'strcat' accessing 280 or more bytes at offsets 412
and 691 may overlap 1 byte at offset 691 [-Wrestrict]
Regards
-
Looks like I screwed up and didn't do a make clean.
This part of the patch is unneeded,
- CHAR szCnrTitle[ CCHMAXPATH + 20 ]; // Container title
+ CHAR szCnrTitle[ CCHMAXPATH + 19 ]; // Container title
The makefile should have referenced cnrmenu.h on the first line of the recipe at line 22,
ctxtmenu.obj : ctxtmenu.c cnrmenu.h
gcc -Wall -Zomf -c -O2 ctxtmenu.c -o ctxtmenu.obj
So that when I touched the header a rebuild of ctxtmenu.obj should be triggered. Not sure how to fix the warning.
-
The problem is that szDirectory is a character array of 260 bytes and szCnrTitle is a byte array that is shorter. Gcc can detect that. Either you make szCnrTitle at least as large as szDirectory or you just ignore it.
-
The problem is that szDirectory is a character array of 260 bytes and szCnrTitle is a byte array that is shorter. Gcc can detect that. Either you make szCnrTitle at least as large as szDirectory or you just ignore it.
I see this,
CHAR szCnrTitle[ CCHMAXPATH + 20 ]; // Container title
CHAR szDirectory[ CCHMAXPATH + 1 ]; // Directory being displayed
-
Then, gcc computed that concatenation via strcat might overflow from szCnrTitle into szDirectory. In that case, szCnrTitle has to be the theoretical maximum of the string length that could result from concatenation. You either have to likely double the size of szCnrTitle or use pointers pointing to array locations in order to trick the compiler in giving up on determining maximum string lengths.
-
Seems to be a bug in GCC, doubling the size didn't help but removing the optimization got rid of the warning. -O1 or -Os (optimize for size) or -Og (optimize in debugger friendly way) also gets rid of the warning, -O3 of course doesn't. Too lazy to try to figure out which optimization that -O2 uses triggered the problem. I'd suggest changing the optimization of ctxmenu.c to -O1.
-
Thanks for the feedback.
I'm leaving "CNRMENU" on the github repo:
https://github.com/OS2World/DEV-SAMPLES-C-PM-CNRMENU
Regards
-
Hello
Now I'm trying this sample: https://github.com/OS2World/DEV-SAMPLES-The-IBM-Developer-Connection-Release-12/tree/master/PMSAMPLE/MOUSPLAY
It compiles and runs, but it seems that it does not do what it offers. I guess you have to put the X and Y coordinates and it will move the mouse pointer there, press a click and even put some text. But it does not work for me.
It also has two warnings of some variables that I'm not sure if does something.
Regards
-
Hi, the warnings are simple, need to include stdlib.h.
--- mousplay.h.orig 2023-07-29 22:10:56.000000000 -0700
+++ mousplay.h 2023-07-29 22:30:46.000000000 -0700
@@ -5,6 +5,7 @@
#define INCL_WIN
#include <OS2.h>
#include <process.h>
+#include <stdlib.h>
/*---------------------------------------------------------------------------+
| Dialog defines |
+---------------------------------------------------------------------------*/
Searching @unixroot/usr/include will often show the header that has the prototype, beginthread in this case.
Compile failed here with,
wrc -r mousplay.rc
Open Watcom Windows and OS/2 Resource Compiler Version 2.0beta1 LA
Portions Copyright (c) 1993-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
mousplay.h(9): Error! E062: Unable to open 'process.h'
make: *** [makefile:35: mousplay.res] Error 9
Which is caused by wrc not understanding GCC include options, fixed by adding %UNIXROOT%\usr\include to %INCLUDE%, perhaps something that should be done in config.sys.
It crashes here in pmmerge after entering the coordinates and text.
______________________________________________________________________
Call Stack
______________________________________________________________________
EBP Address Module Obj:Offset Nearest Public Symbol
-------- --------- -------- ------------- -----------------------
Trap -> 1FC06AAE PMMERGE 0004:00116AAE between XQueryWindowText + 12 and
WSetWindowULong - 10E
0012FE98 1FC04B5F PMMERGE 0004:00114B5F between WIN32QUERYWINDOWTEXT + 2F
and CalcUpdate - 15
0012FEDC 1FBF59F9 PMMERGE 0004:001059F9 between WIN32DISPATCHMSG + F5 and
CheckLoseBoost - 1B
0012FF28 00010759 MOUSPLAY 0001:00000759 mousplay.c#59 main + 99 0001:0000
06C0 (mousplay.c)
Offset Name Type Hex Value
────── ──────────────────── ──────────────────────────── ─────────
32 qmsg 0x202 0
0012FF78 00010027 MOUSPLAY 0001:00000027 crt0.s#90 __text + 27 0001:000000
00 (D:\Temp\ccLyDNo2.s)
0012FFE0 1FDC811B LIBCN0 0001:0003811B unwind-pe.h#201 ___gcc_personalit
y_v0 - 47 0001:00038162 (unwind-c.obj)
16 bit code failure??
-
The makefile is also weird. To build the exe, you are linking against the import lib twice and also the obj file used to build the dll. I fixed with,
--- makefile.orig 2023-07-29 22:58:40.000000000 -0700
+++ makefile 2023-07-29 23:15:18.000000000 -0700
@@ -16,7 +16,7 @@
all : mousplay.exe mousedll.dll
mousplay.exe: mousedll.obj mousplay.obj mousplay.def mousplay.res $(HEADERS) $(LIBS)
- gcc -Zomf -Zmap -lmousedll $(LIBS) mousedll.obj mousplay.obj mousplay.def mousplay.res -o $@
+ gcc -Zomf -Zmap $(LIBS) mousplay.obj mousplay.def mousplay.res -o $@
wrc mousplay.res
mousplay.obj: mousplay.c mousplay.h $(HEADERS)
Could have gone with -lmousedll instead of $(LIBS).
Then we get undefined symbol errors, fixed by updating the def,
--- mousedll.def.orig 2023-07-29 23:16:30.000000000 -0700
+++ mousedll.def 2023-07-29 23:24:36.000000000 -0700
@@ -12,11 +12,11 @@
DATA MULTIPLE NONSHARED
-;EXPORTS
-;MousePlayHookProc @1
-;KeyPlayHookProc @2
-;Thmq @3
-;sXCoordinate @4
-;sYCoordinate @5
-;PlayString @6
+EXPORTS
+MousePlayHookProc @1
+KeyPlayHookProc @2
+_Thmq @3
+_sXCoordinate @4
+_sYCoordinate @5
+_PlayString @6
Still crashes though :(
-
Hi Dave
Thanks for the feedback. This is strange, I did the changes, and it compiled fine. Now it does not want to compile, I'm not sure what I screwed up.
Also, when it runs, the exe does not shows on the "taskbar", it shows on TOP, was there some other trick to make it show there?
I found inside MOUSPLAY.DLG a reference to "DLGINCLUDE 1 "RAFAEL.H"" but not sure if it is related to some issue.
Regards
-
Hi Martin, somehow in MOUSPLAY_B2 mousedll.c is 0 bytes. Once I restored it, it compiled fine, still crashed.
-
Seems you changed WinQueryDlgItemShort() to WinQueryDlgItemText(), changing it back gets rid of the crash but the program still doesn't seem to work and leaves the DLL loaded. Possibly the DEF needs adjusting to use INITGLOBAL TERMGLOBAL like how it was? I'll test later.
--- mousplay.c.orig 2023-07-30 09:48:22.000000000 -0700
+++ mousplay.c 2023-07-30 13:19:58.000000000 -0700
@@ -7,9 +7,9 @@
/*************************************************************************/
/* Move and play related variables */
/*************************************************************************/
-extern LONG sXCoordinate; /* Make coordinates extern to share */
-extern LONG sYCoordinate; /* with the hook DLL */
-extern CHAR PlayString[]; /* DLL definition of character string */
+extern PSHORT sXCoordinate; /* Make coordinates extern to share */
+extern PSHORT sYCoordinate; /* with the hook DLL */
+extern PSZ PlayString[]; /* DLL definition of character string */
ULONG EXPENTRY MousePlayHookProc(HAB habSpy,BOOL fSkip, PQMSG pQmsg); /* 4 */
ULONG EXPENTRY KeyPlayHookProc(HAB habSpy,BOOL fSkip, PQMSG pQmsg); /* 4 */
ULONG TextLen;
@@ -70,9 +70,9 @@
/* hook */
/***********************************************************/
- if( !WinQueryDlgItemText( hwndDlg, EF_X, (LONG) &sXCoordinate, FALSE ))
+ if( !WinQueryDlgItemShort( hwndDlg, EF_X, (PSHORT)&sXCoordinate, FALSE ))
sXCoordinate=0;
- if( !WinQueryDlgItemText( hwndDlg, EF_Y, (LONG) &sYCoordinate, FALSE ))
+ if( !WinQueryDlgItemShort( hwndDlg, EF_Y, (PSHORT)&sYCoordinate, FALSE ))
sYCoordinate=0;
TextLen=WinQueryDlgItemText( hwndDlg,ID_CHARPLAY, 79, (PSZ) PlayString);
TstTID=_beginthread(PlayThread,0,STACKSIZE,0);
-
Thanks Dave. I don't know how I lost mousedll.c. Now it compiles without error and warnings, but , yes, still does not work.
I changed the INITGLOBAL TERMGLOBAL on mousedll, but no improvement.
Regards
-
Hello.
I just get back to compile an extra little thing. It compiles and works.
Can you please give me a hand with this warning?
gcc -Wall -Zomf -c -O2 pmstars.c -o pmstars.obj
pmstars.c: In function 'ClientWndProc':
pmstars.c:60:16: warning: variable 'my_timer' set but not used [-Wunused-but-set-variable]
60 | static ULONG my_timer; /* System (PM) number indicating unique (system) timer number
| ^~~~~~~~
Regards
-
Hello.
I just get back to compile an extra little thing. It compiles and works.
Can you please give me a hand with this warning?
gcc -Wall -Zomf -c -O2 pmstars.c -o pmstars.obj
pmstars.c: In function 'ClientWndProc':
pmstars.c:60:16: warning: variable 'my_timer' set but not used [-Wunused-but-set-variable]
60 | static ULONG my_timer; /* System (PM) number indicating unique (system) timer number
| ^~~~~~~~
Regards
Hi Martin, the warning simply states the my_timer variable is never used. Just to be extra sure, search for it into the source code and if it is really never used (as I expect to happen), you can safely comment out / delete the statement.
Mentore
-
Hello
If I comment :
line 60 // static ULONG my_timer;
and
line 98 // my_timer=WinStartTimer( hab, hwnd, 0L, (ULONG)50 );
It will compile without errors, runs, but the animation will not work.
I guess I will leave this warning as it is.
Regards
-
Hello
Here it is another one. I tried to convert Fatbits (pixel magnifier program) from the OS/2 1.1 API by changing some WinQuery.. functions to PrfQuery.... Removed the warnings. I ignored the ASM code that seemed only to create the DLL, and didn't create the DLL, I embedded it to the EXE.
It compiles without warnings, it loads, shows the magnified pixels, but it does not refresh the screen according the position of the cursor. If I maximize and reduce a window, it will refresh the magnifier image.
Regards
-
Hello
If I comment :
line 60 // static ULONG my_timer;
and
line 98 // my_timer=WinStartTimer( hab, hwnd, 0L, (ULONG)50 );
It will compile without errors, runs, but the animation will not work.
I guess I will leave this warning as it is.
Regards
which is the right thing to do, Martin, as the variable is of course needed. To remove the warning you may try to do something with it like this:
my_timer++;
my_timer--;
before calling WinStartTimer, so that the compiler thinks we have done something on it, or maybe search for some #pragma
statement to avoid the warning. Not sure about it, since I'm no GCC expert at all.
Mentore
-
Can you please give me a hand with this warning?
gcc -Wall -Zomf -c -O2 pmstars.c -o pmstars.obj
pmstars.c: In function 'ClientWndProc':
pmstars.c:60:16: warning: variable 'my_timer' set but not used [-Wunused-but-set-variable]
60 | static ULONG my_timer; /* System (PM) number indicating unique (system) timer number
| ^~~~~~~~
Calling WinStopTimer on it at cleanup time might be the most "proper" way of dealing with that. However, a quicker and cheaper way of eliminating the warning is probably to add:
if ( my_timer ) {;} /* stop compiler from complaining */
after the call to WinStartTimer.
-
Thanks Alex, Mentore.
Now it compiles without warning. I had included the latest changes on the github.
- https://github.com/OS2World/APP-GRAPHICS-PMStars
If you have any suggestion about FatBits, I will appreciate it. I didn't think it was going to be able to compile it since it came from 1990, but it compiled with some changes, sadly the magnifier screen does not refresh when the mouse moves.
Regards