Re: MODULES vs FILES in bib file



Yes, that's what you need to do (put the drivers in FILES).

I think that your concern about address space is misplaced, but I know
*nothing* about your OS, so, again, you have to test. I know that I often
move things from MODULES to FILES and back with absolutely no concern at all
about address space (as I said, you have much more-pressing problems to
worry about, generally)...

Paul T.

<tpandey02@xxxxxxxxx> wrote in message
news:e09a3062-b044-4964-9e6f-11df1d497b49@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Oct 1, 8:47 am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT no
instrument no spam DOT com> wrote:
Yep, you're right. Sorry about my error!

Paul T.

"Bruce Eitman [eMVP]" <bruce.eitman.nos...@xxxxxxxxxxxxxxxxxxx> wrote in
messagenews:ue47fd8IJHA.5900@xxxxxxxxxxxxxxxxxxxxxxx



Actually the OP is correct. Moving the dll from MODULES to FILES in
Windows CE 5.0 and 4.x will cause it to be loaded in Slot 0 instead of
Slot 1, which will reduce the available virtual address space of all
processes.

I agree with Paul though, test.

On the other hand, I beleive that this question goes back to your
earlier
question about calculating a hash code for the dll. Since the dll is in
the OS image, why not calculate the hash on the image as a whole?

--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT EuroTech DOT com
My BLOGhttp://geekswithblogs.net/bruceeitman

EuroTech Inc.
www.EuroTech.com

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT
com> wrote in messagenews:u%23oHYO1IJHA.788@xxxxxxxxxxxxxxxxxxxxxxx
It will load into the process slot of the device manager, but, if the
device manager is completely out of address space, you're screwed
anyway.
Don't manufacture concerns; there are enough things to be worried about
without this one. *Test* and you'll know whether there's a problem or
not.

Paul T.

<tpande...@xxxxxxxxx> wrote in message
news:84ef8f80-4a0b-4819-8148-bb6060ed8736@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Sep 30, 3:37 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Well, you can be sure that the driver will be in RAM while it's
executing,
so it might run a little faster, depending on what the options you put
in
the BIB file when it was in the MODULES section were. Load time during
startup might be slightly affected while the file is actually loaded
into
RAM, again, depending on the old settings. Unless you have some
observed
problem, I don't see any reason to worry about it before you even try
it.

Paul T.

<tpande...@xxxxxxxxx> wrote in message

news:0cfdd9ec-c5e4-49d3-af57-c4a5b529abf8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Hi All,

Can anybody tell me that if I move my driver dll from MODULES
section
to FILES section is there going to be any effect as far as my driver
working is concern ?

I mean is what is the difference If I move my driver from MODULES to
FILES ?I wanted to read a file from release directory and after
moving
that to FILES section I can read that now but don't know if the
performance of the driver will have any impact.

Tpandey- Hide quoted text -

- Show quoted text -

Thanks Paul for the fast reply.

I went through the MSDN and it says that instead of loading the driver
in only process slot1 it will load in all the slots so some concern
with virtual memory for any one process.

I moved my driver dll into FILES section jus to do a readfile for the
driver and I could read and generate the checksum/hash.

Tpandey- Hide quoted text -

- Show quoted text -

Thanks guys for the replies.

The reason for not calculating the hash on the whole OS is that the
Client does not want us to change specific drivers. If we change any
other driver the OS is gonna change and will generate a different
hash.

So I am worrying about calculating the hash for only those drivers
that the client wants.
And I don't have any other way(as far as I know) to read the driver
dlls except moving that to the files section which in turn will be a
concern for virtual memory.

Tpandey


.