🚀 go-pugleaf

"Kris" <ks@ks.com> wrote in message news:46d05592@newsgroups.borland.com...
> Hi,
>
> I'm writing some code to deal with HID devices. This functionality is 
> defined in header files such as hidpddi.h, hidpi.h, hidsdi.h and 
> hidusage.h.
>
> Unfortunately, these files are apparently not included in Builder 2007. So 
> I copied them from Microsoft's DDK and included them in my project.
>
> However, I'm running into several problems and was wondering what is the 
> best way to deal when using these header files in Builder (which are 
> actually intended for use in Visual C++).

<snip>

> Basically I'm wondering how one is able to efficiently and correctly use 
> the DDK header files from Visual studio in Builder 2007 ?

Hi Kris,

It has always been my understanding that C++Builder is not capable of 
building Windows device drivers.  That is always on their "what would you 
like to see in C++Builder?" questionnaire, but apparently it never gets 
enough votes to make it a reality.  It's too bad, but at the same time, I 
can understand it.  C++Builder's primarily selling point is that it is a RAD 
tool.  It can be used to do non-RAD (GUI) development, but that's not where 
it really shines.

- Dennis 

Kris wrote:
> This seems like a never ending story of adding new header files (and 
> having those newly included header files cause other errors). For now I've 
> commented out GetCollectionDescription in order to get things compiled 
> (but the possibility exists that I'm going to still need it later on).

This is sometimes what one has to do to get code written from MSVC to work 
in BCB.


> (2) Hid API calls do not link
> E.g. HidD_GetAttributes(DeviceHandle,&Attributes); compiles fine but fails 
> to link with following error:
> [ILINK32 Error] Error: Unresolved external '__stdcall 
> HidD_GetAttributes(void *, _HIDD_ATTRIBUTES *)' referenced from 
> C:\DOCUMENTS AND SETTINGS\KRIS\MY DOCUMENTS\RAD 
> STUDIO\PROJECTS\USB_HID\DEBUG_BUILD\USB_IO_UNIT.OBJ
>
> For now I've worked around the problem by using GetProcAddress() to 
> extract the location of the function I need from HID.DLL. This works fine, 
> but it sure would be nice if I wouldn't have to do this for every HID 
> function call I want to use.

Use implib on the HID.dll file to get a BCB-compatible .lib file that will 
handle all these imports for you.


> Basically I'm wondering how one is able to efficiently and correctly use 
> the DDK header files from Visual studio in Builder 2007 ?

Like Dennis Jones said, you'll probably find that you need to use VS to 
develop device drivers. I think that there are some limitations to the BCB 
linker and/or compiler that prevent it from being able to create device 
drivers.

Jon 

FWIW: A couple of versions ago I created some device drivers with BCB.  The 
IDE was not up to it.  I had to use the command line to do it.  The linker 
has (had?) an option to create a device driver.

.  Ed

> Jonathan Benedicto wrote in message
> news:46d073e6$1@newsgroups.borland.com...
>
>> This seems like a never ending story of adding new header files (and 
>> having those newly included header files cause other errors). For now 
>> I've commented out GetCollectionDescription in order to get things 
>> compiled (but the possibility exists that I'm going to still need it 
>> later on).
>
> This is sometimes what one has to do to get code written from MSVC to work 
> in BCB.
>
>
>> (2) Hid API calls do not link
>> E.g. HidD_GetAttributes(DeviceHandle,&Attributes); compiles fine but 
>> fails to link with following error:
>> [ILINK32 Error] Error: Unresolved external '__stdcall 
>> HidD_GetAttributes(void *, _HIDD_ATTRIBUTES *)' referenced from 
>> C:\DOCUMENTS AND SETTINGS\KRIS\MY DOCUMENTS\RAD 
>> STUDIO\PROJECTS\USB_HID\DEBUG_BUILD\USB_IO_UNIT.OBJ
>>
>> For now I've worked around the problem by using GetProcAddress() to 
>> extract the location of the function I need from HID.DLL. This works 
>> fine, but it sure would be nice if I wouldn't have to do this for every 
>> HID function call I want to use.
>
> Use implib on the HID.dll file to get a BCB-compatible .lib file that will 
> handle all these imports for you.
>
>
>> Basically I'm wondering how one is able to efficiently and correctly use 
>> the DDK header files from Visual studio in Builder 2007 ?
>
> Like Dennis Jones said, you'll probably find that you need to use VS to 
> develop device drivers. I think that there are some limitations to the BCB 
> linker and/or compiler that prevent it from being able to create device 
> drivers.

Thanks for all the feedback.

Actually, I'm not writing a device driver but just writing a user mode 
application that needs to communicate with the HID device driver (HID 
class devices all use the default windows HID device driver). Convenient 
API calls are available for HID communication. Unfortunately, all of its 
header files are only available in the DDK.

But now at least I understand that using DDK header files does involve 
some work. I was worried I was missing something obvious which was 
causing me to do a lot of extra unnecessary work.

Thanks.

Kris

Ed Mulroy wrote:
> FWIW: A couple of versions ago I created some device drivers with BCB. 
> The IDE was not up to it.  I had to use the command line to do it.  The 
> linker has (had?) an option to create a device driver.

Very interesting, thanks for the information. I'll have to remember that 
when I ever need to write a device driver.

Jon 

If I remember correctly the ilink32 option was /aa for GUI, /ap for console 
mode and /ad for device driver.

.  Ed

> Jonathan Benedicto wrote in message
> news:46d0901d$1@newsgroups.borland.com...
>
> Very interesting, thanks for the information. I'll have to remember that 
> when I ever need to write a device driver.

Not sure if this helps but there was some work done developing device 
drivers using delphi.  I read about it on rootkit.com or 
http://rootkit.host.sk

This might be something worth looking at.

P.S. please post back if you get something - i'm particularly interested in 
this

"Jonathan Benedicto" <invalid@nobody.com> wrote in message 
news:46d073e6$1@newsgroups.borland.com...
> Kris wrote:
>> This seems like a never ending story of adding new header files (and 
>> having those newly included header files cause other errors). For now 
>> I've commented out GetCollectionDescription in order to get things 
>> compiled (but the possibility exists that I'm going to still need it 
>> later on).
>
> This is sometimes what one has to do to get code written from MSVC to work 
> in BCB.
>
>
>> (2) Hid API calls do not link
>> E.g. HidD_GetAttributes(DeviceHandle,&Attributes); compiles fine but 
>> fails to link with following error:
>> [ILINK32 Error] Error: Unresolved external '__stdcall 
>> HidD_GetAttributes(void *, _HIDD_ATTRIBUTES *)' referenced from 
>> C:\DOCUMENTS AND SETTINGS\KRIS\MY DOCUMENTS\RAD 
>> STUDIO\PROJECTS\USB_HID\DEBUG_BUILD\USB_IO_UNIT.OBJ
>>
>> For now I've worked around the problem by using GetProcAddress() to 
>> extract the location of the function I need from HID.DLL. This works 
>> fine, but it sure would be nice if I wouldn't have to do this for every 
>> HID function call I want to use.
>
> Use implib on the HID.dll file to get a BCB-compatible .lib file that will 
> handle all these imports for you.
>
>
>> Basically I'm wondering how one is able to efficiently and correctly use 
>> the DDK header files from Visual studio in Builder 2007 ?
>
> Like Dennis Jones said, you'll probably find that you need to use VS to 
> develop device drivers. I think that there are some limitations to the BCB 
> linker and/or compiler that prevent it from being able to create device 
> drivers.
>
> Jon 

Kris wrote:
> Thanks for all the feedback.
> 
> Actually, I'm not writing a device driver but just writing a user mode 
> application that needs to communicate with the HID device driver (HID 
> class devices all use the default windows HID device driver). Convenient 
> API calls are available for HID communication. Unfortunately, all of its 
> header files are only available in the DDK.
> 
> But now at least I understand that using DDK header files does involve 
> some work. I was worried I was missing something obvious which was 
> causing me to do a lot of extra unnecessary work.

The same thing applies to common Windows SDK. That is the reason I 
started bccsdk. Now if you are willing to do some real work with DDK 
headers and share that with community let me know. Perhaps we can 
include that into bccsdk or I can help you start your own project on 
sourceforge.

Darko

FYI, I just tried these switches in BDS2006's ilink32 and it happily accepts 
them.  I've never tried building a driver with BCC though.  I would love to 
see this as an official feature though, even if just for the bragging rights 
(it's not a real compiler until you can use it for a kernel driver!)

At least with MS tools it is technically possible to write a driver using 
C++, but it's a bit dodgy because of what areas the compiler / linker places 
particular bits of code in.  It's been a long time since I wrote a device 
driver, and I never researched this much since I only ever used C, but I 
gather it was to do with some its of code being placed in sections that were 
loaded by the kernel into swappable memory by default... or something... 
that makes sense as a potential problem though if you expected your code to 
be able to run at any IRQL!  Ed, when you used BCB did you use C or C++?

Cheers,

David


"Ed Mulroy [TeamB]" <dont_email_me@bitbuc.ket> wrote in message 
news:46d0a754@newsgroups.borland.com...
> If I remember correctly the ilink32 option was /aa for GUI, /ap for 
> console mode and /ad for device driver.
>
> .  Ed
>
>> Jonathan Benedicto wrote in message
>> news:46d0901d$1@newsgroups.borland.com...
>>
>> Very interesting, thanks for the information. I'll have to remember that 
>> when I ever need to write a device driver.
>
> 

I did it for the sole purpose of proving to myself that I could.  A third 
party (VMWare?) used to sell a device driver development kit for use with 
Borland's compilers.  When I finally broke down and decided to spend some 
money and buy it I found that they no longer supported Borland's compilers. 
I was trying to demonstrate to myself that I could do it without their help.

I used C++ but deliberately did not use exception handling, runtime type id 
or the STL.  I also used some assembly language (separate *.asm file).  I 
think that at least some assembly is required for any practical device 
driver.

It has been a while since I did it.  The disk on which it was located 
crashed so I am operating from pure memory in describing what I did and 
cannot show a copy of it.

.  Ed

> David M wrote in message
> news:46dcfd29@newsgroups.borland.com...
>
> FYI, I just tried these switches in BDS2006's ilink32 and it happily 
> accepts them.  I've never tried building a driver with BCC though.  I 
> would love to see this as an official feature though, even if just for the 
> bragging rights (it's not a real compiler until you can use it for a 
> kernel driver!)
>
> At least with MS tools it is technically possible to write a driver using 
> C++, but it's a bit dodgy because of what areas the compiler / linker 
> places particular bits of code in.  It's been a long time since I wrote a 
> device driver, and I never researched this much since I only ever used C, 
> but I gather it was to do with some its of code being placed in sections 
> that were loaded by the kernel into swappable memory by default... or 
> something... that makes sense as a potential problem though if you 
> expected your code to be able to run at any IRQL!  Ed, when you used BCB 
> did you use C or C++?