when i build the driver i get this erro
C;\usbexe\final\internal.f (54) : error fatal error c1083 cannot open file ‘public.h’; no such ile of directry.
I made sure that public.h was in the usbexe \final direcry.
can someone tell me how to fix this error
tnks ron hathcock
xxxxx@gmail.com wrote:
when i build the driver i get this erro
C;\usbexe\final\internal.f (54) : error fatal error c1083 cannot open file ‘public.h’; no such ile of directry.
I made sure that public.h was in the usbexe \final direcry.
can someone tell me how to fix this error
Did you mean “internal.c”?
In the sample, public.h is located in …\inc, which is added to the
INCLUDES path in the sources file.
I guess you’ll need to show us a “dir /s” of the c:\usbexe directory,
and your “sources” file.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
UMDF_VERSION controls the headers that the driver uses.
UMDF_VERSION + UMDF_MINOR_VERSION control which version
of UMDF the driver is bound to in the INF and which
update coinstaller it requires (through stampinf).
UMDF_VERSION=1
UMDF_MINOR_VERSION=7
KMDF_VERSION=1
KMDF_MINOR_VERSION=7
TARGETNAME=WUDFOsrUsbFilter
TARGETTYPE=DYNLINK
USE_MSVCRT=1
C_DEFINES = $(C_DEFINES) /D_UNICODE /DUNICODE
WIN32_WINNT_VERSION=$(LATEST_WIN32_WINNT_VERSION)
_NT_TARGET_VERSION=$(_NT_TARGET_VERSION_WINXP)
NTDDI_VERSION=$(LATEST_NTDDI_VERSION)
WIN32_WINNT_VERSION=$(LATEST_WIN32_WINNT_VERSION)
_NT_TARGET_VERSION=$(_NT_TARGET_VERSION_WINXP)
NTDDI_VERSION=$(LATEST_NTDDI_VERSION)
DLLENTRY=_DllMainCRTStartup
DLLDEF=exports.def
INCLUDES=$(INCLUDES);…....\inc
SOURCES=\
OsrUsbFilter.rc \
dllsup.cpp \
comsup.cpp \
driver.cpp \
device.cpp \
queue.cpp \
TARGETLIBS=\
$(SDK_LIB_PATH)\strsafe.lib \
$(SDK_LIB_PATH)\kernel32.lib \
$(SDK_LIB_PATH)\advapi32.lib \
NTTARGETFILES=$(OBJ_PATH)$(O)\WUDFOsrUsbFilterOnKmDriver.Inf \
$(OBJ_PATH)$(O)\WUDFOsrUsbFilterOnUmDriver.Inf
MISCFILES=$(NTTARGETFILES)
This sets up the WPP preprocessor and tells it to scan internal.h to find
the trace function definition that’s in there.
RUN_WPP= $(SOURCES) -dll -scan:internal.h
On 6/10/09, Tim Roberts wrote:
>
> xxxxx@gmail.com wrote:
> > when i build the driver i get this erro
> > C;\usbexe\final\internal.f (54) : error fatal error c1083 cannot open
> file ‘public.h’; no such ile of directry.
> > I made sure that public.h was in the usbexe \final direcry.
> > can someone tell me how to fix this error
> >
>
> Did you mean “internal.c”?
>
> In the sample, public.h is located in …\inc, which is added to the
> INCLUDES path in the sources file.
>
> I guess you’ll need to show us a “dir /s” of the c:\usbexe directory,
> and your “sources” file.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
On 6/10/09, ron hathcock wrote:
>
> #
>
> # UMDF_VERSION controls the headers that the driver uses.
>
> # UMDF_VERSION + UMDF_MINOR_VERSION control which version
>
> # of UMDF the driver is bound to in the INF and which
>
> # update coinstaller it requires (through stampinf).
>
> #
>
> UMDF_VERSION=1
>
> UMDF_MINOR_VERSION=7
>
> KMDF_VERSION=1
>
> KMDF_MINOR_VERSION=7
>
>
>
> TARGETNAME=WUDFOsrUsbFilter
>
> TARGETTYPE=DYNLINK
>
> USE_MSVCRT=1
>
> C_DEFINES = $(C_DEFINES) /D_UNICODE /DUNICODE
>
> WIN32_WINNT_VERSION=$(LATEST_WIN32_WINNT_VERSION)
>
> _NT_TARGET_VERSION=$(_NT_TARGET_VERSION_WINXP)
>
> NTDDI_VERSION=$(LATEST_NTDDI_VERSION)
>
> WIN32_WINNT_VERSION=$(LATEST_WIN32_WINNT_VERSION)
>
> _NT_TARGET_VERSION=$(_NT_TARGET_VERSION_WINXP)
>
> NTDDI_VERSION=$(LATEST_NTDDI_VERSION)
>
> DLLENTRY=_DllMainCRTStartup
>
> DLLDEF=exports.def
>
> INCLUDES=$(INCLUDES);…....\inc
>
> SOURCES=<br>>
> OsrUsbFilter.rc <br>>
> dllsup.cpp <br>>
> comsup.cpp <br>>
> driver.cpp <br>>
> device.cpp <br>>
> queue.cpp <br>>
>
>
> TARGETLIBS=<br>>
> $(SDK_LIB_PATH)\strsafe.lib <br>>
> $(SDK_LIB_PATH)\kernel32.lib <br>>
> $(SDK_LIB_PATH)\advapi32.lib <br>>
> NTTARGETFILES=$(OBJ_PATH)$(O)\WUDFOsrUsbFilterOnKmDriver.Inf <br>>
> $(OBJ_PATH)$(O)\WUDFOsrUsbFilterOnUmDriver.Inf
>
>
>
> MISCFILES=$(NTTARGETFILES)
>
> #
>
> # This sets up the WPP preprocessor and tells it to scan internal.h to find
>
> # the trace function definition that’s in there.
>
> #
>
> RUN_WPP= $(SOURCES) -dll -scan:internal.h
>
>
>
>
> On 6/10/09, Tim Roberts wrote:
>>
>> xxxxx@gmail.com wrote:
>> > when i build the driver i get this erro
>> > C;\usbexe\final\internal.f (54) : error fatal error c1083 cannot open
>> file ‘public.h’; no such ile of directry.
>> > I made sure that public.h was in the usbexe \final direcry.
>> > can someone tell me how to fix this error
>> >
>>
>> Did you mean “internal.c”?
>>
>> In the sample, public.h is located in …\inc, which is added to the
>> INCLUDES path in the sources file.
>>
>> I guess you’ll need to show us a “dir /s” of the c:\usbexe directory,
>> and your “sources” file.
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
On 6/10/09, ron hathcock wrote:
>
>
>
> On 6/10/09, ron hathcock wrote:
>>
>> #
>>
>> # UMDF_VERSION controls the headers that the driver uses.
>>
>> # UMDF_VERSION + UMDF_MINOR_VERSION control which version
>>
>> # of UMDF the driver is bound to in the INF and which
>>
>> # update coinstaller it requires (through stampinf).
>>
>> #
>>
>> UMDF_VERSION=1
>>
>> UMDF_MINOR_VERSION=7
>>
>> KMDF_VERSION=1
>>
>> KMDF_MINOR_VERSION=7
>>
>>
>>
>> TARGETNAME=WUDFOsrUsbFilter
>>
>> TARGETTYPE=DYNLINK
>>
>> USE_MSVCRT=1
>>
>> C_DEFINES = $(C_DEFINES) /D_UNICODE /DUNICODE
>>
>> WIN32_WINNT_VERSION=$(LATEST_WIN32_WINNT_VERSION)
>>
>> _NT_TARGET_VERSION=$(_NT_TARGET_VERSION_WINXP)
>>
>> NTDDI_VERSION=$(LATEST_NTDDI_VERSION)
>>
>> WIN32_WINNT_VERSION=$(LATEST_WIN32_WINNT_VERSION)
>>
>> _NT_TARGET_VERSION=$(_NT_TARGET_VERSION_WINXP)
>>
>> NTDDI_VERSION=$(LATEST_NTDDI_VERSION)
>>
>> DLLENTRY=_DllMainCRTStartup
>>
>> DLLDEF=exports.def
>>
>> INCLUDES=$(INCLUDES);…....\inc
>>
>> SOURCES=<br>>>
>> OsrUsbFilter.rc <br>>>
>> dllsup.cpp <br>>>
>> comsup.cpp <br>>>
>> driver.cpp <br>>>
>> device.cpp <br>>>
>> queue.cpp <br>>>
>>
>>
>> TARGETLIBS=<br>>>
>> $(SDK_LIB_PATH)\strsafe.lib <br>>>
>> $(SDK_LIB_PATH)\kernel32.lib <br>>>
>> $(SDK_LIB_PATH)\advapi32.lib <br>>>
>> NTTARGETFILES=$(OBJ_PATH)$(O)\WUDFOsrUsbFilterOnKmDriver.Inf <br>>>
>> $(OBJ_PATH)$(O)\WUDFOsrUsbFilterOnUmDriver.Inf
>>
>>
>>
>> MISCFILES=$(NTTARGETFILES)
>>
>> #
>>
>> # This sets up the WPP preprocessor and tells it to scan internal.h to
>> find
>>
>> # the trace function definition that’s in there.
>>
>> #
>>
>> RUN_WPP= $(SOURCES) -dll -scan:internal.h
>>
>> how do i make a copy of all the files in usbexe
>>
>
tnks ron
On 6/10/09, Tim Roberts wrote:
>>>
>>> xxxxx@gmail.com wrote:
>>> > when i build the driver i get this erro
>>> > C;\usbexe\final\internal.f (54) : error fatal error c1083 cannot open
>>> file ‘public.h’; no such ile of directry.
>>> > I made sure that public.h was in the usbexe \final direcry.
>>> > can someone tell me how to fix this error
>>> >
>>>
>>> Did you mean “internal.c”?
>>>
>>> In the sample, public.h is located in …\inc, which is added to the
>>> INCLUDES path in the sources file.
>>>
>>> I guess you’ll need to show us a “dir /s” of the c:\usbexe directory,
>>> and your “sources” file.
>>>
>>> –
>>> Tim Roberts, xxxxx@probo.com
>>> Providenza & Boekelheide, Inc.
>>>
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>>
>
ron hathcock wrote:
…
TARGETNAME=WUDFOsrUsbFilter
TARGETTYPE=DYNLINK
USE_MSVCRT=1
C_DEFINES = $(C_DEFINES) /D_UNICODE /DUNICODE
WIN32_WINNT_VERSION=$(LATEST_WIN32_WINNT_VERSION)
_NT_TARGET_VERSION=$(_NT_TARGET_VERSION_WINXP)
NTDDI_VERSION=$(LATEST_NTDDI_VERSION)
WIN32_WINNT_VERSION=$(LATEST_WIN32_WINNT_VERSION)
_NT_TARGET_VERSION=$(_NT_TARGET_VERSION_WINXP)
NTDDI_VERSION=$(LATEST_NTDDI_VERSION)
DLLENTRY=_DllMainCRTStartup
DLLDEF=exports.def
INCLUDES=$(INCLUDES);…....\inc
If your source files are in c:\usbexe\final, then it should be clear
that …....\inc is pointing to the wrong place.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
you are telling me that public.h needs to be in theinc directry or do i need to redirect it to thr final dir can you tell me how to redirect it to the final directry using the INCLUGES = command tnks ron
xxxxx@gmail.com wrote:
you are telling me that public.h needs to be in theinc directry or do i need to redirect it to thr final dir can you tell me how to redirect it to the final directry using the INCLUGES = command
It simply need to be somewhere that the compiler can find it. If it’s
in the same directory as the file being compiled, then the compiler will
find it automatically. If it is in …\inc, then you need to add …\inc
to the INCLUDES line.
Oh, here’s another thought that might be related. The compiler will
only find the file in the same directory if you use quotes:
#include “public.h”
If you use angle brackets like this, it will not look in the current
directory:
#include <public.h>
So, if you WANT public.h to be in the same directory as the source
files, then you need to make sure the #include lines use double quotes.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</public.h>
I am pretty sure that build does distinguish where to look for a file for either “” or <>, all of my includes are “” and none of the headers are in the same dir as the sources
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Tim Roberts
Sent: Thursday, June 11, 2009 3:53 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] build compling
xxxxx@gmail.com wrote:
> you are telling me that public.h needs to be in theinc directry or do i need to redirect it to thr final dir can you tell me how to redirect it to the final directry using the INCLUGES = command
>
It simply need to be somewhere that the compiler can find it. If it’s
in the same directory as the file being compiled, then the compiler will
find it automatically. If it is in …\inc, then you need to add …\inc
to the INCLUDES line.
Oh, here’s another thought that might be related. The compiler will
only find the file in the same directory if you use quotes:
#include “public.h”
If you use angle brackets like this, it will not look in the current
directory:
#include <public.h>
So, if you WANT public.h to be in the same directory as the source
files, then you need to make sure the #include lines use double quotes.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</public.h>
I was under the impression that the rules for finding an include were
essentialy:
- If #included with “” look in the same directory as the including file,
then search the paths specified by -I. - If #includes with <> first search the paths specified by -I and then
search the directory of the including file.
Or something like that.
The distinction was not in determining the total set of folders searched but
the order of preference given to the -I search paths.
Perhaps I have missunderstood how the C preprocessor does this?
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, June 11, 2009 6:53 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] build compling
xxxxx@gmail.com wrote:
you are telling me that public.h needs to be in theinc directry or do
i need to redirect it to thr final dir can you tell me how to redirect
it to the final directry using the INCLUGES = command
It simply need to be somewhere that the compiler can find it. If it’s in
the same directory as the file being compiled, then the compiler will find
it automatically. If it is in …\inc, then you need to add …\inc to the
INCLUDES line.
Oh, here’s another thought that might be related. The compiler will only
find the file in the same directory if you use quotes:
#include “public.h”
If you use angle brackets like this, it will not look in the current
directory:
#include <public.h>
So, if you WANT public.h to be in the same directory as the source files,
then you need to make sure the #include lines use double quotes.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</public.h>
David R. Cattley wrote:
I was under the impression that the rules for finding an include were
essentialy:
- If #included with “” look in the same directory as the including file,
then search the paths specified by -I.- If #includes with <> first search the paths specified by -I and then
search the directory of the including file.Or something like that.
Almost. With #include <xxx.h>, the goes straight to the -I set and
never looks in the current directory at all. Otherwise, what you
describe is correct. This behavior is mandated by the C standards –
it’s not a Microsoft invention.
> The distinction was not in determining the total set of folders searched but
> the order of preference given to the -I search paths.
>
> Perhaps I have missunderstood how the C preprocessor does this?
>
Nope, you got it (almost) exactly right, and that’s exactly what I tried
to say. Apparently, since both you and Doron thought I said something
else, I must have said it quite badly.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</xxx.h>
What you are saying is correct. IIRC, one of edition of "C programming
languages " mentioned it …#include “hdrfile.h” => look at the current
directory. i.e. the directory of the includer ( usually a src.c file ).
Don’t look anywhere else.
#include <hdrfile.h> => look at the includes specified by -I ( in left to
right order ).
For some reason, I’ve seen MS compilers do include file from the current
directory of the src.c file, even if you mentioned the following -
#include <hdrfile.h> // and it resides in the current directory of the src.c
=> That means somewhere -I also consider current directory …
Two things ( at least ) very confusing when it comes to MS compilers -
1) #include
2) typedefs
Few more were out of synch, but from MSVC 8, lot of them are falling back to
std. C/C++
Only my observation …
-pro
On Fri, Jun 12, 2009 at 10:06 AM, Tim Roberts wrote:
> David R. Cattley wrote:
> > I was under the impression that the rules for finding an include were
> > essentialy:
> >
> > 1. If #included with “” look in the same directory as the including
> file,
> > then search the paths specified by -I.
> > 2. If #includes with <> first search the paths specified by -I and then
> > search the directory of the including file.
> >
> > Or something like that.
> >
>
> Almost. With #include <xxx.h>, the goes straight to the -I set and
> never looks in the current directory at all. Otherwise, what you
> describe is correct. This behavior is mandated by the C standards –
> it’s not a Microsoft invention.
>
> > The distinction was not in determining the total set of folders searched
> but
> > the order of preference given to the -I search paths.
> >
> > Perhaps I have missunderstood how the C preprocessor does this?
> >
>
> Nope, you got it (almost) exactly right, and that’s exactly what I tried
> to say. Apparently, since both you and Doron thought I said something
> else, I must have said it quite badly.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
></xxx.h></hdrfile.h></hdrfile.h>
> one of edition of "C programming languages " mentioned it
When absolutely all means are exhausted, time to look into the manual, MSDN in this case:
–Quoted form
The preprocessor searches for include files in the following order:
1) In the same directory as the file that contains the #include statement.
2) In the directories of any previously opened include files in the reverse order in which they were opened. The search starts from the directory of the include file that was opened last and continues through the directory of the include file that was opened first.
3) Along the path specified by each /I compiler option.
4) Along the paths specified by the INCLUDE environment variable.
–Angle-bracket form
The preprocessor searches for include files in the following order:
1) Along the path specified by each /I compiler option.
2) When compiling from the command line, along the paths that are specified by the INCLUDE environment variable.
----- Original Message -----
From: Prokash Sinha
To: Windows System Software Devs Interest List
Sent: Friday, June 12, 2009 3:46 PM
Subject: Re: [ntdev] build compling
What you are saying is correct. IIRC, one of edition of "C programming languages " mentioned it …
#include “hdrfile.h” => look at the current directory. i.e. the directory of the includer ( usually a src.c file ). Don’t look anywhere else.
#include <hdrfile.h> => look at the includes specified by -I ( in left to right order ).
For some reason, I’ve seen MS compilers do include file from the current directory of the src.c file, even if you mentioned the following -
#include <hdrfile.h> // and it resides in the current directory of the src.c => That means somewhere -I also consider current directory …
Two things ( at least ) very confusing when it comes to MS compilers -
1) #include
2) typedefs
Few more were out of synch, but from MSVC 8, lot of them are falling back to std. C/C++
Only my observation …
-pro
On Fri, Jun 12, 2009 at 10:06 AM, Tim Roberts wrote:
David R. Cattley wrote:
> I was under the impression that the rules for finding an include were
> essentialy:
>
> 1. If #included with “” look in the same directory as the including file,
> then search the paths specified by -I.
> 2. If #includes with <> first search the paths specified by -I and then
> search the directory of the including file.
>
> Or something like that.
>
Almost. With #include <xxx.h>, the goes straight to the -I set and
never looks in the current directory at all. Otherwise, what you
describe is correct. This behavior is mandated by the C standards –
it’s not a Microsoft invention.
> The distinction was not in determining the total set of folders searched but
> the order of preference given to the -I search paths.
>
> Perhaps I have missunderstood how the C preprocessor does this?
>
Nope, you got it (almost) exactly right, and that’s exactly what I tried
to say. Apparently, since both you and Doron thought I said something
else, I must have said it quite badly.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</xxx.h></hdrfile.h></hdrfile.h>
Prokash Sinha wrote:
What you are saying is correct. IIRC, one of edition of "C programming
languages " mentioned it …
#include “hdrfile.h” => look at the current directory. i.e. the
directory of the includer ( usually a src.c file ). Don’t look
anywhere else.
No. It says look FIRST in the current directory, THEN look at the -I
path. Angle brackets merely eliminates the first step.
For some reason, I’ve seen MS compilers do include file from the
current directory of the src.c file, even if you mentioned the following -
#include <hdrfile.h> // and it resides in the current directory of the
> src.c => That means somewhere -I also consider current directory …
If you specify -I . on the command line, then this will work.
Otherwise, it will not be found.
> Two things ( at least ) very confusing when it comes to MS compilers -
>
> 1) #include
> 2) typedefs
I think you are merely spreading your own misconceptions here.
Microsoft has always had the #include behavior correct. VC7 had a few
non-compliance issues with templates, but not with basic typedefs, and
virtually all of them are resolved in VC8.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</hdrfile.h>
On Fri, Jun 12, 2009 at 1:24 PM, Tim Roberts wrote:
> Prokash Sinha wrote:
> > What you are saying is correct. IIRC, one of edition of "C programming
> > languages " mentioned it …
> > #include “hdrfile.h” => look at the current directory. i.e. the
> > directory of the includer ( usually a src.c file ). Don’t look
> > anywhere else.
>
> No. It says look FIRST in the current directory, THEN look at the -I
> path. Angle brackets merely eliminates the first step.
>
Looks like my interpretation is wrong, I need to look at the book again to
see if implies to take the -I also for " " include.
>
>
> > For some reason, I’ve seen MS compilers do include file from the
> > current directory of the src.c file, even if you mentioned the following
> -
> > #include <hdrfile.h> // and it resides in the current directory of the
> > src.c => That means somewhere -I also consider current directory …
>
> If you specify -I . on the command line, then this will work.
> Otherwise, it will not be found.
>
My interpretation must again be wrong here, but the way I under stood is
that the std. says it only search whatever in -I, and if the include path
don’t have the current directory ( where both the include file and the src
file exists ) then it will miss ( as per std.).
>
>
> > Two things ( at least ) very confusing when it comes to MS compilers -
> >
> > 1) #include
> > 2) typedefs
>
> I think you are merely spreading your own misconceptions here.
> Microsoft has always had the #include behavior correct. VC7 had a few
> non-compliance issues with templates, but not with basic typedefs, and
> virtually all of them are resolved in VC8.
>
But I’ve seen quite a few warnings on VC8 ( in code path, where it was
#ifdef for posix or win32 ). The warnings were not there in vc7 but were on
vc8. Informations were explict, so taking those win32 block out complied
okay without warnings – that is what I saw, and IIRC they are not
templates, not deprecated calls etc.
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
></hdrfile.h>
Tim’s definition is part of the ANSI C standard.
–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Prokash Sinha” wrote in message news:xxxxx@ntdev…
> On Fri, Jun 12, 2009 at 1:24 PM, Tim Roberts wrote:
>
>> Prokash Sinha wrote:
>> > What you are saying is correct. IIRC, one of edition of "C programming
>> > languages " mentioned it …
>> > #include “hdrfile.h” => look at the current directory. i.e. the
>> > directory of the includer ( usually a src.c file ). Don’t look
>> > anywhere else.
>>
>> No. It says look FIRST in the current directory, THEN look at the -I
>> path. Angle brackets merely eliminates the first step.
>>
>
> Looks like my interpretation is wrong, I need to look at the book again to
> see if implies to take the -I also for " " include.
>
>>
>>
>> > For some reason, I’ve seen MS compilers do include file from the
>> > current directory of the src.c file, even if you mentioned the
>> > following
>> -
>> > #include <hdrfile.h> // and it resides in the current directory of the
>> > src.c => That means somewhere -I also consider current directory …
>>
>> If you specify -I . on the command line, then this will work.
>> Otherwise, it will not be found.
>>
>
> My interpretation must again be wrong here, but the way I under stood is
> that the std. says it only search whatever in -I, and if the include path
> don’t have the current directory ( where both the include file and the src
> file exists ) then it will miss ( as per std.).
>
>>
>>
>> > Two things ( at least ) very confusing when it comes to MS compilers -
>> >
>> > 1) #include
>> > 2) typedefs
>>
>> I think you are merely spreading your own misconceptions here.
>> Microsoft has always had the #include behavior correct. VC7 had a few
>> non-compliance issues with templates, but not with basic typedefs, and
>> virtually all of them are resolved in VC8.
>>
>
>
> But I’ve seen quite a few warnings on VC8 ( in code path, where it was
> #ifdef for posix or win32 ). The warnings were not there in vc7 but were
> on
> vc8. Informations were explict, so taking those win32 block out complied
> okay without warnings – that is what I saw, and IIRC they are not
> templates, not deprecated calls etc.
>
>
>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4151 (20090612)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
Information from ESET NOD32 Antivirus, version of virus signature database 4151 (20090612)
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com</hdrfile.h>
Thanks Don for point out the difference. Time for me to forget about
construct like f() { body}
Got it…
Well, as if I’ve to sign something !
Prokash Sinha
http://prokash.squarespace.com
Success has many fathers, but failure is an orphan.
----- Original Message -----
From: “Don Burn”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Friday, June 12, 2009 1:51 PM
Subject: Re:[ntdev] build compling
> Tim’s definition is part of the ANSI C standard.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
> “Prokash Sinha” wrote in message news:xxxxx@ntdev…
>> On Fri, Jun 12, 2009 at 1:24 PM, Tim Roberts wrote:
>>
>>> Prokash Sinha wrote:
>>> > What you are saying is correct. IIRC, one of edition of "C programming
>>> > languages " mentioned it …
>>> > #include “hdrfile.h” => look at the current directory. i.e. the
>>> > directory of the includer ( usually a src.c file ). Don’t look
>>> > anywhere else.
>>>
>>> No. It says look FIRST in the current directory, THEN look at the -I
>>> path. Angle brackets merely eliminates the first step.
>>>
>>
>> Looks like my interpretation is wrong, I need to look at the book again
>> to
>> see if implies to take the -I also for " " include.
>>
>>>
>>>
>>> > For some reason, I’ve seen MS compilers do include file from the
>>> > current directory of the src.c file, even if you mentioned the
>>> > following
>>> -
>>> > #include <hdrfile.h> // and it resides in the current directory of the
>>> > src.c => That means somewhere -I also consider current directory …
>>>
>>> If you specify -I . on the command line, then this will work.
>>> Otherwise, it will not be found.
>>>
>>
>> My interpretation must again be wrong here, but the way I under stood is
>> that the std. says it only search whatever in -I, and if the include path
>> don’t have the current directory ( where both the include file and the
>> src
>> file exists ) then it will miss ( as per std.).
>>
>>>
>>>
>>> > Two things ( at least ) very confusing when it comes to MS compilers -
>>> >
>>> > 1) #include
>>> > 2) typedefs
>>>
>>> I think you are merely spreading your own misconceptions here.
>>> Microsoft has always had the #include behavior correct. VC7 had a few
>>> non-compliance issues with templates, but not with basic typedefs, and
>>> virtually all of them are resolved in VC8.
>>>
>>
>>
>> But I’ve seen quite a few warnings on VC8 ( in code path, where it was
>> #ifdef for posix or win32 ). The warnings were not there in vc7 but were
>> on
>> vc8. Informations were explict, so taking those win32 block out complied
>> okay without warnings – that is what I saw, and IIRC they are not
>> templates, not deprecated calls etc.
>>
>>
>>
>>> –
>>> Tim Roberts, xxxxx@probo.com
>>> Providenza & Boekelheide, Inc.
>>>
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>>
>>
>> Information from ESET NOD32 Antivirus, version of virus
>> signature database 4151 (20090612)
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>>
>
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4151 (20090612)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</hdrfile.h>
do i need to redirect the file by using this command
INCLUDES=$(final);…....\inc
dont understand the …....\inc
xxxxx@gmail.com wrote:
do i need to redirect the file by using this command
INCLUDES=$(final);…....\inc
dont understand the …....\inc
You really need to have some basic understanding of makefiles in order
to use the WDK.
You apparently copied this “sources” from some other project, which
includes a bunch of include files laid out in a directory tree. The
…....\inc says that it should look for include files in a directory
way up the tree. Up three directories, then down to “inc”. So, if your
source code was in “c:\myfiles\project\src\driver\part1”, then
“…....\inc” refers to “c:\myfiles\project\inc”. That’s basic command
shell stuff.
The ${final} you have there is almost certainly a mistake. That would
only be valid if you had an environment variable called “final”, or had
defined a variable called “final” in the sources file.
We’ve already told you how to proceed here. If the file “public.h” is
in the same directory as “sources”, then just make sure you have
#include “public.h”
and NOT
#include <public.h>
But if the file is in a different directory, then you need to name that
directory in the INCLUDES variable. We don’t know your directory
structure, so we don’t know where the file lives. If you have all of
your files in the same directory, then you don’t need the INCLUDES
variable at all, but you need to use the right #include line for your
own include files.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</public.h>
xxxxx@gmail.com wrote:
do i need to redirect the file by using this command
INCLUDES=$(final);…....\inc
dont understand the …....\inc
Alternatively, zip up your whole project tree and email it to me
privately, and I’ll fix it and send it back. That will probably be
quicker for all involved.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.