ALEC999:
I don’t think this has anything in particular to do with x64. The
actual line in question would be helpful, but that error usually occurs
when a function declaration uses an undefined type somewhere in its
statement. To the best of my knowledge, I don’t believe that it is
possible to include both Windows and NTDDK (or WDM.H, NTIFS.H), without
modifications. I have no idea of what those might be, and how long they
would take. If they are at all reasonable, there is no decision to be
made - go that way.
Otherwise, as it would be very difficult to be using as significant
amount of both user and kernel, you have to pick one and add what you
need from the other. In your case, I have to believe that you are only
using a handful of top level stuff from the WDK, so reimplement the
necessary declarations for that. Having had to recreate parts of the
WDK headers for totally different reasons, my advice would be that
attempting to create it step by step exactly will take an amazingly long
time for what would seem like only a small amount of code, and that
attempting to do so will drive you out of your mind. For example, if
something that you want involves and IRP, your going to be there for a
while before you can actually get the IRP itself. I found it much, much
easier to more or less just roll my own types as needed, because this
allows you to temporarily cheat on thing such as enumerations or
manifests constants that will always end up as an integer of some type.
Unless you are interested in making this effort portable, which is
actually not that hard, whether you make something a long or an int
generally is not likely to matter all that much for your purposes.
Basically, this allows you to use a dump from WinDbg (dt -b -v) to get
the cardinal type and size, to free you from having to look up
everything that is some form of a 32-bit integer immediately; this is an
amazing amount of stuff, much of it nested several levels deep.
Ultimately, you need to implement all of it correctly, consistently and
fully, but just to get rolling, this comes in very handy.
As matter of personal preference, the other reason I did not recreate
the necessary parts exactly is that I wanted it to be obvious that the
WDK itself was not being used, because you’re going to get some of it
wrong, and no one, including yourself down the road, is ever going to
think to consider this as a possibility if it looks the same.
I did this a long time ago. Today, if I had reason and there were no
way to simply modify files to just include them, I would use the perl
scripts I have written that take the results of dt and generate C
structs.
MM
>> xxxxx@gmail.com 2006-09-14 07:48 >>>
Hi all,
I am trying to compile my user space library for x64.
The problem is that I am including ntifs.h or ntddk.h that i need for
some native functions.
#define AMD64 1
or
#define X86 1
extern “C” {
#include <ntddk.h>
or
#include <ntifs.h>
}
I am using WNET path to DDK headers of IFS kit 3790.1830 compiled on
Visual 2005.
I get this when trying to compile -> error C4430: missing type
specifier - int assumed. Note: C++ does not support default-int
Any advice on how to compile user space for x64?
Regards,
Alec999
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</ntifs.h></ntddk.h>
