Author Archives: neozeed

Wlink-ing for fun & … profit?

Posted on by
4

well rounding out the experiment is of course the hidden OS/2 2ine. And how does it respond to the various linkers?

Operating System/2 LX (Linear Executable) Linker
Version 2.00.000 Mar 20 1992
Copyright (C) IBM Corporation 1988-1991.
Copyright (C) Microsoft Corp. 1988-1991.
All rights reserved.

If you remember this is from the Limited Edition or Citrix Multiuser 2.0 version:

$ ./lx_loader /mnt/c/msos2/test/mt.exe
mmap((nil), 8192, RW-, ANON|PRIVATE|FIXED, -1, 0) failed (1): Operation not permitted
$

What about the OS/2 2.0 GA linker?

[<ohestwo>-C:\TEMP]\os2\link386 mt.obj

Operating System/2 Linear Executable Linker
Version 2.01.005 Mar 16 1993
Copyright (C) IBM Corporation 1988-1993.
Copyright (C) Microsoft Corp. 1988-1993.
 All rights reserved.

Run File [mt.exe]:
List File [nul.map]:
Libraries [.lib]:
Definitions File [nul.def]:
LINK386 :  warning L4071: application type not specified; assuming WINDOWCOMPAT

[<ohestwo>-C:\TEMP]mt
hi

[<ohestwo>-C:\TEMP]

and on 2ine?

$ ./lx_loader /mnt/c/msos2/test/mt.exe
not an OS/2 module
$

Well this all sucks. But how about a 3rd party linker? Watcom?!

C:\msos2\test>cl386 /c mt.c
Microsoft (R) Microsoft 386 C Compiler. Version 1.00.075
Copyright (c) Microsoft Corp 1984-1989. All rights reserved.

mt.c

C:\msos2\test>wlink d all SYS os2v2 op m op maxe=25 op q op symf @mt.lnk

C:\msos2\test>dir mt.exe
 Volume in drive C has no label.
 Volume Serial Number is 3C41-1D63

 Directory of C:\msos2\test

13/05/2021  01:48 am             5,160 mt.exe
               1 File(s)          5,160 bytes
               0 Dir(s)  646,855,708,672 bytes free

C:\msos2\test>

and on 2ine?

$ ./lx_loader /mnt/c/msos2/test/mt.exe
hi
$

Wow! How about OS/2 2.00 GA?

Sadly a no go.

Obviously this needs more testing on later versions of OS/2. I tried wlink from Watcom C/C++ 10.0 and it won’t run. Once more again the devil is in the linker, and just as last time, it turns out that the ‘portable’ tools are 16bit!

$ ./lx_dump /mnt/c/msos2/bin/orig/CL386.EXE
/mnt/c/msos2/bin/orig/CL386.EXE
NE (16-bit) executable.
Linker version: 5
Linker revision: 2
Entry table offset: 117
Entry table size: 2
CRC32: 0x30E8EA59
Module flags: MULTIPLEDATA
Application type: WINPMCOMPAT

I meant to post earlier but if you want to follow along, project dump is msos2-wlink.7z.

GCC 2.5.8 failure on 32bit ARM

Posted on by
1

This is really nothing more than a placeholder for me… Unless someone else knows the answer, then it’s really ‘how not to cross compile GCC’.

First I’m using the EMX’ified version of GCC from my MinGW to EMX cross. It didn’t require that much massaging to get it to build, the usual unzip as ascii to convert text, and in no time I can build cc1.


root@pinepro:/src/emx/src/gcc-2.5.8# file cc1
cc1: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=42c0c8de7175edade7614dc92d5d13e4421e0e6f, with debug_info, not stripped

and it crashes in what has to be a 2020 most unfortunte name

Reading symbols from cc1...done.
(gdb) r
Starting program: /src/emx/src/gcc-2.5.8/cc1 

Program received signal SIGSEGV, Segmentation fault.
0x004f6b84 in rtx_cost (x=<error reading variable: Cannot access memory at address 0xff7efff0>, 
    outer_code=<error reading variable: Cannot access memory at address 0xff7effec>) at cse.c:667
667     {
(gdb)

Yes, it really crashes in rtx_cost. Good thing there isn’t a super popular card from Nvidia that is currently being short squeezed by crypto miners right now called the RTX where everyone is looking for a good price. 😐

I had then been thinking perhaps it’s because I’m using GCC 8.3.0, maybe it’s introducing some new and exciting bug? So I cross compiled GCC 4.1.2 as follows:

./configure --target=armeb-linux --host=armeb-linux --build=armeb-linux

Keeping in mind that my knowledge of ARM is pretty much nill, especially on Linux. The compile went mostly okay, just have to remember the gnu inline macro’s as needed from back in the day (-fgnu89-inline) and while it builds, it is insisting on using collect2 which of course is screwing things up. And of course I don’t want it as my system compiler. As a hack I found system gcc 8 can link things fine as I didn’t want to spend all day messing with GCC/collect2

I copied xgcc, cc1 and cpp from 4.1.2 into a /412 directory, and rebuilt 2.5.8 with the following shell:

make CC="/412/xgcc -B/412 -g -O0  -I. \
-I./config \
-I/usr/lib/gcc/arm-linux-gnueabihf/8/include \
-I/usr/local/include \
-I/usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed \
-I/usr/include/arm-linux-gnueabihf \
-I/usr/include" cc1

As you can see the cross wasn’t picking up the right include paths, so I just cheated, and dumped them from 8, and just copied them into this script. I re-ran the build and had 2 issues, 

/412/xgcc -B/412 -g -O0  -I. -I./config -I/usr/lib/gcc/arm-linux-gnueabihf/8/include -I/usr/local/include -I/usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed -I/usr/include/arm-linux-gnueabihf -I/usr/include -c  -DIN_GCC   -g -std=gnu89     -I. -I. -I./config local-al.c

....

/tmp/ccMguyhs.s: Assembler messages:
/tmp/ccMguyhs.s:5001: Error: selected processor does not support `fltd f1,r3' in ARM mode
/tmp/ccMguyhs.s:5025: Error: selected processor does not support `fltd f0,r3' in ARM mode
/tmp/ccMguyhs.s:5026: Error: selected processor does not support `dvfd f1,f1,f0' in ARM mode
/tmp/ccMguyhs.s:5027: Error: selected processor does not support `ldfd f0,.L489' in ARM mode
/tmp/ccMguyhs.s:5028: Error: selected processor does not support `mufd f0,f1,f0' in ARM mode

and so on. Also failing was global.c Again the same weird instruction/asm mix being triggered. Other than those two, cc1 will build, but unsurprisingly:

Reading symbols from cc1...done.
(gdb) r
Starting program: /src/emx/src/gcc-2.5.8/cc1 

Program received signal SIGSEGV, Segmentation fault.
0x004f6b84 in rtx_cost (x=<error reading variable: Cannot access memory at address 0xff7efff0>, 
    outer_code=<error reading variable: Cannot access memory at address 0xff7effec>) at cse.c:667
667     {
(gdb)

Well, at least it’s consistent?

Or a fun way to kill a couple hours.

**EDIT I went ahead and looked in the 4.1 source for ARM stuff..

root@pinepro:/src/gcc-4.1.2# grep arm config*|grep linux
grep: config: Is a directory
configure:  arm*-*-linux-gnueabi)
configure.in:  arm*-*-linux-gnueabi)

it didn’t like the gnueabihf stuff one bit.

I tried to rebuild as linux-gnueabi

./configure --target=arm-linux-gnueabi --host=arm-linux-gnueabi --build=arm-linux-gnueabi

make LANGUAGES=c HOST_CFLAGS='-fgnu89-inline' CFLAGS='-fgnu89-inline'

And then re-built GCC 2.5.8 with the same error, but slightly further into the program:

Starting program: /src/emx/src/gcc-2.5.8/cc1

Program received signal SIGSEGV, Segmentation fault.
0x004f2a20 in rtx_cost (x=0x41, outer_code=PLUS) at cse.c:679
679       code = GET_CODE (x);
(gdb) bt
#0  0x004f2a20 in rtx_cost (x=0x41, outer_code=PLUS) at cse.c:679
#1  0x004f2e20 in rtx_cost (x=0x60c3f8, outer_code=SET) at cse.c:736
#2  0x004ac2dc in init_expmed () at expmed.c:87
#3  0x0045ae28 in compile_file (name=0x5c96ec "stdin") at toplev.c:1648
#4  0x0045f6fc in main (argc=1, argv=0xfffefd04, envp=0xfffefd0c) at toplev.c:3569
(gdb)

The positive thing is that there was no weird register errors while compiling, and it built 100% normally…? “arm-linux-gnueabihf” almost seems right, specs needs fixing to point to “/lib/ld-linux-armhf.so.3” instead of “/lib/ld-linux.so.3” along with the linker target.

Continuing with Ancient Microsoft C/Linkers

Posted on by
23
Microsoft OS/2 Software Development Kit Pre-Release 2

I don’t know why, but Microsoft OS/2 2.00 beta’s are beyond rare. At one point I had a documentation set but not disks. However disk images circulated around, so at one point I did have printed documents (that basically didn’t show much interesting other than True Type fonts for OS/2), and the SDK/ToolKit. However there to date has been no operating system images surfacing.

Since yesterday’s look at the 1991 Windows NT Pre-release which turned out to be using the OS/2 compiler, I went back and checked the Microsoft OS/2 SDK, and it turns out that the compiler is a ‘bound’ executable, meaning that it’ll run under MS-DOS!… And for us that means the MS-DOS Player can make native Win32/Win64 executables out of the compiler/assembler.

Microsoft (R) Microsoft 386 C Compiler. Version 1.00.075
Copyright (c) Microsoft Corp 1984-1989. All rights reserved.

As always the devil is in the details, and this time it’s the linker. I now have OS/2 2.00 v123 (February of 1991), Citrix Multiuser 2.0 (March 1992), and OS/2 2.00 GA (July 1993). And not surprisingly despite them all either including a system link386.exe or the SDK link386 they have massive final incompatibilities.

For fun, I’m using a super simple C program, and compiling it with the Microsoft Pre-Release 2 SDK. After that I’m just using various Linkers & OS’s and the same Pre-Release libraries to see the same object relinked and running.

void main(void){
write(0,"hi\n",3);
}

It’s a very simple program that really doesn’t assume or need much other than write.

So looking at OS/2 build 123

Version 1.01.015

This is the SDK Linker 1.01.015. Dated November 28th, 1990. Which sounds a bit late in the year, but don’t worry as the OS includes Version 1.01.018, dated August 15th 1990!

Version 1.01.018

I don’t understand it either.

Citrix Multiuser 2.0

Version 2.00.000

Citrix Multiuser is using the 177H base also known as the OS/2 2.00 LE. It includes a version 2.00.000 linker, which works fine for it. However the SDK and 123 linked files do not run. While the SDK runs fine, I don’t know how did they link the tools as they work fine**.

OS/2 2.00 GA

Version 2.01.005

And finally we have OS/2 2.00 GA using it’s linker, and yeah it runs fine. Also the GA can run the LA linked files. Naturally 123 can’t run either LA or GA EXE’s.

Obviously the tool group was separate from the OS teams, and there was that brief window when everything 32bit was OMF, and LX was going to be the grand behind the doors unification thing providing 32bit exe’s for Windows 3.x VXD’s, OS/2 2.x and Windows NT. But as was obvious in the 1991 Pre-Release the tool to convert OMF to COFF wasn’t going to be a tool much longer and it was going to be integrated directly.

I’ve tried using the link386 from the Windows 3.1 DDK but I can’t get it to link properly. Just as I haven’t tried other MASM386’s or even 16bit MASM 5+ which apparently support 32bit OMF?

Again it’s interesting to me, but is it useful? Not really. Also the last interesting bit is that the Microsoft C from the 73g build of the Windows 95 SDK can produce assembly that the Pre-Release more or less understands:

D:\OneDrive\proj\link386>4.00.73g\BIN\cl /c /Famt.asm mt.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 8.00.3200
Copyright (c) Microsoft Corp 1984-1993. All rights reserved.

mt.c

D:\OneDrive\proj\link386>

And then assembling and linking on OS/2

Useful? Not very. I don’t think anything complicated will run, although I have only tried one thing and it had a tonne of 16bit/32bit collisions. I don’t know if Microsoft C/C++ 8.0 for OS/2 is all that desirable but I’d imagine if it were, smarter people than I would have made it a thing.

**Edit from the future

Well it turns out the SDK tools are 16bit Family mode apps. It’s obvious once Nathan pointed it out that there is no 32bit ‘bound’ for MS-DOS, however there was Family Mode*** for realmode/protected mode 16bit code.

DOS/4G error (2300): can’t find DOSCALLS.282 – referenced from MT
DOS/4G fatal error (1313): can’t resolve external references

PharLap famously made their early 286 extender based around OS/2, however for the 32bit stuff it was apparently home grown for the early stuff (I have version 4) but there is DLL’s to emulate MS-DOS like the 286 extender. Interestingly enough DOS/4G supports DLL’s but again there is no DOSCALLS.DLL I can find, but the loader loads it.

***Family Mode/Family API

From the book INSIDE OS/2 (ISBN 1-55615-117-9):

2.2.4.1 Family API
To provide downward compatibility for applications, OS/2 designers
integrated a Family Applications Program Interface (Family API) into the
OS/2 project. The Family API provides a standard execution environment
under MS-DOS version 3.x and OS/2. Using the Family API, a programmer can
create an application that uses a subset of OS/2 functions (but a superset
of MS-DOS version 3.x functions) and that runs in a binary compatible
fashion under MS-DOS version 3.x and OS/2. In effect, some OS/2 functions
can be retrofitted into an MS-DOS version 3.x environment by means of the
Family API.

Interesting? Maybe. October 1991 NT SDK uses the OS/2 toolchain

Posted on by
Reply
The linker is from an older MS SDK, the compiler from October 1991 preview of NT

So back in the day I wrote something vague about the October 1991 preview version of Windows NT, and after messing with the tools and building f2c & dungeon (among some other stuff) one that that stuck out to me is that the object files had to be converted for NT.

cvtomf!

The interesting thing is of course that it doesn’t support the cl386 direct compile and link (hence CL). Instead you have to compile, convert and then link. A fun thing about the October 1991 version is that there is a cl386 cross compiler for OS/2. So while looking around for OMF linkers (and assemblers that either understand GAS but output OMF, or some translator) I ran across this, and well yeah, it turns out that the OS/2 tool chain is the toolchain. I guess it makes sense in that the NT team was using OS/2 to build NT, but objects and exe’s were not solidified.

I think 6.00.080 was the last version of Microsoft C 386 for OS/2. I need to start collecting more of the SDK/DDK’s of the mixed era, I think the LX/OMF stuff was a bit more widespread hiding in plain sight.

Anyways, interesting?! sure. useful? Maybe 30 years ago. Although I’d probably say just use Watcom C/C++ instead of Microsoft C 6.00

Infocom: The Documentary

Posted on by
2

Infocom (1979-1989) is recognized as the all-time leader in Interactive Fiction, releasing top-selling games and products that dominated the sales charts and still extend considerable influence and memory on the gaming industry. At times they were half of the top ten games being sold and were considered a flagship of the game industry. And then they were gone.

As part of the 2010 documentary GET LAMP, director Jason Scott talked to creators, management, fans and academics about the Infocom story, and produced this 45 minute overview of this unique and wonderful company.

Jason Scott on Twitter; http://twitter.com/textfiles​

Patreon for Jason Scott's podcast: http://patreon.com/textfiles​

To purchase the DVD of this and the other GET LAMP features, visit http://WWW.GETLAMP.COM​.

The Oregon Trail for FORTRAN 77

Posted on by
Reply

The other day I’d been alerted to this fantastic port of the BASIC game to Fortran 77 by Kidon, bringing it to mainframe and midrange machines of the 1970s!

You can read more information at it’s home page here, along with getting the source code and building it out.

Naturally I had to build it using f2c, and QuickC for Windows. Just some minor tweeks and it runs!

Victory! …?!?

Although victory could have gone a bit better. I know it’s largely my fault trying to introduce a clean way to pause before exiting. Obviously there is tonnes of Fortran compilers out there, for many old platforms, so perhaps this will make the Oregon Trail the ‘DooM’ of machines with F77?! Give it a try, there is extensive build instructions, and a quick list of known good platforms, be sure to update with newer (older) stuff that is found to fun!

Presenting MacFlim

Posted on by
4

This is beyond super cool! Video has always been something of the realm of ‘high end’ machines, back when QuickTime became a thing it was lauded at running in a postage stamp sized window with absolutely incredible artifacting. And that was running with a Quadra (68040) back in the day, the transition from 68000 to PowerPC really helped with video on the desktop with much faster clocks and better caching.

The idea of video on any of the compact black & white Macs, even the ultra high end SE/30 68030 based Mac seemed something out of fantasy. But thanks to modern processors, massive storage and the ability to front process the video, it is now possible to do playback on a B&W mac!

Enter MacFilm 1.0 by Fred!

This is some super cool ‘impossible’ tech for the low end macs!

This is nothing short of incredible!

Of course the ‘downside’ is there is no audio.. And it’s directly blitting to the 512×342 B&W display so if you are not running on a 1 bit original display it’s not going to work or just blast seemingly junk to the screen.

Maybe if big 80’s media wasn’t so slow, or massive SCSI disks didn’t cost as much as a car we could have been enjoying an almost Brazilian future of black and white movies on tiny CRT’s.

[TUHS] 4.4BSD sparc, pmax binary recently compiled

Posted on by
2

Well this came as a bit of a surprise, but also a great thing!

 I compiled 4.4BSD to get pmax and sparc binary, from CSRG Archive CD-ROM #4
source code.

    http://www.netside.co.jp/~mochid/comp/bsd44-build/

  pmax:
    - Works on GXemul DECstaion(PMAX) emulation.
    - I used binutils 2.6 and gcc 2.7.2.3 taken from Gnu ftp site,
      as 4.4BSD src does not contain pmax support part in as, ld,
      gcc and gdb.
    - Lack of GDB. I got rid of compile errors of gdb 4.16, but that
      does not work yet.
    - gcc included can not deal c++ static constructor. So, contrib/groff
      can not be compiled. Instead, it uses old/{nroff,troff,eqn,tbl..}.

  sparc:
    - Works on sun4c. I use on SPARCstation 2, real hardware.
      TME sun4c emulation can boot to single user, but it locks up in
      middle of /etc/rc.
 
 CSRG Archive CD-ROM #4's source code (just after Lite2 release) seems
have differences from CSRG's binary distributions before (2 times),
e.g. mount systemcall is not compatible.

 I used NetBSD 1.0/sparc, NetBSD 1.1/pmax for 1st (slightly) cross
compiling. NetBSD 1.0/sparc boots and works well on TME emulator.
SunOS 4.1.4, Solaris7 works too, but this 4.4BSD binary doesn't..

-mochid

So this is a heck yes, let me boot this thing up! It’s been a while since I last messed with GXemul, but even this old version runs 4.4BSD!

And yeah it’ll boot up! Exciting.

As mentioned it’s based off the CD #4 from the CSRG set. Really if you are interested in old UNIX, be it BSD or AT&T get this set!

Back of the set aka contents

On the back you can see it’s the last source dump including all the SCCS tags. This plus the extra “historic content” is what you need! Maybe it’s the emulation, maybe it’s the last cut of 4.4 but mounting a CD-ROM just works. So nice. Although the source on the CD isn’t directly buildable. There is some issue with the MIPS locore which needs a patch from mochid, but with the fixes in place it’ll build and run!

Obviously the unanswered question is where is the i386. And that is probably the greatest 90’s software bungle that is either conspiracy to profit or just incredible lack of vision when it comes to platforms. It’s certainly easy to have an off version of reality in University, especially with nice OEM hardware grants to see the world in one light, Just as the Amiga/Atari home computer wars both ignored the vastly inferior PC for it’s laughable beeper, CP/M like OS and woefully inadequate CGA graphics. But the PC was modular and it was an open platform, the industry didn’t have to wait for IBM to make a 32bit PC, instead you had people adding 386DX processors on 286 motherboards complete with 80287 coprocessors, and custom memory controllers to retrofit the memory bus.

CSRG had TAHOE dreams, HP 680000 plans, then SPARC. All the while missing out on the unwashed masses with their 386 and 486 machines. I haven’t tried it, but I bet BSD/OS 1.1 will patch in pretty well for i386. And why would it? Because that was the ticket to the pre pre pre .com bubble of commodity minicomputer UNIX on the desktop. But that blasted 1-800-ITS-UNIX ruined it all, and this ‘hey guys’ project took the UNIX crown.

I’ve been playing with updating the GXemul ‘port’ I did along with integrating SLIRP so I can telnet it. The timing is very shakey and I’m not too happy with it. And I want to redo the disks and sources to be a cleaner ‘merge’ so it just ‘makes’ in the normal places like a native build. If I had crazy people money I’d want to port this to the Loongson-3A4000, but that’d be crazy, instead it’d be more worth my while to try to make an Amiga or Atari ST.

But what do I know, my cellphone runs Mach/BSD!