www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - coffimplib tool

reply "Walter Bright" <newshound digitalmars.com> writes:
I've written a small utility that will convert import libraries in Microsoft 
COFF format to the OMF format used by the Digital Mars linker. This should 
make it much easier to keep import libraries updated with whatever the 
latest from Microsoft is.

ftp://ftp.digitalmars.com/coffimplib.zip

Consider it a beta. Let me know about any problems with it.
Jan 02 2006
next sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dpaolp$1oek$1 digitaldaemon.com...

 I've written a small utility that will convert import libraries in 
 Microsoft COFF format to the OMF format used by the Digital Mars linker. 
 This should make it much easier to keep import libraries updated with 
 whatever the latest from Microsoft is.

 ftp://ftp.digitalmars.com/coffimplib.zip

 Consider it a beta. Let me know about any problems with it.


Thanks for this excellent tool. It converted all my Platform SDK libs, 
except for uuid.lib, complaining "uuid.lib is not an import library". 
Perhaps uuid.lib is a static library?
Jan 02 2006
next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"John C" <johnch_atms hotmail.com> wrote in message 
news:dpb0oj$21fo$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:dpaolp$1oek$1 digitaldaemon.com...

 I've written a small utility that will convert import libraries in 
 Microsoft COFF format to the OMF format used by the Digital Mars linker. 
 This should make it much easier to keep import libraries updated with 
 whatever the latest from Microsoft is.

 ftp://ftp.digitalmars.com/coffimplib.zip

 Consider it a beta. Let me know about any problems with it.


 Thanks for this excellent tool. It converted all my Platform SDK libs, 
 except for uuid.lib, complaining "uuid.lib is not an import library". 
 Perhaps uuid.lib is a static library?


Yes, as there is no uuid.dll. coffimplib only recognizes import symbols in 
the library, it's not a general coff object file format converter.
Jan 02 2006
prev sibling parent J C Calvarese <technocrat7 gmail.com> writes:
In article <dpb0oj$21fo$1 digitaldaemon.com>, John C says...

"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dpaolp$1oek$1 digitaldaemon.com...

 I've written a small utility that will convert import libraries in 
 Microsoft COFF format to the OMF format used by the Digital Mars linker. 
 This should make it much easier to keep import libraries updated with 
 whatever the latest from Microsoft is.

 ftp://ftp.digitalmars.com/coffimplib.zip

 Consider it a beta. Let me know about any problems with it.


Thanks for this excellent tool. It converted all my Platform SDK libs, 
except for uuid.lib, complaining "uuid.lib is not an import library". 
Perhaps uuid.lib is a static library? 


You might be able to use this to create a uuid.lib:
http://svn.dsource.org/projects/bindings/trunk/uuid_obj.d

(binary: http://svn.dsource.org/projects/bindings/trunk/lib/uuid.lib)

If you find something that I've left something out (I doubt the file is complete
due to the way Microsoft is always making things more complicated), you can
either let me know and I'll try to fix it or edit it in the SVN repository
yourself.

jcc7
Jan 02 2006
prev sibling next sibling parent reply Kevin <Kevin_member pathlink.com> writes:
In article <dpaolp$1oek$1 digitaldaemon.com>, Walter Bright says...

I've written a small utility that will convert import libraries in Microsoft 
COFF format to the OMF format used by the Digital Mars linker. This should 
make it much easier to keep import libraries updated with whatever the 
latest from Microsoft is.

ftp://ftp.digitalmars.com/coffimplib.zip

Consider it a beta. Let me know about any problems with it. 


If it's this easy to convert the format of the files why not add support for
coff files to the linker directly and remove the need to generate the omf format
files at all?  This would be one less possible source of error during
development.
Jan 03 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Kevin" <Kevin_member pathlink.com> wrote in message 
news:dpdr8t$3pe$1 digitaldaemon.com...

 In article <dpaolp$1oek$1 digitaldaemon.com>, Walter Bright says...

I've written a small utility that will convert import libraries in 
Microsoft
COFF format to the OMF format used by the Digital Mars linker. This should
make it much easier to keep import libraries updated with whatever the
latest from Microsoft is.

ftp://ftp.digitalmars.com/coffimplib.zip

Consider it a beta. Let me know about any problems with it.


 If it's this easy to convert the format of the files why not add support 
 for
 coff files to the linker directly and remove the need to generate the omf 
 format
 files at all?  This would be one less possible source of error during
 development.


Because the linker is very difficult to modify (it's entirely in assembler).
Jan 03 2006
next sibling parent reply BCS <BCS_member pathlink.com> writes:
Walter Bright wrote:

 "Kevin" <Kevin_member pathlink.com> wrote in message 
 news:dpdr8t$3pe$1 digitaldaemon.com...
 

In article <dpaolp$1oek$1 digitaldaemon.com>, Walter Bright says...


I've written a small utility that will convert import libraries in 
Microsoft
COFF format to the OMF format used by the Digital Mars linker. This should
make it much easier to keep import libraries updated with whatever the
latest from Microsoft is.

ftp://ftp.digitalmars.com/coffimplib.zip

Consider it a beta. Let me know about any problems with it.


If it's this easy to convert the format of the files why not add support 
for
coff files to the linker directly and remove the need to generate the omf 
format
files at all?  This would be one less possible source of error during
development.


 
 
 Because the linker is very difficult to modify (it's entirely in assembler). 
 
 


How about a wrapper script that does that work? (Finds *.dll in the 
command line, calls coffumplib, ...)
Jan 03 2006
parent reply "Chris Miller" <chris dprogramming.com> writes:
On Tue, 03 Jan 2006 14:35:27 -0500, BCS <BCS_member pathlink.com> wrote:


 If it's this easy to convert the format of the files why not add  
 support for
 coff files to the linker directly and remove the need to generate the  
 omf format
 files at all?  This would be one less possible source of error during
 development.


   Because the linker is very difficult to modify (it's entirely in  
 assembler).


 How about a wrapper script that does that work? (Finds *.dll in the  
 command line, calls coffumplib, ...)


I've been thinking about this one for awhile. How about a "dlink" that  
does D pre-linker magic. The current C/C++ linker seems to be too low  
level for some of D's features, so this intermediate linker could bridge  
the gap. Perhaps even emitting .dobj files containing extra info and the  
embedded .obj file.
Jan 03 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Chris Miller wrote:


 On Tue, 03 Jan 2006 14:35:27 -0500, BCS <BCS_member pathlink.com> wrote:
 

 If it's this easy to convert the format of the files why not add
 support for
 coff files to the linker directly and remove the need to generate the
 omf format
 files at all?  This would be one less possible source of error during
 development.


   Because the linker is very difficult to modify (it's entirely in
 assembler).


 How about a wrapper script that does that work? (Finds *.dll in the
 command line, calls coffumplib, ...)


 
 I've been thinking about this one for awhile. How about a "dlink" that
 does D pre-linker magic. The current C/C++ linker seems to be too low
 level for some of D's features, so this intermediate linker could bridge
 the gap. Perhaps even emitting .dobj files containing extra info and the
 embedded .obj file.


Hmm, I might misunderstand what you're suggesting here, but could it be
something like DDL?

http://trac.dsource.org/projects/ddl/

Lars Ivar Igesund
Jan 03 2006
parent "Chris Miller" <chris dprogramming.com> writes:
On Tue, 03 Jan 2006 15:03:11 -0500, Lars Ivar Igesund  
<larsivar igesund.net> wrote:


 Chris Miller wrote:


 On Tue, 03 Jan 2006 14:35:27 -0500, BCS <BCS_member pathlink.com> wrote:


 If it's this easy to convert the format of the files why not add
 support for
 coff files to the linker directly and remove the need to generate the
 omf format
 files at all?  This would be one less possible source of error during
 development.


   Because the linker is very difficult to modify (it's entirely in
 assembler).


 How about a wrapper script that does that work? (Finds *.dll in the
 command line, calls coffumplib, ...)


 I've been thinking about this one for awhile. How about a "dlink" that
 does D pre-linker magic. The current C/C++ linker seems to be too low
 level for some of D's features, so this intermediate linker could bridge
 the gap. Perhaps even emitting .dobj files containing extra info and the
 embedded .obj file.


 Hmm, I might misunderstand what you're suggesting here, but could it be
 something like DDL?

 http://trac.dsource.org/projects/ddl/

 Lars Ivar Igesund


Don't think so, what I'm talking about is static linking. A layer between  
dmd and link.
DDL is pretty cool, though.
Jan 03 2006
prev sibling parent "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Walter Bright" <newshound digitalmars.com> skrev i en meddelelse 
news:dpei17$r05$1 digitaldaemon.com...


 Because the linker is very difficult to modify (it's entirely in 
 assembler).


Why not writing a linker in D? :-)

Regards,
Martin
Jan 05 2006
prev sibling next sibling parent reply "Todor Totev" <umbra.tenebris list.ru> writes:
 I've written a small utility that will convert import libraries in  =



 Microsoft COFF format to the OMF format used by the Digital Mars linke=


r.

 Consider it a beta. Let me know about any problems with it.


It worked like a charm on my small test programme.
I converted latest lib files from Windows Server 2003 SP1 PlatformSDK
and replaced original ones from dmc. No issues and I'm using functions
 from kernel32/advapi32/ntdll.

If someone find this valuable I can post the converted files in this  =

newsgroup -
the archive is only 375KiB. But I'm sure that users of dmc will also  =

benefit from them.

Thank you for the wonderful utility,
Todor
Jan 03 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Todor Totev" <umbra.tenebris list.ru> wrote in message 
news:op.s2tnq5utihwmk4 todor-1-xp.sanbolic.local...

It worked like a charm on my small test programme.
I converted latest lib files from Windows Server 2003 SP1 PlatformSDK
and replaced original ones from dmc. No issues and I'm using functions
 from kernel32/advapi32/ntdll.


Great!


 If someone find this valuable I can post the converted files in this 
 newsgroup -
 the archive is only 375KiB. But I'm sure that users of dmc will also 
 benefit from them.


I'd rather you didn't, due to licensing issues. Microsoft may not allow 
redistribution without permission.
Jan 03 2006
prev sibling next sibling parent reply "Todor Totev" <umbra.tenebris list.ru> writes:
It is a little offtopic but I'll ask here:
It appears that functions belonging to C run-time library are implemente=
d  =

in
Windows kernel components. Particulary ntdll.dll exports symbols like  =

snprintf,
memcpy etc which clashes with snn.
I checked the documentation of optlink and it appears that it first chec=
ks  =

for
names given via command-line and than those mentioned in obj files.
Am I right? Also I think that snn.lib is the CRT of Digital Mars, isn't =
it?
How dmd tells the linker to check for snn.lib?

Regards,
Todor
Jan 03 2006
next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Todor Totev" <umbra.tenebris list.ru> wrote in message
news:op.s2tnzsnbihwmk4 todor-1-xp.sanbolic.local...

It appears that functions belonging to C run-time library are implemented
in
Windows kernel components. Particulary ntdll.dll exports symbols like
snprintf, memcpy etc which clashes with snn.
I checked the documentation of optlink and it appears that it first checks
for
names given via command-line and than those mentioned in obj files.
Am I right?


It checks the obj files listed on the linker command line first.


 Also I think that snn.lib is the CRT of Digital Mars, isn't it?


Yes.


How dmd tells the linker to check for snn.lib?


See www.digitalmars.com/ctg/acrtused.html. A reference to snn.lib is 
embedded into the .obj file.
Jan 03 2006
prev sibling parent reply "Kris" <fu bar.com> writes:
I'd very much like to see these functions exposed ~ they may help Ares 
become independent of snn.lib. Is there a webpage that describes the kernel 
functions?

Thx;

"Todor Totev" <umbra.tenebris list.ru> wrote ...
It is a little offtopic but I'll ask here:
It appears that functions belonging to C run-time library are implemented
in
Windows kernel components. Particulary ntdll.dll exports symbols like
snprintf,
memcpy etc which clashes with snn.
I checked the documentation of optlink and it appears that it first checks
for
names given via command-line and than those mentioned in obj files.
Am I right? Also I think that snn.lib is the CRT of Digital Mars, isn't it?
How dmd tells the linker to check for snn.lib?

Regards,
Todor
Jan 03 2006
parent reply "Todor Totev" <umbra.tenebris list.ru> writes:
On Wed, 04 Jan 2006 00:20:58 +0200, Kris <fu bar.com> wrote:


 I'd very much like to see these functions exposed ~ they may help Ares=



 become independent of snn.lib. Is there a webpage that describes the  =



 kernel functions?

 "Todor Totev" <umbra.tenebris list.ru> wrote ...
 It appears that functions belonging to C run-time library are implemen=


ted

 in Windows kernel components. Particulary ntdll.dll exports symbols li=


ke

 snprintf, memcpy etc which clashes with snn.


Any MSDN page will do the trick - they are like usual MS CRT library  =

functions
with the exception that all non-vararg ones are __stdcall (in MS terms).=


I will advise you to stay away from them.
Ntdll is available only on NT based systems. Also it implements only
MS view of CRT so you will have not 80-bit reals.
Third, it may do weird things like jumping to kernel mode to do its work=

(I know that Windows kernel ntoskrnl.exe exports the same symbols -
if you don't believe me, grab Dependency Wlker from
http://www.dependencywalker.com/ and look at its exports).
Next it may implement CRT functions to various degrees - ex.
Windows 2000 do not have snwprintf but XP does it.
(As a side note, the so called Safe String library from MS do need
snwprintf so for Windows2000 MS just ripped their own CRT and put it
in kernel mode - and the "simple" string library comes complete
with exception support (exsup*.obj etc) - it's a real fun to see how
MS hacks themselves to do the work).
Jan 04 2006
parent reply "Todor Totev" <umbra.tenebris list.ru> writes:
 I will advise you to stay away from them.
 Ntdll is available only on NT based systems. Also it implements only
 MS view of CRT so you will have not 80-bit reals.
 Third, it may do weird things like jumping to kernel mode to do its wo=


rk

 (I know that Windows kernel ntoskrnl.exe exports the same symbols -
 if you don't believe me, grab Dependency Wlker from
 http://www.dependencywalker.com/ and look at its exports).
 Next it may implement CRT functions to various degrees - ex.
 Windows 2000 do not have snwprintf but XP does it.
 (As a side note, the so called Safe String library from MS do need
 snwprintf so for Windows2000 MS just ripped their own CRT and put it
 in kernel mode - and the "simple" string library comes complete
 with exception support (exsup*.obj etc) - it's a real fun to see how
 MS hacks themselves to do the work).


Sorry, I pressed the Send button by mistake.
I think that if you want to work with library that comes with OS you can=

take the path of MinGW - they use msvcrt.dll which comes with Win95OSR2
and all up systems.
Anyway if you wish to play the NTDll game, contact me at
umbra.tenebris -at- list.ru and i will provide you all the information I=
  =

can.

Best regards,
Todor Totev
Jan 04 2006
parent kris <fu bar.org> writes:
Todor Totev wrote:

 I will advise you to stay away from them.
 Ntdll is available only on NT based systems. Also it implements only
 MS view of CRT so you will have not 80-bit reals.
 Third, it may do weird things like jumping to kernel mode to do its work
 (I know that Windows kernel ntoskrnl.exe exports the same symbols -
 if you don't believe me, grab Dependency Wlker from
 http://www.dependencywalker.com/ and look at its exports).
 Next it may implement CRT functions to various degrees - ex.
 Windows 2000 do not have snwprintf but XP does it.
 (As a side note, the so called Safe String library from MS do need
 snwprintf so for Windows2000 MS just ripped their own CRT and put it
 in kernel mode - and the "simple" string library comes complete
 with exception support (exsup*.obj etc) - it's a real fun to see how
 MS hacks themselves to do the work).


 
 
 Sorry, I pressed the Send button by mistake.
 I think that if you want to work with library that comes with OS you can
 take the path of MinGW - they use msvcrt.dll which comes with Win95OSR2
 and all up systems.
 Anyway if you wish to play the NTDll game, contact me at
 umbra.tenebris -at- list.ru and i will provide you all the information 
 I  can.
 
 Best regards,
 Todor Totev


Thanks, Todor;

That all sounds like good advice.
Jan 04 2006
prev sibling parent reply =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
On Mon, 02 Jan 2006 09:36:03 +0100, Walter Bright  
<newshound digitalmars.com> wrote:


 I've written a small utility that will convert import libraries in  
 Microsoft COFF format to the OMF format used by the Digital Mars  
 linker. This should make it much easier to keep import libraries  
 updated with whatever the latest from Microsoft is.


Does this tool work for non-MS files as well? I think so. So, it  
replaces the coff2omf tool?

-- 
Robert M. Münch
Management & IT Freelancer
http://www.robertmuench.de
Jan 30 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Robert M. Münch" <robert.muench robertmuench.de> wrote in message 
news:op.s3692dkj3b5602 news.digitalmars.com...

 On Mon, 02 Jan 2006 09:36:03 +0100, Walter Bright 
 <newshound digitalmars.com> wrote:


 I've written a small utility that will convert import libraries in 
 Microsoft COFF format to the OMF format used by the Digital Mars  linker. 
 This should make it much easier to keep import libraries  updated with 
 whatever the latest from Microsoft is.


 Does this tool work for non-MS files as well?


If they are import libraries in Microsoft's COFF format. Otherwise, no.


 I think so. So, it replaces the coff2omf tool?


For import libraries only.
Jan 31 2006