> 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.
> 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

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

"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.

"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.

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

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 implemented
> in Windows kernel components. Particulary ntdll.dll exports symbols like
> 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).

>
> 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

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.

"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

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