Show Posts

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


Messages - Lars

Pages: 1 ... 8 9 [10] 11 12 ... 85
136
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 21, 2023, 10:26:07 pm »
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.

137
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 21, 2023, 10:15:12 am »
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 ...

138
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 21, 2023, 10:02:10 am »
Cannot get a working executable built with gcc. It just won't do whatever I try. VAC rules !

139
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 21, 2023, 09:56:31 am »
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.

140
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 21, 2023, 09:54:37 am »
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.

141
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 21, 2023, 09:23:28 am »
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.


142
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 20, 2023, 07:34:36 pm »
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.

143
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 20, 2023, 08:05:00 am »
Beehive doesn't actually crash here, trying to use a debugger, it sets up dive, reads the pcx files and then cleanly exits.
Code: [Select]
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.

144
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 17, 2023, 11:04:54 pm »
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 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.

145
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 17, 2023, 04:18:37 pm »
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 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

146
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 17, 2023, 03:37:02 pm »
Try the attached. I used VAC so you will need to replace with your own makefile.

147
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 12, 2023, 09:17:04 am »
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).

148
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 12, 2023, 09:13:39 am »
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.

149
Programming / Re: Compiling a PM sample with GCC (2023)
« on: June 12, 2023, 07:55:00 am »
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);

150
Applications / Re: LarsenCommander - new test version
« on: June 11, 2023, 03:11:24 pm »
I think, this misunderstanding stems from the fact that every IOPL example (which means 16-bit code use by the nature of IOPL support in OS/2) seems to imply that you need to put the IOPL code into a separate DLL. Well, you do not have to do that, just needs some additions to the def file and you can happily link 16-bit IOPL code to the rest of your 32-bit app.

Pages: 1 ... 8 9 [10] 11 12 ... 85