64-bit build questions

NTDEV
1

Somewhat long and rambling but I think I get to some kind of point at the
end :slight_smile:

Every time I build a driver, I wind up with 6 different .sys files - checked
& free for x86, amd64 and ia64. If the driver also has a support DLL, App or
whatever, well, do the math.

I posted a note a while back about what editor to use and the consensus
seems to be to stick with VS 6. That’s fine with me. I’ve got it set up now
to use the DDK compiler and it seems to work OK for browsing driver code.
(Using the VS driver configuration seems to break everything for DLLs, COM
stuff and GUI apps. I need to do a little more work.)

I’m not happy with the idea that I can only have a WIN32 environment in VS 6
(I know about VS for Alpha giving you other environments but that doesn’t
help) and I don’t like the idea of kludging some sort of batch file ‘hidden’
under some obscure config tab to build the other stuff.

At the moment, I’m leaning toward using Microsoft’s build/dirs/sources
mechanism to build everything for all platforms. All of NT/2000/XP etc is
built this way so it’s got to work. I see the following advantages:

  1. Microsoft shows no signs of changing this process.
  2. The 64-bit environments are in a state of flux and will be for some years
    to come. Letting Microsoft fix ‘my’ tools at the same they fix theirs is a
    good thing. 3. Generally speaking, I don’t have to document some home-grown
    build process and the people I do piece work for can pass the projects on to
    others with a high expectation that they will work.

On the other hand, I see some disadvantages:

  1. Everything is built as a .lib and these are used to link executables.
    While there’s nothing wrong with this, it gets kind of messy when you take
    an old VS project for instance that has stuff scattered all over everywhere.
  2. What files can be in what directories is very inflexible. 3. At the
    moment, it seems that all DLLs must have .def files to define exports. Very
    few people use these any more so you have to make them up (and disable the
    _dllexport stuff).

So, my questions:

Does anyone else do this? (I know everyone uses the tools for drivers but
what about other stuff like GUI apps and COM objects?)

Are there any tools to help manage the dirs & sources files? (WHY didn’t
they stick some kind of extension on these files? Grumble.) I need to do
some more learning on this but at the moment, using a VS project file and/or
an exported makefile to build a sources file looks *real* tedious.

Are there any documents other than the DDK that show the range of useful
options in the sources file? Some of the stuff documented in the latest DDK
isn’t implemented and some of it works… well… differently than expected.

I wouldn’t be going down this path if it weren’t for all the different
platforms. Any thoughts appreciated.

Regards,
Mickey.

2

> 2. What files can be in what directories is very inflexible. 3. At the

moment, it seems that all DLLs must have .def files to define exports. Very
few people use these any more so you have to make them up (and disable the
_dllexport stuff).

.DEF file is the only sane way of exporting from DLLs. __dllexport results in
mangled names, which in turn result in problems using GetProcAddress for such a
DLL.

Are there any documents other than the DDK that show the range of useful
options in the sources file?

MAKEFILE.DEF and platform-specific .MK files themselves.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

3

Do your user-mode components really need to be 64-bit? If they don’t really
exercise 64-bit functionality, then you can setup your 64-bit drivers to
detect when they are called by 32-bit apps. If you define structures
carefully enough there will be very little difference between the way the
driver handles 32-bit and 64-bit user-mode calls an dlittel difference
between your 32-bit driver and your 64-bit driver.

This wat all ure-mode components remain 32-bit. You are still stuck with all
the driver permutations, however.

Thomas F. Divine

“Charles Lane” wrote in message news:xxxxx@ntdev…
Somewhat long and rambling but I think I get to some kind of point at the
end :slight_smile:

Every time I build a driver, I wind up with 6 different .sys files - checked
& free for x86, amd64 and ia64. If the driver also has a support DLL, App or
whatever, well, do the math.

I posted a note a while back about what editor to use and the consensus
seems to be to stick with VS 6. That’s fine with me. I’ve got it set up now
to use the DDK compiler and it seems to work OK for browsing driver code.
(Using the VS driver configuration seems to break everything for DLLs, COM
stuff and GUI apps. I need to do a little more work.)

I’m not happy with the idea that I can only have a WIN32 environment in VS 6
(I know about VS for Alpha giving you other environments but that doesn’t
help) and I don’t like the idea of kludging some sort of batch file ‘hidden’
under some obscure config tab to build the other stuff.

At the moment, I’m leaning toward using Microsoft’s build/dirs/sources
mechanism to build everything for all platforms. All of NT/2000/XP etc is
built this way so it’s got to work. I see the following advantages:

1. Microsoft shows no signs of changing this process.
2. The 64-bit environments are in a state of flux and will be for some years
to come. Letting Microsoft fix ‘my’ tools at the same they fix theirs is a
good thing. 3. Generally speaking, I don’t have to document some home-grown
build process and the people I do piece work for can pass the projects on to
others with a high expectation that they will work.

On the other hand, I see some disadvantages:

1. Everything is built as a .lib and these are used to link executables.
While there’s nothing wrong with this, it gets kind of messy when you take
an old VS project for instance that has stuff scattered all over everywhere.
2. What files can be in what directories is very inflexible. 3. At the
moment, it seems that all DLLs must have .def files to define exports. Very
few people use these any more so you have to make them up (and disable the
_dllexport stuff).

So, my questions:

Does anyone else do this? (I know everyone uses the tools for drivers but
what about other stuff like GUI apps and COM objects?)

Are there any tools to help manage the dirs & sources files? (WHY didn’t
they stick some kind of extension on these files? Grumble.) I need to do
some more learning on this but at the moment, using a VS project file and/or
an exported makefile to build a sources file looks real tedious.

Are there any documents other than the DDK that show the range of useful
options in the sources file? Some of the stuff documented in the latest DDK
isn’t implemented and some of it works… well… differently than expected.

I wouldn’t be going down this path if it weren’t for all the different
platforms. Any thoughts appreciated.

Regards,
Mickey.

4

Faux. Appropriate use of exern “C” combined with __declspec(dllexport)
produces clean, unmangled exports ever time.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Friday, April 16, 2004 6:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 64-bit build questions

  1. What files can be in what directories is very inflexible. 3. At the

moment, it seems that all DLLs must have .def files to define exports.

Very few people use these any more so you have to make them up (and
disable the _dllexport stuff).

.DEF file is the only sane way of exporting from DLLs. __dllexport
results in mangled names, which in turn result in problems using
GetProcAddress for such a DLL.

Are there any documents other than the DDK that show the range of
useful options in the sources file?

MAKEFILE.DEF and platform-specific .MK files themselves.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@dchbk.us
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

The combination of extern “C” and __declspec(dllexport) produces the
“stdcall” style exports of

_MyFuncWithThreeParameters@12

If you will also add __cdecl there - you will have

_MyFuncWithThreeParameters

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “benson margulies”
To: “Windows System Software Devs Interest List”
Sent: Saturday, April 17, 2004 10:34 PM
Subject: RE: [ntdev] 64-bit build questions

> Faux. Appropriate use of exern “C” combined with __declspec(dllexport)
> produces clean, unmangled exports ever time.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> Shatskih
> Sent: Friday, April 16, 2004 6:42 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] 64-bit build questions
>
>
> > 2. What files can be in what directories is very inflexible. 3. At the
>
> > moment, it seems that all DLLs must have .def files to define exports.
>
> > Very few people use these any more so you have to make them up (and
> > disable the _dllexport stuff).
>
> .DEF file is the only sane way of exporting from DLLs.__dllexport
> results in mangled names, which in turn result in problems using
> GetProcAddress for such a DLL.
>
> > Are there any documents other than the DDK that show the range of
> > useful options in the sources file?
>
> MAKEFILE.DEF and platform-specific .MK files themselves.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@dchbk.us
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

6

I don’t get hit with those leading _'s. I do this constantly for
user-mode stuff.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Saturday, April 17, 2004 2:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 64-bit build questions

The combination of extern “C” and __declspec(dllexport) produces the
“stdcall” style exports of

_MyFuncWithThreeParameters@12

If you will also add __cdecl there - you will have

_MyFuncWithThreeParameters

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “benson margulies”
To: “Windows System Software Devs Interest List”
Sent: Saturday, April 17, 2004 10:34 PM
Subject: RE: [ntdev] 64-bit build questions

> Faux. Appropriate use of exern “C” combined with __declspec(dllexport)

> produces clean, unmangled exports ever time.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> Shatskih
> Sent: Friday, April 16, 2004 6:42 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] 64-bit build questions
>
>
> > 2. What files can be in what directories is very inflexible. 3. At
> > the
>
> > moment, it seems that all DLLs must have .def files to define
> > exports.
>
> > Very few people use these any more so you have to make them up (and
> > disable the _dllexport stuff).
>
> .DEF file is the only sane way of exporting from DLLs.__dllexport
> results in mangled names, which in turn result in problems using
> GetProcAddress for such a DLL.
>
> > Are there any documents other than the DDK that show the range of
> > useful options in the sources file?
>
> MAKEFILE.DEF and platform-specific .MK files themselves.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@dchbk.us
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@dchbk.us
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

If the name in the header file (and in the reference) mismatches the name
for GetProcAddress - this is IMHO bad.

Another evilness of __declspec(dllexport) is that the exports start to be
scattered all over the source, while the .DEF file is a centralized list of all
exports. This is encapsulation.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “benson margulies”
To: “Windows System Software Devs Interest List”
Sent: Saturday, April 17, 2004 11:56 PM
Subject: RE: [ntdev] 64-bit build questions

> I don’t get hit with those leading _'s. I do this constantly for
> user-mode stuff.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> Shatskih
> Sent: Saturday, April 17, 2004 2:42 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] 64-bit build questions
>
>
> The combination of extern “C” and __declspec(dllexport) produces the
> “stdcall” style exports of
>
> _MyFuncWithThreeParameters@12
>
> If you will also add__cdecl there - you will have
>
> _MyFuncWithThreeParameters
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “benson margulies”
> To: “Windows System Software Devs Interest List”
> Sent: Saturday, April 17, 2004 10:34 PM
> Subject: RE: [ntdev] 64-bit build questions
>
>
> > Faux. Appropriate use of exern “C” combined with __declspec(dllexport)
>
> > produces clean, unmangled exports ever time.
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> > Shatskih
> > Sent: Friday, April 16, 2004 6:42 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] 64-bit build questions
> >
> >
> > > 2. What files can be in what directories is very inflexible. 3. At
> > > the
> >
> > > moment, it seems that all DLLs must have .def files to define
> > > exports.
> >
> > > Very few people use these any more so you have to make them up (and
> > > disable the _dllexport stuff).
> >
> > .DEF file is the only sane way of exporting from DLLs.__dllexport
> > results in mangled names, which in turn result in problems using
> > GetProcAddress for such a DLL.
> >
> > > Are there any documents other than the DDK that show the range of
> > > useful options in the sources file?
> >
> > MAKEFILE.DEF and platform-specific .MK files themselves.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@dchbk.us
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@dchbk.us
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

8

I should not shout out loud, when it comes down to 64-bit. But one thing
to notice, as was well known that __declspec(…) is better when it comes
down to linkage fixes. It does have a better performance under 32bit, if
that is
one needs to address. I think Riechter and Matt broke their fingure while
writing it again and again about it :).Again, performance is the last step
in the process …

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Saturday, April 17, 2004 1:13 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 64-bit build questions

If the name in the header file (and in the reference) mismatches the
name
for GetProcAddress - this is IMHO bad.

Another evilness of __declspec(dllexport) is that the exports start to
be
scattered all over the source, while the .DEF file is a centralized list of
all
exports. This is encapsulation.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “benson margulies”
To: “Windows System Software Devs Interest List”
Sent: Saturday, April 17, 2004 11:56 PM
Subject: RE: [ntdev] 64-bit build questions

> I don’t get hit with those leading _'s. I do this constantly for
> user-mode stuff.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> Shatskih
> Sent: Saturday, April 17, 2004 2:42 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] 64-bit build questions
>
>
> The combination of extern “C” and __declspec(dllexport) produces the
> “stdcall” style exports of
>
> _MyFuncWithThreeParameters@12
>
> If you will also add__cdecl there - you will have
>
> _MyFuncWithThreeParameters
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “benson margulies”
> To: “Windows System Software Devs Interest List”
> Sent: Saturday, April 17, 2004 10:34 PM
> Subject: RE: [ntdev] 64-bit build questions
>
>
> > Faux. Appropriate use of exern “C” combined with __declspec(dllexport)
>
> > produces clean, unmangled exports ever time.
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> > Shatskih
> > Sent: Friday, April 16, 2004 6:42 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] 64-bit build questions
> >
> >
> > > 2. What files can be in what directories is very inflexible. 3. At
> > > the
> >
> > > moment, it seems that all DLLs must have .def files to define
> > > exports.
> >
> > > Very few people use these any more so you have to make them up (and
> > > disable the _dllexport stuff).
> >
> > .DEF file is the only sane way of exporting from DLLs.__dllexport
> > results in mangled names, which in turn result in problems using
> > GetProcAddress for such a DLL.
> >
> > > Are there any documents other than the DDK that show the range of
> > > useful options in the sources file?
> >
> > MAKEFILE.DEF and platform-specific .MK files themselves.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@dchbk.us
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@dchbk.us
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

If I’m correct, this performance increase (of 1 jump) is due to
__declspec(dllimport), and not __declspec(dllexport).

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Prokash Sinha”
To: “Windows System Software Devs Interest List”
Sent: Sunday, April 18, 2004 1:36 AM
Subject: RE: [ntdev] 64-bit build questions

> I should not shout out loud, when it comes down to 64-bit. But one thing
> to notice, as was well known that __declspec(…) is better when it comes
> down to linkage fixes. It does have a better performance under 32bit, if
> that is
> one needs to address. I think Riechter and Matt broke their fingure while
> writing it again and again about it :).Again, performance is the last step
> in the process …
>
> -pro
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> Sent: Saturday, April 17, 2004 1:13 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] 64-bit build questions
>
>
> If the name in the header file (and in the reference) mismatches the
> name
> for GetProcAddress - this is IMHO bad.
>
> Another evilness of__declspec(dllexport) is that the exports start to
> be
> scattered all over the source, while the .DEF file is a centralized list of
> all
> exports. This is encapsulation.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “benson margulies”
> To: “Windows System Software Devs Interest List”
> Sent: Saturday, April 17, 2004 11:56 PM
> Subject: RE: [ntdev] 64-bit build questions
>
>
> > I don’t get hit with those leading _'s. I do this constantly for
> > user-mode stuff.
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> > Shatskih
> > Sent: Saturday, April 17, 2004 2:42 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] 64-bit build questions
> >
> >
> > The combination of extern “C” and __declspec(dllexport) produces the
> > “stdcall” style exports of
> >
> > _MyFuncWithThreeParameters@12
> >
> > If you will also add__cdecl there - you will have
> >
> > _MyFuncWithThreeParameters
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > ----- Original Message -----
> > From: “benson margulies”
> > To: “Windows System Software Devs Interest List”
> > Sent: Saturday, April 17, 2004 10:34 PM
> > Subject: RE: [ntdev] 64-bit build questions
> >
> >
> > > Faux. Appropriate use of exern “C” combined with __declspec(dllexport)
> >
> > > produces clean, unmangled exports ever time.
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> > > Shatskih
> > > Sent: Friday, April 16, 2004 6:42 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] 64-bit build questions
> > >
> > >
> > > > 2. What files can be in what directories is very inflexible. 3. At
> > > > the
> > >
> > > > moment, it seems that all DLLs must have .def files to define
> > > > exports.
> > >
> > > > Very few people use these any more so you have to make them up (and
> > > > disable the _dllexport stuff).
> > >
> > > .DEF file is the only sane way of exporting from DLLs.__dllexport
> > > results in mangled names, which in turn result in problems using
> > > GetProcAddress for such a DLL.
> > >
> > > > Are there any documents other than the DDK that show the range of
> > > > useful options in the sources file?
> > >
> > > MAKEFILE.DEF and platform-specific .MK files themselves.
> > >
> > > Maxim Shatskih, Windows DDK MVP
> > > StorageCraft Corporation
> > > xxxxx@storagecraft.com
> > > http://www.storagecraft.com
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@dchbk.us
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@dchbk.us
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

10

I think Ur assertion make sense, w/o looking thru PE discussion. Also
that one jump could cause branch prediction problem, not sure though. So I
will stop digressing …

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Saturday, April 17, 2004 2:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 64-bit build questions

If I’m correct, this performance increase (of 1 jump) is due to
__declspec(dllimport), and not __declspec(dllexport).

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Prokash Sinha”
To: “Windows System Software Devs Interest List”
Sent: Sunday, April 18, 2004 1:36 AM
Subject: RE: [ntdev] 64-bit build questions

> I should not shout out loud, when it comes down to 64-bit. But one thing
> to notice, as was well known that __declspec(…) is better when it comes
> down to linkage fixes. It does have a better performance under 32bit, if
> that is
> one needs to address. I think Riechter and Matt broke their fingure while
> writing it again and again about it :).Again, performance is the last step
> in the process …
>
> -pro
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> Sent: Saturday, April 17, 2004 1:13 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] 64-bit build questions
>
>
> If the name in the header file (and in the reference) mismatches the
> name
> for GetProcAddress - this is IMHO bad.
>
> Another evilness of__declspec(dllexport) is that the exports start to
> be
> scattered all over the source, while the .DEF file is a centralized list
of
> all
> exports. This is encapsulation.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “benson margulies”
> To: “Windows System Software Devs Interest List”
> Sent: Saturday, April 17, 2004 11:56 PM
> Subject: RE: [ntdev] 64-bit build questions
>
>
> > I don’t get hit with those leading _'s. I do this constantly for
> > user-mode stuff.
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> > Shatskih
> > Sent: Saturday, April 17, 2004 2:42 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] 64-bit build questions
> >
> >
> > The combination of extern “C” and __declspec(dllexport) produces the
> > “stdcall” style exports of
> >
> > _MyFuncWithThreeParameters@12
> >
> > If you will also add__cdecl there - you will have
> >
> > _MyFuncWithThreeParameters
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > ----- Original Message -----
> > From: “benson margulies”
> > To: “Windows System Software Devs Interest List”
> > Sent: Saturday, April 17, 2004 10:34 PM
> > Subject: RE: [ntdev] 64-bit build questions
> >
> >
> > > Faux. Appropriate use of exern “C” combined with __declspec(dllexport)
> >
> > > produces clean, unmangled exports ever time.
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> > > Shatskih
> > > Sent: Friday, April 16, 2004 6:42 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] 64-bit build questions
> > >
> > >
> > > > 2. What files can be in what directories is very inflexible. 3. At
> > > > the
> > >
> > > > moment, it seems that all DLLs must have .def files to define
> > > > exports.
> > >
> > > > Very few people use these any more so you have to make them up (and
> > > > disable the _dllexport stuff).
> > >
> > > .DEF file is the only sane way of exporting from DLLs.__dllexport
> > > results in mangled names, which in turn result in problems using
> > > GetProcAddress for such a DLL.
> > >
> > > > Are there any documents other than the DDK that show the range of
> > > > useful options in the sources file?
> > >
> > > MAKEFILE.DEF and platform-specific .MK files themselves.
> > >
> > > Maxim Shatskih, Windows DDK MVP
> > > StorageCraft Corporation
> > > xxxxx@storagecraft.com
> > > http://www.storagecraft.com
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@dchbk.us
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@dchbk.us
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

11

Any jumps will cause it, and in this particular case it is 2 jumps vs. 1
jump.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Prokash Sinha”
To: “Windows System Software Devs Interest List”
Sent: Sunday, April 18, 2004 2:56 AM
Subject: RE: [ntdev] 64-bit build questions

> I think Ur assertion make sense, w/o looking thru PE discussion. Also
> that one jump could cause branch prediction problem, not sure though. So I
> will stop digressing …
>
> -pro
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> Sent: Saturday, April 17, 2004 2:43 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] 64-bit build questions
>
>
> If I’m correct, this performance increase (of 1 jump) is due to
> __declspec(dllimport), and not__declspec(dllexport).
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “Prokash Sinha”
> To: “Windows System Software Devs Interest List”
> Sent: Sunday, April 18, 2004 1:36 AM
> Subject: RE: [ntdev] 64-bit build questions
>
>
> > I should not shout out loud, when it comes down to 64-bit. But one thing
> > to notice, as was well known that __declspec(…) is better when it comes
> > down to linkage fixes. It does have a better performance under 32bit, if
> > that is
> > one needs to address. I think Riechter and Matt broke their fingure while
> > writing it again and again about it :).Again, performance is the last step
> > in the process …
> >
> > -pro
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> > Sent: Saturday, April 17, 2004 1:13 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] 64-bit build questions
> >
> >
> > If the name in the header file (and in the reference) mismatches the
> > name
> > for GetProcAddress - this is IMHO bad.
> >
> > Another evilness of__declspec(dllexport) is that the exports start to
> > be
> > scattered all over the source, while the .DEF file is a centralized list
> of
> > all
> > exports. This is encapsulation.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > ----- Original Message -----
> > From: “benson margulies”
> > To: “Windows System Software Devs Interest List”
> > Sent: Saturday, April 17, 2004 11:56 PM
> > Subject: RE: [ntdev] 64-bit build questions
> >
> >
> > > I don’t get hit with those leading _'s. I do this constantly for
> > > user-mode stuff.
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> > > Shatskih
> > > Sent: Saturday, April 17, 2004 2:42 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] 64-bit build questions
> > >
> > >
> > > The combination of extern “C” and __declspec(dllexport) produces the
> > > “stdcall” style exports of
> > >
> > > _MyFuncWithThreeParameters@12
> > >
> > > If you will also add__cdecl there - you will have
> > >
> > > _MyFuncWithThreeParameters
> > >
> > > Maxim Shatskih, Windows DDK MVP
> > > StorageCraft Corporation
> > > xxxxx@storagecraft.com
> > > http://www.storagecraft.com
> > >
> > >
> > > ----- Original Message -----
> > > From: “benson margulies”
> > > To: “Windows System Software Devs Interest List”
> > > Sent: Saturday, April 17, 2004 10:34 PM
> > > Subject: RE: [ntdev] 64-bit build questions
> > >
> > >
> > > > Faux. Appropriate use of exern “C” combined with __declspec(dllexport)
> > >
> > > > produces clean, unmangled exports ever time.
> > > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> > > > Shatskih
> > > > Sent: Friday, April 16, 2004 6:42 PM
> > > > To: Windows System Software Devs Interest List
> > > > Subject: Re: [ntdev] 64-bit build questions
> > > >
> > > >
> > > > > 2. What files can be in what directories is very inflexible. 3. At
> > > > > the
> > > >
> > > > > moment, it seems that all DLLs must have .def files to define
> > > > > exports.
> > > >
> > > > > Very few people use these any more so you have to make them up (and
> > > > > disable the _dllexport stuff).
> > > >
> > > > .DEF file is the only sane way of exporting from DLLs.__dllexport
> > > > results in mangled names, which in turn result in problems using
> > > > GetProcAddress for such a DLL.
> > > >
> > > > > Are there any documents other than the DDK that show the range of
> > > > > useful options in the sources file?
> > > >
> > > > MAKEFILE.DEF and platform-specific .MK files themselves.
> > > >
> > > > Maxim Shatskih, Windows DDK MVP
> > > > StorageCraft Corporation
> > > > xxxxx@storagecraft.com
> > > > http://www.storagecraft.com
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@dchbk.us
> > > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@dchbk.us
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@garlic.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

12

Yes, in this case compiler is out of the picture, so we will have two inst.
pipe line flush instead of one.

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Saturday, April 17, 2004 4:02 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 64-bit build questions

Any jumps will cause it, and in this particular case it is 2 jumps vs. 1
jump.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Prokash Sinha”
To: “Windows System Software Devs Interest List”
Sent: Sunday, April 18, 2004 2:56 AM
Subject: RE: [ntdev] 64-bit build questions

> I think Ur assertion make sense, w/o looking thru PE discussion. Also
> that one jump could cause branch prediction problem, not sure though. So I
> will stop digressing …
>
> -pro
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> Sent: Saturday, April 17, 2004 2:43 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] 64-bit build questions
>
>
> If I’m correct, this performance increase (of 1 jump) is due to
> __declspec(dllimport), and not__declspec(dllexport).
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “Prokash Sinha”
> To: “Windows System Software Devs Interest List”
> Sent: Sunday, April 18, 2004 1:36 AM
> Subject: RE: [ntdev] 64-bit build questions
>
>
> > I should not shout out loud, when it comes down to 64-bit. But one thing
> > to notice, as was well known that __declspec(…) is better when it
comes
> > down to linkage fixes. It does have a better performance under 32bit, if
> > that is
> > one needs to address. I think Riechter and Matt broke their fingure
while
> > writing it again and again about it :).Again, performance is the last
step
> > in the process …
> >
> > -pro
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> > Sent: Saturday, April 17, 2004 1:13 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] 64-bit build questions
> >
> >
> > If the name in the header file (and in the reference) mismatches the
> > name
> > for GetProcAddress - this is IMHO bad.
> >
> > Another evilness of__declspec(dllexport) is that the exports start
to
> > be
> > scattered all over the source, while the .DEF file is a centralized list
> of
> > all
> > exports. This is encapsulation.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > ----- Original Message -----
> > From: “benson margulies”
> > To: “Windows System Software Devs Interest List”
> > Sent: Saturday, April 17, 2004 11:56 PM
> > Subject: RE: [ntdev] 64-bit build questions
> >
> >
> > > I don’t get hit with those leading _'s. I do this constantly for
> > > user-mode stuff.
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> > > Shatskih
> > > Sent: Saturday, April 17, 2004 2:42 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] 64-bit build questions
> > >
> > >
> > > The combination of extern “C” and __declspec(dllexport) produces
the
> > > “stdcall” style exports of
> > >
> > > _MyFuncWithThreeParameters@12
> > >
> > > If you will also add__cdecl there - you will have
> > >
> > > _MyFuncWithThreeParameters
> > >
> > > Maxim Shatskih, Windows DDK MVP
> > > StorageCraft Corporation
> > > xxxxx@storagecraft.com
> > > http://www.storagecraft.com
> > >
> > >
> > > ----- Original Message -----
> > > From: “benson margulies”
> > > To: “Windows System Software Devs Interest List”
> > > Sent: Saturday, April 17, 2004 10:34 PM
> > > Subject: RE: [ntdev] 64-bit build questions
> > >
> > >
> > > > Faux. Appropriate use of exern “C” combined with
__declspec(dllexport)
> > >
> > > > produces clean, unmangled exports ever time.
> > > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> > > > Shatskih
> > > > Sent: Friday, April 16, 2004 6:42 PM
> > > > To: Windows System Software Devs Interest List
> > > > Subject: Re: [ntdev] 64-bit build questions
> > > >
> > > >
> > > > > 2. What files can be in what directories is very inflexible. 3. At
> > > > > the
> > > >
> > > > > moment, it seems that all DLLs must have .def files to define
> > > > > exports.
> > > >
> > > > > Very few people use these any more so you have to make them up
(and
> > > > > disable the _dllexport stuff).
> > > >
> > > > .DEF file is the only sane way of exporting from DLLs.__dllexport
> > > > results in mangled names, which in turn result in problems using
> > > > GetProcAddress for such a DLL.
> > > >
> > > > > Are there any documents other than the DDK that show the range of
> > > > > useful options in the sources file?
> > > >
> > > > MAKEFILE.DEF and platform-specific .MK files themselves.
> > > >
> > > > Maxim Shatskih, Windows DDK MVP
> > > > StorageCraft Corporation
> > > > xxxxx@storagecraft.com
> > > > http://www.storagecraft.com
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@dchbk.us
> > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@dchbk.us
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@garlic.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

13

Those of us exporting C++ classes never want to hear about maintain def
files with 100’s of mangled names. Adding declspecs to classes is far
superior.

I frequently set up disciplines for GetProcAddress, and there’s usually
a macro like:

DECLARE_FACTORY_FUNCTION(fcn)

That boils down to a __declspec(dllexport). It it, to me, much clearer
to have that in the source than to have the fact that the function is
export be off in a def file someplace.

However, Chacun a son gout.

Or, as, for those of you who like mohair,

Chacun a son goat.

14

> Those of us exporting C++ classes never want to hear about maintain def

files with 100’s of mangled names.

Any need in this??? There are C functions, and there are COM classes - why use
something “in between”?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

15

COM classes would be overkilled, much too of a overkill. I’ve seen what
Benson is
saying, it is much too difficult to keep those in .def file. I’ve seen
people did it
in 16bit time frame, acutally I did too, because I did not know a better
approach (if I recall).

Same is MFC, it is bit more than C++, may be c+++, why someone always need
to have an extra wrapper framework.

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Saturday, April 17, 2004 6:53 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 64-bit build questions

Those of us exporting C++ classes never want to hear about maintain def
files with 100’s of mangled names.

Any need in this??? There are C functions, and there are COM classes - why
use
something “in between”?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

16

With respect to a question about 64-bit building/porting issues.

Benson Margulies comments:

“Those of us exporting C++ classes never want to hear about maintain def
files with 100’s of mangled names.”

Maxim Shatskih asks:

“Any need in this??? There are C functions, and there are COM classes - why
use something “in between”?”

The problem is not what’s right or good but what is. I’m guessing that there
are tens of thousands of DLLs that export classes. The first project that I
tried to move to 64-bit (the one that started this whole thread) has two of
them.

I wrote the stuff some years ago using VS Wizards to create the framework.
In retrospect, particularly in light of the current situation, I can see
where I should have implemented the code as a library and not as a DLL.

There seems to be this cultural sort of thing that says “Libraries are bad
because your executable size is huge” and “DLLs are good because the size is
small.” You can make all sorts of arguments about how this is not really the
case, run-time issues and so on but the fact remains that people believe
this and VS reinforces the idea by running you down the DLL path. If you’re
new to it and don’t really understand what’s going on, this is how you learn
to do stuff and you stick with it as the years roll by.

Given the mission to port an existing project including drivers and related
stuff to 64-bit (and assuming the reliance on the multi-platform Build.exe
utility), the question now should be which is less painful, figuring out a
way to export classes from DLLs using .def files or re-writing the code to
use a “C” interface of re-structuring the code to be a library instead of a
DLL.

Regards,
Mickey.

17

With respect to Thomas F. Divine’s question:

“Do your user-mode components really need to be 64-bit? If they don’t really
exercise 64-bit functionality, then you can setup your 64-bit drivers to
detect when they are called by 32-bit apps.”

Please keep in mind that there are two completely different flavors of
64-bit Windows, Microsoft’s documentation is spotty and frequently doesn’t
specify which version they’re talking about and I’m up to here in questions,
unfounded opinions and mistaken assumptions. I’m also ‘relearning’ a bunch
of old Alpha stuff. What follows is probably full of errors and I will
gladly accept any corrections.

The released version of 64-bit Windows (which may be XP) runs on the
Itanium2 processor. The binaries will not execute on 32-bit processors or
64-bit AMD processors. Everything needs to be recompiled and linked. (The
old Alpha had an x86 emulator. Does the Itanium2?)

The beta version of 64-bit EXTENDED Windows (which may be Server 2003
although it says it is XP) runs on the AMD processor. All of the O/S is
recompiled (I think) and all of the drivers must recompiled but it will run
*some* existing 32-bit stuff via the old thunking methods.

There’s something called WOW64 which is used to facilitate running 32-bit
stuff but I’m not clear on which platform(s) it applies to. In either case,
the 32-bit stuff takes a performance hit. (On the old Alpha, it was a huge
hit.)

The AMD system will install/run some 32-bit user-level things and not
others. For instance, the latest DDK will not install using Setup.exe (it
won’t run) but will install if you manually execute some of the components.
I haven’t tried to build all the samples yet. WinZip 8 won’t run but WinZip
9 will. I haven’t tried VS 6 yet but I have installed a very few other
things that worked as-is from the 32-bit world.

Thomas’ comment:

"If you define structures carefully enough there will be very little
difference between the way the driver handles 32-bit and 64-bit user-mode
calls and little difference between your 32-bit driver and your 64-bit
driver.

There’s a paper on this but I haven’t dived into in detail it yet. It seems
to dwell on IOCTL buffer contents.

The problem is not that you can’t write new stuff to behave well in this
environment but that there’s a *bunch* of stuff in existence that needs to
be recompiled at best and actually ported at worst. Most of it written by
people who have never seen anything but 32-bit x86.

My objective is to find a way to deal with the existing stuff without having
to review every line of code to see if it needs changes. For instance, I’d
like to avoid having to re-evaluate every bit that moves between a driver
and its user code for 32 vs. 64-bit issues.

My take on it is that since you have to re-do everything for the ia64
situation, you might as well do it for the amd64 as well. If nothing else,
it gets rid of a lot of special case situations where “this will work with
that” but “on that platform, you need a special.” so-and-so.

While on the subject, I’m wondering if the AMD Windows release (and the
expected Intel version of same when they release the new chip) will kill the
Itanium platform. NT used to run on Alpha, MIPS (it was written on MIPS),
PPC and I think one other (ARM?) but the faster Intel (x86) equipment seems
to have killed them off.

Regards,
Mickey.

18

Charles Lane wrote thusly:

While on the subject, I’m wondering if the AMD Windows release (and
the expected Intel version of same when they release the new chip)
will kill the Itanium platform. NT used to run on Alpha, MIPS (it
was written on MIPS), PPC and I think one other (ARM?) but the
faster Intel (x86) equipment seems to have killed them off.

Personally, I think IA64 has little or no future. AMD has really hit the
sweet spot with Opteron – excellent price, excellent performance in both 32
and 64 bit environments, excellent compatibility, they’re meeting demand,
and major server manufacturers are adopting it. The sales numbers are
Also, Opteron’s integrated memory controller and ccNUMA logic makes building
SMP systems ridiculously easy, and (even better) makes the SMP
implementations quite uniform. (I’m sure there are people here who can tell
some horror stories of early SMP chipset differences.)

When I first learned about IA64, I was a big fan. VLIW/EPIC seemed like a
great design, and the 32->64 bit transition seemed like a great opportunity
to switch to it. But the reality was disappointing. I had an Intel “SDV”
in my office – Software Development Vehicle – for about a year, so I could
find and fix all 64-bit bugs in my code. The thing was a dog – my puny
little P3 600MHz desktop ran circles around it. Obviously, performance
improved, but IA64 performance has definitely NOT delivered the order of
magnitude improvement that we were sold on.

Intel also completely missed the boat on backwards compatibility for IA64.
Which is shocking, since they have a history of doing a pretty good job on
instruction set compatibility and maintaining performance levels.

When I first learned of AMD64, I thought it was just a hack. Yet another
extension to an instruction set that has already been stretched from 8, to
16, to 32 bits? Yeah, right. It took me a while to understand that their
design was sound, and that they actually had some really good ideas that
would put them ahead of Intel. Specifically, HyperTransport and their
integrated ccNUMA glue.

The big lesson is that the instruction set really doesn’t matter much.
Modern CISC processors, P3, P4, K7, K8, have so many pipeline elements that
the importance of the instruction set really fades away after the first few
stages. In fact, the higher instruction density of CISC actually helps –
more instructions means less wasted cache, and better use of input
bandwidth. (And 64-bit mode doesn’t always help performance – I’ve seen
numerical applications that ran better in 32-bit mode, because passing
around 64-bit pointers just wasted time.)

Exploiting the existing market of software is absolutely crucial.
Performance is absolutely crucial. Cost is merely important. Itanium blew
it.

– arlie

19

“Arlie Davis” wrote in message news:xxxxx@ntdev…
> Charles Lane wrote thusly:
> > While on the subject, I’m wondering if the AMD Windows release (and
> > the expected Intel version of same when they release the new chip)
> > will kill the Itanium platform. NT used to run on Alpha, MIPS (it
> > was written on MIPS), PPC and I think one other (ARM?) but the
> > faster Intel (x86) equipment seems to have killed them off.
>
> Personally, I think IA64 has little or no future. AMD has really hit the
> sweet spot with Opteron – excellent price, excellent performance in both
32
> and 64 bit environments, excellent compatibility, they’re meeting demand,
> and major server manufacturers are adopting it. The sales numbers are
> Also, Opteron’s integrated memory controller and ccNUMA logic makes
building
> SMP systems ridiculously easy, and (even better) makes the SMP
> implementations quite uniform. (I’m sure there are people here who can
tell
> some horror stories of early SMP chipset differences.)
>
> When I first learned about IA64, I was a big fan. VLIW/EPIC seemed like a
> great design, and the 32->64 bit transition seemed like a great
opportunity
> to switch to it. But the reality was disappointing. I had an Intel “SDV”
> in my office – Software Development Vehicle – for about a year, so I
could
> find and fix all 64-bit bugs in my code. The thing was a dog – my puny
> little P3 600MHz desktop ran circles around it. Obviously, performance
> improved, but IA64 performance has definitely NOT delivered the order of
> magnitude improvement that we were sold on.
>
> Intel also completely missed the boat on backwards compatibility for IA64.
> Which is shocking, since they have a history of doing a pretty good job on
> instruction set compatibility and maintaining performance levels.
>
> When I first learned of AMD64, I thought it was just a hack. Yet another
> extension to an instruction set that has already been stretched from 8, to
> 16, to 32 bits? Yeah, right. It took me a while to understand that their
> design was sound, and that they actually had some really good ideas that
> would put them ahead of Intel. Specifically, HyperTransport and their
> integrated ccNUMA glue.
>
> The big lesson is that the instruction set really doesn’t matter much.
> Modern CISC processors, P3, P4, K7, K8, have so many pipeline elements
that
> the importance of the instruction set really fades away after the first
few
> stages. In fact, the higher instruction density of CISC actually helps –
> more instructions means less wasted cache, and better use of input
> bandwidth. (And 64-bit mode doesn’t always help performance – I’ve seen
> numerical applications that ran better in 32-bit mode, because passing
> around 64-bit pointers just wasted time.)
>
> Exploiting the existing market of software is absolutely crucial.
> Performance is absolutely crucial. Cost is merely important. Itanium
blew
> it.
>
I agree with you, Arlie.

I am no expert on IA64 - primarily because I could never afford one for
development. I was somewat disturbed a few years ago when SysInternals
ported a lot of their utilities ot IA64 - and they did it on an IA64 loaner
from Microsoft. I have to buy my tools…

I’m glad I waited it out. Recently AMD64 desktops came on the scene at a
very reasonable price.

Adapting 32-bit drivers for AMD64 was not that difficult. With about a weeks
worth of time I had my driver sources modified where I could build 32-bit
x86 and 64-bit amd64 from the same sources. With a little tweaking of
structures passed between applications and the drivers I could use either
32-bit applications or 64-bit applications on my 64-bit driver. And, the
32-bit application worked on all platforms.

Of course, my drivers are probably much simpler then Charles’s. I can see
that he has a much bigger problem then I had.

I mentioned using 32-bit applications on 64-bit drivers because in some case
it makes sense. In particular, if the driver does most of the work and the
application is only used occasionally to configure the driver, then why
bother with a 64-bit application. Especially when the 64-bit application
development tools are so far behind (e.g., no 64-bit .NET support, no MFC,
etc.). OTOH, if the user-mode application interacts with the driver more
heavily, then naturally a 64-bit application is in order.

Regards,

Thomas F. Divine

20

Just to say Thanks would be bit insulting !. Hat’s off for this account !

I’ve been trying to grab an AMD but sometime penny pinching needs to have a
priority. Yes, now there are
AMD 64bit MP desktop(s) for around 2K USD.

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Arlie Davis
Sent: Sunday, April 18, 2004 8:51 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] 64-bit build questions

Charles Lane wrote thusly:

While on the subject, I’m wondering if the AMD Windows release (and
the expected Intel version of same when they release the new chip)
will kill the Itanium platform. NT used to run on Alpha, MIPS (it
was written on MIPS), PPC and I think one other (ARM?) but the
faster Intel (x86) equipment seems to have killed them off.

Personally, I think IA64 has little or no future. AMD has really hit the
sweet spot with Opteron – excellent price, excellent performance in both 32
and 64 bit environments, excellent compatibility, they’re meeting demand,
and major server manufacturers are adopting it. The sales numbers are
Also, Opteron’s integrated memory controller and ccNUMA logic makes building
SMP systems ridiculously easy, and (even better) makes the SMP
implementations quite uniform. (I’m sure there are people here who can tell
some horror stories of early SMP chipset differences.)

When I first learned about IA64, I was a big fan. VLIW/EPIC seemed like a
great design, and the 32->64 bit transition seemed like a great opportunity
to switch to it. But the reality was disappointing. I had an Intel “SDV”
in my office – Software Development Vehicle – for about a year, so I could
find and fix all 64-bit bugs in my code. The thing was a dog – my puny
little P3 600MHz desktop ran circles around it. Obviously, performance
improved, but IA64 performance has definitely NOT delivered the order of
magnitude improvement that we were sold on.

Intel also completely missed the boat on backwards compatibility for IA64.
Which is shocking, since they have a history of doing a pretty good job on
instruction set compatibility and maintaining performance levels.

When I first learned of AMD64, I thought it was just a hack. Yet another
extension to an instruction set that has already been stretched from 8, to
16, to 32 bits? Yeah, right. It took me a while to understand that their
design was sound, and that they actually had some really good ideas that
would put them ahead of Intel. Specifically, HyperTransport and their
integrated ccNUMA glue.

The big lesson is that the instruction set really doesn’t matter much.
Modern CISC processors, P3, P4, K7, K8, have so many pipeline elements that
the importance of the instruction set really fades away after the first few
stages. In fact, the higher instruction density of CISC actually helps –
more instructions means less wasted cache, and better use of input
bandwidth. (And 64-bit mode doesn’t always help performance – I’ve seen
numerical applications that ran better in 32-bit mode, because passing
around 64-bit pointers just wasted time.)

Exploiting the existing market of software is absolutely crucial.
Performance is absolutely crucial. Cost is merely important. Itanium blew
it.

– arlie

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com