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


.



Relevant Pages

  • Re: MODULES vs FILES in bib file
    ... Keep your DLL in MODULES. ... > Paul T. ... why not calculate the hash on the image as a whole? ... >>>>> I mean is what is the difference If I move my driver from MODULES ...
    (microsoft.public.windowsce.platbuilder)
  • Re: MODULES vs FILES in bib file
    ... That would prove NOTHING about whether you changed the driver DLL or not. ... no instrument no spam DOT com> wrote: ... why not calculate the hash on the image as a whole? ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Gotta start somewhere ... how many of us are really out there?
    ... we'll still have hosts sending in old data.... ... Part of the idea I mentioned earlier was using a hash of this information... ... then in future you can iterate over the hardware list, hash it, compare it against your stored hash, and only send if the hardware inventory has changed... ... if someone could bring up a list and find out that 500,000 people were using such-and-such a driver, it may influence the decision as to whether or not to update said driver when architectural changes are being made that require updates to the drivers... ...
    (freebsd-questions)
  • Re: MODULES vs FILES in bib file
    ... no instrument no spam DOT com> wrote: ... why not calculate the hash on the image as a whole? ... performance of the driver will have any impact. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: MODULES vs FILES in bib file
    ... Why don't you just have the bootloader checksum the image before loading, ... then store that in shared memory soewhere. ... why not calculate the hash on the image as a whole? ... performance of the driver will have any impact. ...
    (microsoft.public.windowsce.platbuilder)