digitalmars.D.announce - coffimplib tool
- "Walter Bright" <newshound digitalmars.com> Jan 02 2006
- "John C" <johnch_atms hotmail.com> Jan 02 2006
- "Walter Bright" <newshound digitalmars.com> Jan 02 2006
- J C Calvarese <technocrat7 gmail.com> Jan 02 2006
- Kevin <Kevin_member pathlink.com> Jan 03 2006
- "Walter Bright" <newshound digitalmars.com> Jan 03 2006
- BCS <BCS_member pathlink.com> Jan 03 2006
- "Chris Miller" <chris dprogramming.com> Jan 03 2006
- Lars Ivar Igesund <larsivar igesund.net> Jan 03 2006
- "Chris Miller" <chris dprogramming.com> Jan 03 2006
- "Martin M. Pedersen" <martin moeller-pedersen.dk> Jan 05 2006
- "Todor Totev" <umbra.tenebris list.ru> Jan 03 2006
- "Walter Bright" <newshound digitalmars.com> Jan 03 2006
- "Todor Totev" <umbra.tenebris list.ru> Jan 03 2006
- "Walter Bright" <newshound digitalmars.com> Jan 03 2006
- "Kris" <fu bar.com> Jan 03 2006
- "Todor Totev" <umbra.tenebris list.ru> Jan 04 2006
- "Todor Totev" <umbra.tenebris list.ru> Jan 04 2006
- kris <fu bar.org> Jan 04 2006
- =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> Jan 30 2006
- "Walter Bright" <newshound digitalmars.com> Jan 31 2006
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
"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
"Walter Bright" <newshound digitalmars.com> "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
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
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
"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
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
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.
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
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.
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
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.
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
"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
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=
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
"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
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
"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
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
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=
in Windows kernel components. Particulary ntdll.dll exports symbols li=
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
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=
(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
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
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
"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