Linking with a static library

I've got a simplle static library and I want to link the lib file in with
the driver. What do I put in the sources file? TARGETLIBS seems to be only
for linking with dll stubs, or should that work?

error LNK2019: unresolved external symbol _GetModuleExportAddress@8
referenced in function _ImageLoadNotify@12

Steve
Tue Nov 09 00:36:08 CST 2004

You will probably find it much easier if you use the
Visual C++ IDE to build your projects! The compiler and
linker are the same as the ddk (apparently), you just
need to configure project setting so that the right
includes are included and the right libs linked.

I use Visual C++ to build all my drivers - much easier
than using the ddk build - particularly when you want to
start linking in static libraries, etc. If you need a
blank project that is configured for kernel mode I can
help.

Steve.

>-----Original Message-----
>I've got a simplle static library and I want to link the
lib file in with
>the driver. What do I put in the sources file?
TARGETLIBS seems to be only
>for linking with dll stubs, or should that work?
>
>error LNK2019: unresolved external symbol
_GetModuleExportAddress@8
>referenced in function _ImageLoadNotify@12
>
>
>
>.
>

Spacen
Tue Nov 09 04:19:13 CST 2004

Ah yes, using visual C sounds useful. I did, in the end, realise why it
wouldn't link. I was trying to link a static library that I had already
built in visual studio, to the driver. I included the header file in the
driver with the external definitions but it seems that the default calling
convention in drivers it stdcall, where as the library was using the c ( or
cdecl ) convention.

I will have to develop a proper build environment when I figgure out exactly
what it is I want to do in terms of driver development. I am not actually
doing it for a hardware device.

"Steve" <swoodberry@foursticks.com> wrote in message
news:40e301c4c626$6535ad50$a401280a@phx.gbl...
> You will probably find it much easier if you use the
> Visual C++ IDE to build your projects! The compiler and
> linker are the same as the ddk (apparently), you just
> need to configure project setting so that the right
> includes are included and the right libs linked.
>
> I use Visual C++ to build all my drivers - much easier
> than using the ddk build - particularly when you want to
> start linking in static libraries, etc. If you need a
> blank project that is configured for kernel mode I can
> help.
>
> Steve.
>
>>-----Original Message-----
>>I've got a simplle static library and I want to link the
> lib file in with
>>the driver. What do I put in the sources file?
> TARGETLIBS seems to be only
>>for linking with dll stubs, or should that work?
>>
>>error LNK2019: unresolved external symbol
> _GetModuleExportAddress@8
>>referenced in function _ImageLoadNotify@12
>>
>>
>>
>>.
>>

Don
Tue Nov 09 07:17:36 CST 2004

The problems of not using build have been well discussed on this forum and
NTDEV, if you aren't aware of them don't jump into building drivers with
Visual C directly. I have seen enough subtle problems with these techniques
that when I am helping people hire contractors, those who advocate these
approaches are eliminated from the job search.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

"Spacen Jasset" <a@b.com> wrote in message
news:%23%23%23rNWkxEHA.3336@TK2MSFTNGP11.phx.gbl...
> Ah yes, using visual C sounds useful. I did, in the end, realise why it
> wouldn't link. I was trying to link a static library that I had already
> built in visual studio, to the driver. I included the header file in the
> driver with the external definitions but it seems that the default calling
> convention in drivers it stdcall, where as the library was using the c (
or
> cdecl ) convention.
>
> I will have to develop a proper build environment when I figgure out
exactly
> what it is I want to do in terms of driver development. I am not actually
> doing it for a hardware device.
>
> "Steve" <swoodberry@foursticks.com> wrote in message
> news:40e301c4c626$6535ad50$a401280a@phx.gbl...
> > You will probably find it much easier if you use the
> > Visual C++ IDE to build your projects! The compiler and
> > linker are the same as the ddk (apparently), you just
> > need to configure project setting so that the right
> > includes are included and the right libs linked.
> >
> > I use Visual C++ to build all my drivers - much easier
> > than using the ddk build - particularly when you want to
> > start linking in static libraries, etc. If you need a
> > blank project that is configured for kernel mode I can
> > help.
> >
> > Steve.
> >
> >>-----Original Message-----
> >>I've got a simplle static library and I want to link the
> > lib file in with
> >>the driver. What do I put in the sources file?
> > TARGETLIBS seems to be only
> >>for linking with dll stubs, or should that work?
> >>
> >>error LNK2019: unresolved external symbol
> > _GetModuleExportAddress@8
> >>referenced in function _ImageLoadNotify@12
> >>
> >>
> >>
> >>.
> >>
>
>

Spacen
Tue Nov 09 07:36:16 CST 2004

"Don Burn" <burn@stopspam.acm.org> wrote in message
news:10p1gs3mfcgrkee@corp.supernews.com...
> The problems of not using build have been well discussed on this forum and
> NTDEV, if you aren't aware of them don't jump into building drivers with
> Visual C directly. I have seen enough subtle problems with these
> techniques
> that when I am helping people hire contractors, those who advocate these
> approaches are eliminated from the job search.
>
That's a bit rough. I have also heard of problems though. I think I may have
read about it in Oney's book.

Don
Tue Nov 09 07:47:02 CST 2004

Spending weeks tracking down a stupid bug, because the developer didn't use
the right procedures is rough. Note, also you cannot at present use PreFast
without using the build environment, and I believe no code should be loaded
in the kernel that can't PreFast cleanly.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

"Spacen Jasset" <a@b.com> wrote in message
news:uHbFVEmxEHA.1188@tk2msftngp13.phx.gbl...
> "Don Burn" <burn@stopspam.acm.org> wrote in message
> news:10p1gs3mfcgrkee@corp.supernews.com...
> > The problems of not using build have been well discussed on this forum
and
> > NTDEV, if you aren't aware of them don't jump into building drivers with
> > Visual C directly. I have seen enough subtle problems with these
> > techniques
> > that when I am helping people hire contractors, those who advocate these
> > approaches are eliminated from the job search.
> >
> That's a bit rough. I have also heard of problems though. I think I may
have
> read about it in Oney's book.
>
>

Maxim
Tue Nov 09 07:50:05 CST 2004

> You will probably find it much easier if you use the
> Visual C++ IDE to build your projects!

Given the amount of issues people have with this - it is hardly a good advice.

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

Ray
Tue Nov 09 16:21:15 CST 2004

I heartily agree that it's a good idea to use build if you're starting
out a new project, because there are a few things you'll have to keep in
mind in the design of your source code hierarchies. Otherwise, you can
get into situations that build can't handle easily without introducing a
lot of risky changes, especially if you're trying to group your code so
it's portable to multiple platforms.

Sadly, I find myself in that latter situation. Luckily I haven't had any
problems related to using a VC++ makefile in around 7 years now. One of
these days I'll probably put in the time to rearchitect our source tree
so that it's more convenient to use BUILD and switch over. Well, as soon
as customers stop bugging me :-). That will save a lot of pain running
PREFast too (right now we have to copy a deeply (and invertedly) nested
hierarchy of source files into another directory, cross our fingers, and
run it there, which is really annoying, and makes it so we don't run
PREFast as often as I would like)...

Maxim S. Shatskih wrote:
>>You will probably find it much easier if you use the
>>Visual C++ IDE to build your projects!
>
>
> Given the amount of issues people have with this - it is hardly a good advice.
>

--
../ray\..

nospam
Tue Nov 09 19:15:54 CST 2004

"Don Burn" <burn@stopspam.acm.org> wrote in message
news:10p1ij92rgdd746@corp.supernews.com...
> Spending weeks tracking down a stupid bug, because the developer didn't
> use
> the right procedures is rough. Note, also you cannot at present use
> PreFast
> without using the build environment, and I believe no code should be
> loaded
> in the kernel that can't PreFast cleanly.

I didn't spend weeks (weeks?!) tracking down a stupid bug, several days at
most, but in 99.99% the "right" Microsoft procedures were followed. It
didn't help much, however. Windows is supposed to be built using the right
procedures. Is it becoming more stable? I don't think so, it seems to be
even less stable than NT 3.1 or even DOS.

I am a customer using Windows dodgyware. Do I care whether some driver was
built using an older Microsoft complier from BUILD or a newer Microsoft
compiler from Visual Studio? No, I don't. I worry about the stability of my
system. And in reality WHQL signed drivers built according to all the right
procedures are crashing in the same way and as frequently as the others. In
fact, it's better to use the latest unsigned drivers than older signed ones!

I've just signed up for Microsoft's event called "Marketing Technology
Products to Mainstream Customers". The summary says: "...Simply engineering
a brilliant product doesn't guarantee export success. Long before you go to
market, you must shift your perspective from refining technology to creating
value for your customers. Technical excellence doesn't survive mediocre
marketing.". I agree with this - that's the reality, but what does that
mean? Exactly what Microsoft does - a huge amount of bugs that sells pretty
well. Microsoft doesn't worry about the quality as long as the product
sells - why should we? Business is business, and business must grow, you
know. Get a WHQL sticker, get yourself called a gold or platinum partner -
and you don't have to worry about the quality any more.

Actually, I agree that using anything but BUILD is a bit dangerous for an
inexperienced driver developer. Approximately as dangerous as writing code.
As long as you write your own code, there is a danger of encountering new
bugs in Microsoft compiler or linker. And I personally do encounter them
even more frequently than before (with no relation to BUILD, however).

I would judge developers by their products. If the products are good, then
the procedures the developers employ are probably good as well. If a
developer is not good, BUILD won't help.

Being a human, however, I would eliminate from the job search those people
who use tab instead of spaces for code alignment.

Cheers
Nick

P.S. By the way, Don, what other criteria do you use in the selection
process?

>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
> "Spacen Jasset" <a@b.com> wrote in message
> news:uHbFVEmxEHA.1188@tk2msftngp13.phx.gbl...
>> "Don Burn" <burn@stopspam.acm.org> wrote in message
>> news:10p1gs3mfcgrkee@corp.supernews.com...
>> > The problems of not using build have been well discussed on this forum
> and
>> > NTDEV, if you aren't aware of them don't jump into building drivers
>> > with
>> > Visual C directly. I have seen enough subtle problems with these
>> > techniques
>> > that when I am helping people hire contractors, those who advocate
>> > these
>> > approaches are eliminated from the job search.
>> >
>> That's a bit rough. I have also heard of problems though. I think I may
> have
>> read about it in Oney's book.
>>
>>
>
>

Spacen
Wed Nov 10 09:09:24 CST 2004

"nospam@cristalink.com" <cristalink@nospam.nospam> wrote in message
news:up3bULsxEHA.3792@TK2MSFTNGP10.phx.gbl...
...
> Being a human, however, I would eliminate from the job search those people
> who use tab instead of spaces for code alignment.
...
Someone will say don't hire people that use goto next. :-)

Don
Wed Nov 10 09:35:25 CST 2004

No using anything but BUILD can be dangerous period. The case of weeks was
a subtle compiler bug that did not occur if you used the BUILD environment.

It would be nice to judge dev's by their products, but how do you do that.
For instance if I am hiring an NDIS developer do I hire one of the dev's who
developed drivers for the two best selling NIC's? I wouldn't because the
drivers fail to run correctly under the checked build! Should I not hire a
guy who works for a medical product group, just because I don't know his
product? One of the best dev's I know works for such a group and is
extremely careful.

I judge dev's by there care in developement and lack of risk taking. Not
using build is adding an unessecary risk. Not using /WALL on the compiler,
or not using PreFast are again taking risks. The same holds true for
testing with the checked build, with verifier and with code coverage. If you
want to see my development philosophy go to
http://www.microsoft.com/whdc/resources/mvp/xtremeMVP_drv.mspx#ECAA

I concur that WHQL is far from adequate, and I push Microsoft every chance I
get to fix it. Unfortunately they have to walk the line between satisfying
the end users and their partners. It is ironic that it is their partners
who don't want the tests strengthened for WHQL. "What fix the NIC driver
because it has bugs that have been known for 10 years, they only impact
developers and a rare number of users?" This is a real quote from a very
large firm!


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

"nospam@cristalink.com" <cristalink@nospam.nospam> wrote in message
news:up3bULsxEHA.3792@TK2MSFTNGP10.phx.gbl...
>
> Actually, I agree that using anything but BUILD is a bit dangerous for an
> inexperienced driver developer. Approximately as dangerous as writing
code.
> As long as you write your own code, there is a danger of encountering new
> bugs in Microsoft compiler or linker. And I personally do encounter them
> even more frequently than before (with no relation to BUILD, however).
>
> I would judge developers by their products. If the products are good, then
> the procedures the developers employ are probably good as well. If a
> developer is not good, BUILD won't help.
>
> Being a human, however, I would eliminate from the job search those people
> who use tab instead of spaces for code alignment.
>
> Cheers
> Nick
>
> P.S. By the way, Don, what other criteria do you use in the selection
> process?
>

Maxim
Wed Nov 10 12:33:47 CST 2004

> didn't help much, however. Windows is supposed to be built using the right
> procedures. Is it becoming more stable?

Surely.

>I don't think so, it seems to be
> even less stable than NT 3.1 or even DOS.

Not so. DOS hangs on each misbehaving app. Crashing Windows is by far more
complex.
NT 3.1 was a can of bugs.

> fact, it's better to use the latest unsigned drivers than older signed ones!

Exactly. I'm also a WHQL disbeliever :) due to this very reason.

> mean? Exactly what Microsoft does - a huge amount of bugs that sells pretty

Rather small amount of bugs, if you will compare to Linux. Just read NTBugTraq,
and then the Linux security bulletins from RedHat or such.

> well. Microsoft doesn't worry about the quality as long as the product
> sells

Please show us the example of better debugged commercial software. Most other
commercial software is more buggy, including the security stuff like Kerio
firewall which has a funny bug in IP header parsing, thus making the machine
more vulnerable instead of lesser vulnerable.

> Being a human, however, I would eliminate from the job search those people
> who use tab instead of spaces for code alignment.

Not so an issue, they are easily replaceable :)

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

Robby
Wed Nov 10 13:28:36 CST 2004


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:ehE7BP1xEHA.1956@TK2MSFTNGP14.phx.gbl...

> > mean? Exactly what Microsoft does - a huge amount of bugs that sells
pretty
>
> Rather small amount of bugs, if you will compare to Linux. Just read
NTBugTraq,
> and then the Linux security bulletins from RedHat or such.

Things have really changed then from a few years ago. I used to be
subscribed to the bugtraq lists. While I don't have any actual stats, it
seemed to me (at the time anyway) that security-related bugs were being
discovered in Windows much more regularly than the unix/linux holes. The
turn around time for a patch was just the opposite. I'm sure there are
lot's of justifiable explanations for the observations.

Rob

nospam
Wed Nov 10 13:58:34 CST 2004

>> mean? Exactly what Microsoft does - a huge amount of bugs that sells
>> pretty
>
> Rather small amount of bugs, if you will compare to Linux. Just read
> NTBugTraq,
> and then the Linux security bulletins from RedHat or such.

...*relatively* small amount. I agree that all the rest is even worse. I
choose the lesser evil.


> Please show us the example of better debugged commercial software. Most
> other
> commercial software is more buggy, including the security stuff like Kerio
> firewall which has a funny bug in IP header parsing, thus making the
> machine
> more vulnerable instead of lesser vulnerable.

I didn't say MS is the worst. But it's getting worse.

Here is one of the bugs I discovered recently:

http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackId=FDBK16272

It makes managed C++ nearly unusable with unmanaged code.

And this is Microsoft's response:

<<There is absolutely no way to fix it for earlier versions [MS VS 2003]
since it requires changes in the C++ compiler, the metadata and the CLR
interop layer.>>

Have you noticed Microsoft doesn't fix bugs in the compiler any more,
beginning with VS 2002? They just release a new version in a year or two
with more bugs.

I'm afraid that with Longhorn it would be necessary to replace the whole OS
with a newer version (EvenLongerHorn or whatever) to have a bug fixed.

Yet another funny bug:

http://groups.google.com/groups?hl=en&lr=&threadm=e1mlZlErEHA.644%40tk2msftngp13.phx.gbl&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26q%3D%2522managed%2Bcall%2Bto%2Bwcschr%2522



--
http://www.firestreamer.com - NTBACKUP to DVD and DV