Re: MODULES vs FILES in bib file



On Oct 1, 12:11 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
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.

<tpande...@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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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- Hide quoted text -

- Show quoted text -

Thanks for the concerns Paul.

I was thinking of one more option like to copy the driver dll from
release directory to a different name in the same release directory
say xxx_dup.dll and try reading that file instead of moving files from
MODULES to FILES section before makimg.exe.

I guess I can do this in premakeimg.bat file.

Not sure of the result ?

Tpandey

.



Relevant Pages

  • Re: ADM851X USB-LAN-Adapter driver
    ... no instrument no spam DOT com> wrote: ... Windows CE 4.2 driver worked with, then there's something wrong with your ... LQRP: LM_ReceiveCompleteCE fail! ...
    (microsoft.public.windowsce.platbuilder)
  • Re: ADM851X USB-LAN-Adapter driver
    ... timing differences in when power is applied, etc. on Windows CE vs. desktop ... source (and ask for a CE5-compatible driver, for goodness sake!), turn on ... no instrument no spam DOT com> wrote: ...
    (microsoft.public.windowsce.platbuilder)
  • Re: MODULES vs FILES in bib file
    ... why not calculate the hash on the image as a whole? ... no instrument no spam DOT com> wrote: ... performance of the driver will have any impact. ...
    (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: smart card reading
    ... spam AT no instrument no spam DOT com> wrote: ... You'd then consult the documentation for the card to figure out ... >how to communicate with the driver. ...
    (microsoft.public.dotnet.framework.compactframework)