Link&Locate 86?
in [Embedded]
|
From: Jonathan Kirwan on 5 Sep 2006 05:23 On Tue, 05 Sep 2006 11:10:33 +0200, Philippe Auphelle <pauphelle.no.spam.please(a)wanadoo.fr> wrote: >Thanks a lot to you all. > >I have a moderately complex link / locate problem that (if I remember) >some of the latest (and last) generation of "technical" OMF overlay >linkers were able to solve. Heck, the documentation for a linker like >PLINK was a thick 3-ring binder, and it had nearly as much directives as >the CPU has instructions! >In one word, the problem is about having volatile (init time) segments >and core segments, all in a Group, and having the toolchain insure that >no code from the core ever attempts to reference anything from the init >(while references the other way are allowed). >When I started to google around a few days ago, I realized that all of >those mighty linking tools had totally disappeared. They were already >considered outmoded when the internet started to build up, so they >hardly ever got referenced. > >Jonathan, I found that Link&Locate belonged to SSI, then Beacon >Development Tools, that merged into Embedded System Products, Inc in Dec >98, and then was bought at some point by Quadros Systems, Inc, that is >now in a different sector of activity. I just discovered today that >Comsol, a UK company, *seems* to still carry the SSi tools. > >Jim and Jonathan, I have been in contact with Rick Caro of Paradigm - >Paradigm was in my investigation list for the kind of tools I'm after. >He's been nice, helpful and friendly, but the Paradigm tools don't have >what I'm looking for. > >Hans, thanks for a great link. I thought those too had definitely gone >to oblivion. > >The bottom line is that I went back to the TIS Relocatable OMF >Specification 1.1 and I'm about to make my own tools. >I shouldn't have to go to the point of writing my own linker / locator >:) , but I'll take the same .obj files input as the linker to provide >the checking I need and abort the make if any error appears. > >Doesn't seem too bad at this point. > >Thanks again to all, > >Phil There is also a linker from Intel as part of their 386 builder toolset (if I remember the approximate name, correctly.) I still have one version of that linker and am still using it. It doesn't support all the record types generated by the C compiler tools I use with it, so had to build a custom tool to adapt the object files for the Intel linker/locator. But it looks as though you have a plan. Best of luck with that. Do you have the specification for the object file format you need to process? (In other words, is the specification you mention above the full one for the object file format you will be working with?) Thanks for the update. Jon
From: Philippe Auphelle on 5 Sep 2006 09:24 Jon, What I'm processing is at this point strictly OMF coming from MS MASM 7.x (aka ML). > But it looks as though you have a plan. Yes, that of writing a quick and dirty validation tool as a Delphi Win32 console program to process the OMF files and check what I have to. I don't need to process all the OMF types for that, just half a dozen. I'll run it just before the link, it will take the same file list and abort the build before the link if it finds an error. > Do you have the specification for the object file format you > need to process? Yes, thanks. The format is the "MS brew" of the OMF format, and that one was easy to locate. It's a PDF file titled Tool Interface Standards (TIS) Relocatable Object Module Format (OMF) Specification Version 1.1 (TIS Committee, May 1995) (www.x86.org/ftp/manuals/tools/omf.pdf) This describes the OMF format as Microsoft and other dev tools creators used it before MS decided to switch to COFF. That's different enough from the pure Intel OMF to make interoperability problematic, but the differences are documented well enough. Just in the unlikely case this can save someone some time... sometime: For that kind of job, the most advanced linker I have found so far is OptLink: It belongs to Digital Mars, in their Digital Mars C/C++ package. I bought their CD (it's a bargain), but Optlink can also be downloaded free from the Digital Mars site as part as the C/C++ package: http://www.digitalmars.com/download/dmcpp.html OptLink can generate any type of 16-bit code (.com/.sys/.bin, DOS EXE, Win 3.x EXE, OS/2 EXE, and Win32 32-bit PE .EXE. It has more useful options than any other linker I could find today, and very precise diags if something goes wrong in the linking process. It only does OMF code, and it's not a locator (well, except in the simple case when you can live with a COM or BIN file format). For the record, Optlink was initially from SLR Systems (great OMF linker, and they had the best assembler, OptASM back then too). It was sold long ago to Symantec, and Digital Mars now holds the part of the Symantec portfolio that includes OptLink. Isn't it strange one has to recreate some basic tools like this after all these years! /Ph. Jonathan Kirwan wrote: > On Tue, 05 Sep 2006 11:10:33 +0200, Philippe Auphelle > <pauphelle.no.spam.please(a)wanadoo.fr> wrote: > >> Thanks a lot to you all. >> >> I have a moderately complex link / locate problem that (if I remember) >> some of the latest (and last) generation of "technical" OMF overlay >> linkers were able to solve. Heck, the documentation for a linker like >> PLINK was a thick 3-ring binder, and it had nearly as much directives as >> the CPU has instructions! >> In one word, the problem is about having volatile (init time) segments >> and core segments, all in a Group, and having the toolchain insure that >> no code from the core ever attempts to reference anything from the init >> (while references the other way are allowed). >> When I started to google around a few days ago, I realized that all of >> those mighty linking tools had totally disappeared. They were already >> considered outmoded when the internet started to build up, so they >> hardly ever got referenced. >> >> Jonathan, I found that Link&Locate belonged to SSI, then Beacon >> Development Tools, that merged into Embedded System Products, Inc in Dec >> 98, and then was bought at some point by Quadros Systems, Inc, that is >> now in a different sector of activity. I just discovered today that >> Comsol, a UK company, *seems* to still carry the SSi tools. >> >> Jim and Jonathan, I have been in contact with Rick Caro of Paradigm - >> Paradigm was in my investigation list for the kind of tools I'm after. >> He's been nice, helpful and friendly, but the Paradigm tools don't have >> what I'm looking for. >> >> Hans, thanks for a great link. I thought those too had definitely gone >> to oblivion. >> >> The bottom line is that I went back to the TIS Relocatable OMF >> Specification 1.1 and I'm about to make my own tools. >> I shouldn't have to go to the point of writing my own linker / locator >> :) , but I'll take the same .obj files input as the linker to provide >> the checking I need and abort the make if any error appears. >> >> Doesn't seem too bad at this point. >> >> Thanks again to all, >> >> Phil > > There is also a linker from Intel as part of their 386 builder toolset > (if I remember the approximate name, correctly.) I still have one > version of that linker and am still using it. It doesn't support all > the record types generated by the C compiler tools I use with it, so > had to build a custom tool to adapt the object files for the Intel > linker/locator. > > But it looks as though you have a plan. Best of luck with that. Do > you have the specification for the object file format you need to > process? (In other words, is the specification you mention above the > full one for the object file format you will be working with?) > > Thanks for the update. > > Jon
From: CBFalconer on 5 Sep 2006 14:58 Philippe Auphelle wrote: > > What I'm processing is at this point strictly OMF coming from MS > MASM 7.x (aka ML). > >> But it looks as though you have a plan. > > Yes, that of writing a quick and dirty validation tool as a Delphi > Win32 console program to process the OMF files and check what I > have to. I don't need to process all the OMF types for that, just > half a dozen. I'll run it just before the link, it will take the > same file list and abort the build before the link if it finds an > error. > >> Do you have the specification for the object file format you >> need to process? > > Yes, thanks. The format is the "MS brew" of the OMF format, and > that one was easy to locate. It's a PDF file titled > > Tool Interface Standards (TIS) > Relocatable Object Module Format (OMF) Specification > Version 1.1 > (TIS Committee, May 1995) > (www.x86.org/ftp/manuals/tools/omf.pdf) > > This describes the OMF format as Microsoft and other dev tools > creators used it before MS decided to switch to COFF. That's > different enough from the pure Intel OMF to make interoperability > problematic, but the differences are documented well enough. > > Just in the unlikely case this can save someone some time... > sometime: > > For that kind of job, the most advanced linker I have found so far > is OptLink: It belongs to Digital Mars, in their Digital Mars > C/C++ package. I bought their CD (it's a bargain), but Optlink can > also be downloaded free from the Digital Mars site as part as the > C/C++ package: http://www.digitalmars.com/download/dmcpp.html > > OptLink can generate any type of 16-bit code (.com/.sys/.bin, DOS > EXE, Win 3.x EXE, OS/2 EXE, and Win32 32-bit PE .EXE. It has more > useful options than any other linker I could find today, and very > precise diags if something goes wrong in the linking process. > It only does OMF code, and it's not a locator (well, except in > the simple case when you can live with a COM or BIN file format). > > For the record, Optlink was initially from SLR Systems (great OMF > linker, and they had the best assembler, OptASM back then too). > It was sold long ago to Symantec, and Digital Mars now holds the > part of the Symantec portfolio that includes OptLink. > > Isn't it strange one has to recreate some basic tools like this > after all these years! /Ph. You can hardly go wrong with Steve Russels tools. He also built Z80ASM, SLRLNK, and SLRLIB for CP/M. I still have OPTASM on my system. About 7 years ago I contacted him to try to get rights to the CP/M stuff, with source. He said it all belonged to Symantec, and they never responded. At the time I had a very useful application, involving the Verifone packages, and my PPOE had literally thousands of those in the field. At that time Steve was working for Symantec, doing something with JIT compilation. As usual, Symantec kills everything it touches. -- "I'm the commander--see, I don't have to explain -- I don't need to explain why I say things. That's the interesting thing about being the President. Maybe somebody needs to explain to me why they say something, but I don't feel like I owe anybody an explanation." - George W. Bush, 2002-11-19
From: Philippe Auphelle on 7 Sep 2006 02:53
> You can hardly go wrong with Steve Russels tools. No doubt about this. I was one of the early users of the Optxxx tools, and I still have the original "black book" tech docs for OptASM, OptLink, Optlib: the whole family. OptASM was incomparably better than MASM at the time OptASM was alive - and more compatible with *all* MASM versions (and quirks) than any MASM version. The only problem has been that OptASM disappeared after the Symantec deal, and to my knowledge was never updated for 32-bit x86, nor for supporting long names, etc. Then MASM 6 / ML came up, fixed most bugs, inconsistencies and shortcomings and solved the speed issue, and brought a good number of interesting advanced features, such as automatic BP-addressing handling (locals and Invoke with parms), structured programming directives, etc. And as of today, while ML is again alive and evoluting, and OptLink still lives at Digital Mars, OptASM is nowhere to be seen. That's really too bad. CBFalconer wrote: > Philippe Auphelle wrote: >> What I'm processing is at this point strictly OMF coming from MS >> MASM 7.x (aka ML). >> >>> But it looks as though you have a plan. >> Yes, that of writing a quick and dirty validation tool as a Delphi >> Win32 console program to process the OMF files and check what I >> have to. I don't need to process all the OMF types for that, just >> half a dozen. I'll run it just before the link, it will take the >> same file list and abort the build before the link if it finds an >> error. >> >>> Do you have the specification for the object file format you >>> need to process? >> Yes, thanks. The format is the "MS brew" of the OMF format, and >> that one was easy to locate. It's a PDF file titled >> >> Tool Interface Standards (TIS) >> Relocatable Object Module Format (OMF) Specification >> Version 1.1 >> (TIS Committee, May 1995) >> (www.x86.org/ftp/manuals/tools/omf.pdf) >> >> This describes the OMF format as Microsoft and other dev tools >> creators used it before MS decided to switch to COFF. That's >> different enough from the pure Intel OMF to make interoperability >> problematic, but the differences are documented well enough. >> >> Just in the unlikely case this can save someone some time... >> sometime: >> >> For that kind of job, the most advanced linker I have found so far >> is OptLink: It belongs to Digital Mars, in their Digital Mars >> C/C++ package. I bought their CD (it's a bargain), but Optlink can >> also be downloaded free from the Digital Mars site as part as the >> C/C++ package: http://www.digitalmars.com/download/dmcpp.html >> >> OptLink can generate any type of 16-bit code (.com/.sys/.bin, DOS >> EXE, Win 3.x EXE, OS/2 EXE, and Win32 32-bit PE .EXE. It has more >> useful options than any other linker I could find today, and very >> precise diags if something goes wrong in the linking process. >> It only does OMF code, and it's not a locator (well, except in >> the simple case when you can live with a COM or BIN file format). >> >> For the record, Optlink was initially from SLR Systems (great OMF >> linker, and they had the best assembler, OptASM back then too). >> It was sold long ago to Symantec, and Digital Mars now holds the >> part of the Symantec portfolio that includes OptLink. >> >> Isn't it strange one has to recreate some basic tools like this >> after all these years! /Ph. > > You can hardly go wrong with Steve Russels tools. He also built > Z80ASM, SLRLNK, and SLRLIB for CP/M. I still have OPTASM on my > system. About 7 years ago I contacted him to try to get rights to > the CP/M stuff, with source. He said it all belonged to Symantec, > and they never responded. At the time I had a very useful > application, involving the Verifone packages, and my PPOE had > literally thousands of those in the field. At that time Steve was > working for Symantec, doing something with JIT compilation. > > As usual, Symantec kills everything it touches. > |