Doubt regarding WDK 7000
Aruns
My name is Austin and I am into printer driver development. We were using WDK
6000 for driver development. Recently we downloaded WDK for Windows 7 RC
(7000) and started using the same for our driver development.
Have one doubt here:
In the Release Notes for WDK 7000, it is mentioned that:
Windows 2000 Build Environment no longer supported
The libraries for Microsoft Windows 2000 have been removed from the WDK.
_NT_Target_Version=$(NT_TARGET_VERSION_WIN2K) will result in an error.
I would like to know whether the driver DLLs built with WDK 7000 will work
fine for Windows 2000.
We develop a single set of 32 bit binaries for Windows 2000, XP and Vista.
I would also like to know whether it is mandatory to have SP3 for XP to
install WDK 7000. (We were able to install the same in XP SP2 development
PCs).
Doron Holan [MSFT]
it is possible to build a dll in the win7 wdk that will load on win2k, you
have to be more careful about what you import. your best bet is probably to
target XP (_NT_Target_Version=$(NT_TARGET_VERSION_WINXP) and go from there.
d
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Aruns" <Ar...@discussions.microsoft.com> wrote in message
news:8FAF8C13-3B19-49A7...@microsoft.com...
Aruns
Thank you Holan,
where do we give this _NT_Target_Version in project settings?
We have defined _WIN32_WINNT with value 0x06000000 in our driver DLL project
settings and MachineX86 as Target Machine.
Doron Holan [MSFT]
look in the sources files for the samples in the wdk. for instance
_NT_TARGET_VERSION= $(_NT_TARGET_VERSION_WINXP)
_WIN32_WINNT is something different
d
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Aruns" <Ar...@discussions.microsoft.com> wrote in message
news:D91C2F53-5A2A-4B76...@microsoft.com...
Aruns
We haven't used _NT_TARGET_VERSION anywhere in our source. And if it is so,
is it OK to build using WDK 7000 for Windows 2000?
Tim Roberts
>
>We haven't used _NT_TARGET_VERSION anywhere in our source.
He didn't say to put it in your source. He said to "look in the sources
file". That specifically means the file called "sources", which has the
directives to "build" and "nmake" during the build process.
>And if it is so, is it OK to build using WDK 7000 for Windows 2000?
No, and Doron said this. Did you actually read his reply? WDK 7000 no
longer includes support for Windows 2000, BUT in many cases a driver built
for XP will work in Windows 2000. That's what he's suggesting you do.
Build for XP, then test it on 2000 and see if it works.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Aruns
Thanks a lot Tim, Actually we have only one set of 32 bit binaries
targetting Windows 2000, XP, Vista and even Windows 7. And it seems to be
working fine for all of these. So is it OK to support Windows 2000 if we are
not able to find any issues with this from our testing in Windows 2000?
Volodymyr Shcherbyna
>
> Thanks a lot Tim, Actually we have only one set of 32 bit binaries
> targetting Windows 2000, XP, Vista and even Windows 7. And it seems to be
> working fine for all of these. So is it OK to support Windows 2000 if we
> are
> not able to find any issues with this from our testing in Windows 2000?
Yes. Especially taking into account that 2k is not already supported ...
--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)
Tim Roberts
>
>Thanks a lot Tim, Actually we have only one set of 32 bit binaries
>targetting Windows 2000, XP, Vista and even Windows 7. And it seems to be
>working fine for all of these. So is it OK to support Windows 2000 if we are
>not able to find any issues with this from our testing in Windows 2000?
Yep, that's the best you can do. You just need to be aware that, if your
driver breaks on Windows 2000 because of a DDK problem, you can't get
official Microsoft support help to solve the problem.
Volodymyr Shcherbyna
not load at all in 2k because of some extra tricks which compiler added
because it 'thought', the target is Windows XP. This kind of problems can be
quickly analyzed and fixed (mostly by turning off compiler optimization for
particular piece of code).
--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)
"Tim Roberts" <ti...@probo.com> a �crit dans le message de
news:gr8855p6qe3bph3tk...@4ax.com...
Maxim S. Shatskih
> not load at all in 2k because of some extra tricks which compiler added
> because it 'thought', the target is Windows XP.
__except_handler3 exported by the kernel itself (not by DDK's static lib), to name one.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
Volodymyr Shcherbyna
>> Personally, I think the only problem OP can face is that the driver would
>> not load at all in 2k because of some extra tricks which compiler added
>> because it 'thought', the target is Windows XP.
>
> __except_handler3 exported by the kernel itself (not by DDK's static lib),
> to name one.
>
The other is, __alldiv exported by XP kernel, but not by 2k. If driver
compiled for XP uses % (modulus remainder) it might not load on 2k, as
optimizer uses __alldiv in this case.
Kalle Olavi Niemitalo
> Maxim S. Shatskih wrote:
>> __except_handler3 exported by the kernel itself (not by DDK's static lib),
>> to name one.
>
> The other is, __alldiv exported by XP kernel, but not by 2k. If driver
> compiled for XP uses % (modulus remainder) it might not load on 2k, as
> optimizer uses __alldiv in this case.
How does one work around such problems if the driver needs to run
on W2K?
I suppose it's straightforward to implement __alldiv in asm or C
if necessary, and thus avoid importing it from the kernel.
But how about __except_handler3: does the compiler generate
references to it for each __catch clause, and is the behaviour
documented or at least easy enough to figure out, so that the
function can be rewritten?
Or do you suggest extracting the implementation from the static
library in the old DDK? I hope it doesn't have too many
dependencies on other parts of the library.
Volodymyr Shcherbyna
news:87tz1ms...@Astalo.kon.iki.fi...
[...]
> I suppose it's straightforward to implement __alldiv in asm or C
> if necessary, and thus avoid importing it from the kernel.
> But how about __except_handler3: does the compiler generate
> references to it for each __catch clause, and is the behaviour
> documented or at least easy enough to figure out, so that the
> function can be rewritten?
> Or do you suggest extracting the implementation from the static
> library in the old DDK? I hope it doesn't have too many
> dependencies on other parts of the library.
I suggest to NOT make too big efforts to support 2k ... The problem with
__alldiv is fixed very simply, by turning off optimizer for a particular
piece of code, for example, a function:
#pragma optimize( "", off )
void mydummyfunction()
{
/// some code goes here
}
#pragma optimize( "", on)
Regarding each try/except clause, no need to worry about it. If you put the
following code inside your DriverEntry function:
try
{
KeBugCheck(0x0);
}
except(EXCEPTION_EXECUTE_HANDLER)
{
KeBugCheck(0x1);
}
And compile it as a target for XP, the following code will be produced:
page:00010886 DriverEntry proc near ; CODE XREF:
GsDriverEntry+39 j
page:00010886 push 10h
page:00010888 push offset unk_11518
page:0001088D call __SEH_prolog4
page:00010892 xor ecx, ecx
page:00010894 mov [ebp-20h], cx
page:00010898 xor eax, eax
page:0001089A lea edi, [ebp-1Eh]
page:0001089D stosd
page:0001089E stosw
page:000108A0 mov [ebp-4], ecx
page:000108A3 push ecx
page:000108A4
page:000108A4 loc_108A4: ; CODE XREF:
sub_108AE+5 j
page:000108A4 call ds:__imp__KeBugCheck@4 ; KeBugCheck(x)
page:000108AA
page:000108AA loc_108AA: ; DATA XREF:
.rdata:0001152C o
page:000108AA xor eax, eax
page:000108AC inc eax
page:000108AD retn
page:000108AD DriverEntry endp
As you can see, there is a call for SEH prolog,
page:0001088D call __SEH_prolog4
Which is implemented in binary, i.e, it is not imported from nt kernel
.text:000104C4 __SEH_prolog4 proc near ; CODE XREF:
DriverEntry+7 p
.text:000104C4
.text:000104C4 arg_4 = dword ptr 8
.text:000104C4
.text:000104C4 push offset _except_handler4
.text:000104C9 push large dword ptr fs:0
.text:000104D0 mov eax, [esp+8+arg_4]
.text:000104D4 mov [esp+8+arg_4], ebp
.text:000104D8 lea ebp, [esp+8+arg_4]
.text:000104DC sub esp, eax
.text:000104DE push ebx
.text:000104DF push esi
.text:000104E0 push edi
.text:000104E1 mov eax, __security_cookie
.text:000104E6 xor [ebp-4], eax
.text:000104E9 xor eax, ebp
.text:000104EB push eax
.text:000104EC mov [ebp-18h], esp
.text:000104EF push dword ptr [ebp-8]
.text:000104F2 mov eax, [ebp-4]
.text:000104F5 mov dword ptr [ebp-4], 0FFFFFFFEh
.text:000104FC mov [ebp-8], eax
.text:000104FF lea eax, [ebp-10h]
.text:00010502 mov large fs:0, eax
.text:00010508 retn
.text:00010508 __SEH_prolog4 endp ; sp = -1Ch
Which relies upon _except_handler4, which is also implemented in binary. So,
this code will happily bsod your 2k machine even though it was compiled for
XP as a target and used try/except.