Running old OS/2 Software - Issues

[Martin Iturbide]

Hi

Since I'm reorganizing hobbes I'm also enjoying myself by trying to run some old OS/2 software.
I want to request for some help and I want to use this thread for some old OS/2 software that does not run on today's ArcaOS.

My first one is:

1) Present!  (1992-04-09). A presentation software, maybe like some basic PowerPoint or Freelance. (source code available)

It loads and stops. It gives this error on the log.

Code: [Select]

09-13-2021  11:24:27  SYS3171  PID 00b3  TID 0001  Slot 009f
C:\HOME\DOWNLOADS\PRESENT\PRESENT.EXE
c0000005
1fc5b24d
P1=00000002  P2=0005ffa4  P3=XXXXXXXX  P4=XXXXXXXX 
EAX=1a2a7cfc  EBX=1f040001  ECX=00060378  EDX=00000001
ESI=0100001d  EDI=00405037 
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:1fc5b24d  CSACC=d0df  CSLIM=5fffffff
SS:ESP=0053:0005ffa8  SSACC=d0f3  SSLIM=5fffffff
EBP=000604e0  FLG=00010202

PMMERGE.DLL 0004:0012b24d

Regards

[Neil Waldhauer]

I think any software from 1992 is 16-bit. Now it ought to run, but two things happened to Presentation Manager since 1992. First, the PMMERGE. I don't remember what the two libraries were that merged, but likely the software is linked against the old libraries. Running in the debugger might help.

The second change was between Warp 3 and Warp 4. I think changes made you initialize a PM program differently. It's a minor change, but without, there might well be a crash in PMMERGE. That's still a change that might be monitored in the debugger.

[Dave Yeo]

I had a quick look at the package. The readme does say,

The current version is a simple port from my OS/2 1.3 version that I wrote
two years ago.

So I assume the author ported it to 32 bit OS/2 v2.  Possibly a simple recompile would fix it or show where the error is.

[Dave Yeo]

Trying to compile with VACPP v3.08, I see it wants an unknown library, OPENDLG.LIB, which I nor Google have never heard off. Removing it results in this error,

Code: [Select]

LINK386 :  fatal error L1104: G:\IBMCPP\LIB\cppos30.lib : not valid library
Which I don't understand as cppos30.lib seems to be a valid import library. Seems that is the runtime and there should be a way to statically link it instead of depending on a runtime DLL. Anyone know the recipe?

[Lars]

1) I suspect that OPENDLG.LIB was a library that was necessary to build a OS/2 version 1.3 PM application. Of course, the question is, why is it still listed in the makefile ? Maybe that was an omission to remove it.

2) I suspect that problem with CPPOS30.LIB is that it follows a newer OMF library format than what LINK386 understands. The easiest thing is to replace "link386" with "ilink /NOFREE". /NOFREE will force ilink to follow the same command line syntax as LINK386 but it will be able to link to CPPOS30.LIB.
In any case, it is not wrong to link to the RTL dynamically (but it might be a better idea to link against CPPOM30.LIB, that is, specify /GM+ as compiler switch: link multi-threaded).

David, can you post the makefile as you have corrected it ?

[Martin Iturbide]

I see it wants an unknown library, OPENDLG.LIB,

Hi

I found some other OSS projects that makes reference to OPENDLG.LIB on github
- https://github.com/search?q=org%3AOS2World+opendlg.lib&type=code

I also found that FileDLG also makes a reference that it used to be called OPENDLG, but not sure if it is the same thing.

But I still can not find the missing OPENDLG.LIB

Regards

[Dave Yeo]

1) I suspect that OPENDLG.LIB was a library that was necessary to build a OS/2 version 1.3 PM application. Of course, the question is, why is it still listed in the makefile ? Maybe that was an omission to remove it.

2) I suspect that problem with CPPOS30.LIB is that it follows a newer OMF library format than what LINK386 understands. The easiest thing is to replace "link386" with "ilink /NOFREE". /NOFREE will force ilink to follow the same command line syntax as LINK386 but it will be able to link to CPPOS30.LIB.
In any case, it is not wrong to link to the RTL dynamically (but it might be a better idea to link against CPPOM30.LIB, that is, specify /GM+ as compiler switch: link multi-threaded).

David, can you post the makefile as you have corrected it ?

OK, the "ilink /NOFREE" fixed the linking and produced a working present.exe. Thanks

Code: [Select]

# IBM Developer's Workframe/2 Make File Creation run at 12:29:23 on 04/08/92

# Make File Creation run in directory:
#   E:\C\SHEET;

.SUFFIXES:

.SUFFIXES: .c .rc

ALL: PRESENT.EXE \
     PRESENT.RES

PRESENT.EXE:  \
  PRESENT.OBJ \
  PRESENT.RES \
  PRESFONT.OBJ \
  MAKEFILE
   @REM @<<PRESENT.@0
     PRESENT.OBJ +
     PRESFONT.OBJ
     PRESENT.EXE
     
<<
   ILINK.EXE /NOFREE /PMTYPE:PM @PRESENT.@0
   RC PRESENT.RES PRESENT.EXE

{.}.rc.res:
   RC -r .\$*.RC

{.}.c.obj:
   ICC.EXE /c /I. /Ss .\$*.c

!include MAKEFILE.DEP

Here's the working exe.

[Martin Iturbide]

Thanks Dave. It is working.

I'm packaging the exe and makefile on the zip file and I will upload it to hobbes.
I'm moving it to "/pub/os2/apps/graphics/presentation" since it seems it not for making animations

Regards

[Dave Yeo]

Might want to see if Lars has any suggestions about the CFLAGS such as using the multi-thread library.

[Lars]

What I normally use is this:
/Ge+ (when building an Exe)
/Gm+ (using the multi threaded libs, see following explanation)
/Gd+ (linking the RTL dynamically and therefore cut down on Exe size)

If you use these switches, the final step that you can do is to replace the name of the multi threaded RTL with one that comes as part of every OS/2 installation.
On the created Exe, run this:

Code: [Select]

dllrname.exe present.exe CPPOM30=OS2OM30
Of course, you could add this to the makefile.

That will replace all references to CPPOM30.DLL with OS2OM30.DLL which is always present in OS2/DLL directory.

I am talking about VAC 3.0 and not VAC 3.65 or VAC 4.0.

[Dave Yeo]

OK, that made the compiler dislike C++ type comments After fixing and adding a missing include, seems to work.
I'll package it after work and post the fixed package.

[Dave Yeo]

Packaged version with updated makefile and minor changes (comments and an added include) to make the compiler happy.

[Mike La Martina]

I have attached opendlg.lib from th V1.3 toolkit.

[Lars]

OK, that made the compiler dislike C++ type comments After fixing and adding a missing include, seems to work.
I'll package it after work and post the fixed package.

The /Ss switch did the trick. That allows C++ comments in C code. I did not say to remove that 😂

[Lars]

I have attached opendlg.lib from th V1.3 toolkit.

That is no longer needed for 32- bit code.