Need help with pli-86 compiler under MsDos in DosBox

Hi I programmed a lot with the Pli-86 compiler from Digital Research during the mid 80’ies.Now I am trying to recompile old software in a Dosbox. The compiler works fine but I am getting errors using link86.

A simple program like:

/* program : HelloWorld */
    procedure options(main);
	put skip list ('hello world');

below is the output from the compiler:

PL/I-86 Compiler                       Version 1.0
Serial No. 3091-3000-000347    All Rights Reserved
Copyright (c) 1982,1983     Digital Research, Inc.
PL/I-86 V1.0 Compilation of HELLO

   No Error(s) in Pass 1

   No Error(s) in Pass 2

Code Size: 0025
Data Size: 000B

End of Compilation

Using the link command

f>link86 hello

Gives the following error

LINK-86 Linkage Editor                 Version 1.3
Serial No. 3092-3000-000002    All Rights Reserved
Copyright (C) 1982-1984     Digital Research, Inc.

 RECORD # 0022
 ITEM #   0001

And I have no idea what the problem is. Compiling the same program with a CPM86 version of the compiler under a CPM86 emulator in a MsDos emulator in Windows10 (why not :grinning:) works fine.
Running the CPM 80 version of the compiler works file as well.

However I used both the CP/M compiler beginning of the 80’ies and the MSDoS version mif 80’ies without problems then

I have found some people who have been playing around with these compilers. Unfortunately only on old archives.
Any help would be appreciated!!!
Nico Verduin

Welcome! I have no direct experience, but a couple of thoughts

  • could the 1.3 linker be a little incompatible with the 1.0 compiler?
  • is the library PLILIB.L86 corrupt, or somehow incompatible?

It would be good if you could share a link to the versions you have, so we can try the same thing. I was only able to find versions for CP/M-86, with a quick look.

first: I have no idea what I’m talking about.

That said, this is what the Link-86 manual has to say about this error:


LINK-86 detected an error in the object
file. This is caused by a translator
error or by a bad disk file. Try
regenerating the file.

detected an error in the
object file. This is caused by
a translator error or a bad
disk file. Try regenerating
the file.

LINK-86 accepts two types of object files. The first type is
an object file containing a single object module. This type
generally has the filetype OBJ, and is produced by a language
translator. The second type is a library file which is an indexed
library of object modules. A library file has a filetype L86, and
is generated by the library manager, LIB-86, in the Intel 8086
object module format. LINK-86 can search such a library file and
select only those modules needed by the other programs being linked.

This suggests that the linker can’t parse the library file (mind the “L86” file type), which supports @EdS’s idea that it may be about non-matching versions.

manual file:

Juts for the record, I’ve searched and failed to find in any archive of these archives:

Visit the “Unofficial” CP/M Web site.
European Mirror at :

Thank you all for the fast responses. I was aware of the error mentioned in the manuals. However it does not seem to make sense. I have downloaded several versions where one has even upgraded the library adding correct filehanding (CP/m thing) and date/time. I fixed that in 1985.

some links :

The latter shows even som editing of the library.
All give me the same kind of problems…
I will try to rebuild the library next week. See if that helps.
Unfortunately I do not have an old DOS pc lying around to isolate the possibility that it is a dos emulator issue. After all anything is possible.


Had to split my links to 2 posts. This is the last one

Rebuilt the library. And getting the same errors. Maybe I need someone with an old MsDos PC to determing if the problem is in de DosBox or the compiler.

Which library are you using? There is also a patched library in the “Extras” directory of the MS-DOS version archive. Very interesting READ.ME file there!

I have tried just about every library I can get my hands on. But theyt seem identical being 74kb in size.
I have tried to rebuild the library using lib86 however that has still some challenges. There are problems with filenames starting with a ‘#’. Also if I make an input file with all the object names I have to terminate it with a 0x1A (in NP++ visible as sub) which is the CP/M end-of-file character. Although I compiled everything in a dos box (tried several) I managed to build a library after removing the #files.

Also I have no idea how to use plink and plink86. I understand they were used in Clipper. \

And I have not been able to read the image files (in the files section). They are the original floppy files. The only emulator so far that reads them is 86box.exe. But I haven’t found a way to copy the data out of the emulator to my hard disk.

Great challenge project!!!

1 Like

There is progress!!!
I create a virtual PC-XT 8088 using 86box v3.0 and it works like a charm. Now I have to figure out how to either create an old fasioned 5.25"floppy image of the new files and vice versa. At least I can now compile and link pli programs. Still have to fix the date/time and msdos 128byte sector problems from CP/M


Wel this all took some effort :grinning:But it works.

  • I installed 86box : GitHub - 86Box/86Box: Emulator of x86-based machines based on PCem. and after unpacking the roms (also in this github)
  • Configured the machine as an XT with 640KB, a 20mb HD 2 floppy drives (1 x 5.25 360kb and 1 x 3.5 720kb)
  • installed pcdos 5.02 (from product/pc-dos/5x in [add this in front of the other links])
  • Boot from the first disk image and follow the installation.
  • Then installed the plii-86 dos compiler (product/digital-research-pl-i-compiler/1x)
  • linker and assembler etc (product/dri-programmers-utilities/1x)
  • installed qedit (for now) as a simple editor (/product/qedit/21)

Currently I am running the assembler and pli compiler to build the new plilib (although already supplied)


Great news - and thanks for sharing the recipes. Was it the 86 emulation, or the PC-DOS compatibility, or something else, I wonder?

So the library shipped in the ZIP files is broken, only the one from images works?

It were the emulators that suck. 86box is actually a virtual cpu emilator with a pc built around it. This one seems to work fine. I hope to rebuild a correct library tomorrow.
But with the original compiler i could now build a simple hello world example

Just rebuilt the library plilib.l86 by compiling every .a86 and .pli library file. Now it all works like a charm.
I am very impressed by the 86box virtual pc.
I had some problems at first that files never got copied on my 720kb diskettes. Then I recalled a problem I had with a PC at client here in Holland that their hard disk was full. The cause was the limit of 112 files in the root. Spilt my sources into 3 diskette of 720kb 3.5". Solved the problem!! Yeah.

So it all works. Now to find a file indexing system I used back in those days :slight_smile:


Great! Can you post the compiled plilib.l86 somewhere?

this should work : Dropbox - PLILIB.L86 - Simplify your life

1 Like

tried that one under dosbox and it seems it is an emulation problem indeed!

Ok All,
It has been a year of quite some frustrations :slight_smile: But I hve made quite some progress, The bottom line was ti figure out if I could combine pli-86 programs with Microsoft C 6.0 programs. Well that almost works :frowning:

Segment name erorrs
PLI86 creates a CSEG with name CODE while Microsoft defaults to _TEXT. Fixed that with switch /NTCODE. This changes the default segment name to CODE in MSC 6.0

Segment alignment
In PLI86 the compiler defaults to BYTE Alignment. MSC6.0 defaults to WORD alignment,Sofar I haven’t figured out how to get them the same. Sofar ther is no problem with execution of the program Just a warning from link86.exe.

Maximise optimization
By using switch /Ox it save a whole bunch of not user external defined variables.

Just compile the c source(s)
By using switch /c it wil not try to link it all

Just use inline FP87 emulator
By using switch /FPi you get no link errors

And now the hard part
Microsoft C 6.0 save passed variables on the stack. PLI86 passes in BX a pointer to a block of pointers which in turn points to the variables somewhere in memory.

I stil have to find a nice solution for that

Return variables is limited to either an 8 bit number (in register AL) or a 16 bit number (in register BX).

I tried a very simple trick which seems to work fine by this example:

pli program

test1: proc options (main);

    /* Declarations */
    dcl func1 entry (fixed bin (15)) returns (fixed bin (15));

    put skip list (' Hello Nico ');
    put skip list (func1 (135));
end test1;

This program was compiled as follows : PLI TEST1 [RETURN]

This is the func1.c

void pascal func1 ()
    unsigned int returnWaarde = 0;

	mov  BX,[BX]		; BX = pointer block of pointers
	mov  BX,[BX]           ; BX points to first variable
	mov  [returnWaarde], BX ; fill a variable in local memory with the value of the parameter

    // Divide it by 2 in C
    returnWaarde = returnWaarde / 2;

	mov bx, [returnWaarde]   ; fill BX with our local value

Notice the use of the reserverd word pascal in the function line. This ensures MSC 6.0 does not put an underscore before the name of the functions. Thus avoiding label errors during link.

Also notice that I am ignoring any parameters in the function prototype as this is useless in this case.

Compile the C program with cl /FPi /c /NTCODE /Ox func1.c [return]

and link with link86 test1, func1 [return]

Of course in the func1 I can call any function from say a library (ie a btree library) etc from a pli program.

Because I can!!! :grinning:

I am writing a small paper about the whole process. I’ll share it in due course.


Look forward to seeing your writeup.

I have a fading memory of needing to write a shim, back in the day, for my Amiga, so I could call a BCPL library routine from C - they had different calling conventions. So it was a few lines of assembly code, and the question might be, how did I arrange to name it such that the C called the shim and the shim called the BCPL. Of course I don’t remember! But this seems like a similar situation.