using % operator on a ULONGLONG with the w2k free build

this generates unresolved external symbol __aulldvrm. This function does
unsigned long long divide remain. If I look around inside int64.lib I can
see there is __aulldiv and __aullrem ... but no __aulldvrm. The funny thing
is that all is ok if I build with the w2k checked build. So I'm guessing the
compiler is doing something different in free mode in order to generate a
call to a function that does not exist.

I can get round my problem easily by using RtlEnlargedUnsignedDivide() ...
but the ddk help tells me this function is obsolete and tells me I should
"use the compiler support for 64-bit integer operations" ... but what exactly
does that mean? I'm using LONGLONGs (__int64) everywhere so I assume the
compiler already has support for 64-bit integer operations.

David
Sat Jun 24 13:25:16 CDT 2006

What DDK? What compiler version? Use Server 2003 SP1 DDK or IfsKit. Use
the supplied compiler.

"mirage2k2" <mirage2k2@discussions.microsoft.com> wrote in message
news:13405F9A-A800-406C-9350-C0499E668158@microsoft.com...
> this generates unresolved external symbol __aulldvrm. This function does
> unsigned long long divide remain. If I look around inside int64.lib I can
> see there is __aulldiv and __aullrem ... but no __aulldvrm. The funny
> thing
> is that all is ok if I build with the w2k checked build. So I'm guessing
> the
> compiler is doing something different in free mode in order to generate a
> call to a function that does not exist.
>
> I can get round my problem easily by using RtlEnlargedUnsignedDivide() ...
> but the ddk help tells me this function is obsolete and tells me I should
> "use the compiler support for 64-bit integer operations" ... but what
> exactly
> does that mean? I'm using LONGLONGs (__int64) everywhere so I assume the
> compiler already has support for 64-bit integer operations.

mirage2k2
Sun Jun 25 19:27:01 CDT 2006

w2k3 server sp1 ddk, w2k free build. w2k checked build is ok!

"David J. Craig" wrote:

> What DDK? What compiler version? Use Server 2003 SP1 DDK or IfsKit. Use
> the supplied compiler.
>
> "mirage2k2" <mirage2k2@discussions.microsoft.com> wrote in message
> news:13405F9A-A800-406C-9350-C0499E668158@microsoft.com...
> > this generates unresolved external symbol __aulldvrm. This function does
> > unsigned long long divide remain. If I look around inside int64.lib I can
> > see there is __aulldiv and __aullrem ... but no __aulldvrm. The funny
> > thing
> > is that all is ok if I build with the w2k checked build. So I'm guessing
> > the
> > compiler is doing something different in free mode in order to generate a
> > call to a function that does not exist.
> >
> > I can get round my problem easily by using RtlEnlargedUnsignedDivide() ...
> > but the ddk help tells me this function is obsolete and tells me I should
> > "use the compiler support for 64-bit integer operations" ... but what
> > exactly
> > does that mean? I'm using LONGLONGs (__int64) everywhere so I assume the
> > compiler already has support for 64-bit integer operations.
>
>
>

Tim
Sun Jun 25 19:58:48 CDT 2006

mirage2k2 <mirage2k2@discussions.microsoft.com> wrote:
>
>this generates unresolved external symbol __aulldvrm. This function does
>unsigned long long divide remain. If I look around inside int64.lib I can
>see there is __aulldiv and __aullrem ... but no __aulldvrm. The funny thing
>is that all is ok if I build with the w2k checked build. So I'm guessing the
>compiler is doing something different in free mode in order to generate a
>call to a function that does not exist.

Right. It only calls __aulldvrm if it determines that you are using both
the quotient and the remainder, and it only makes that check when
optimizations are turned on.

>I can get round my problem easily by using RtlEnlargedUnsignedDivide() ...
>but the ddk help tells me this function is obsolete and tells me I should
>"use the compiler support for 64-bit integer operations" ... but what exactly
>does that mean? I'm using LONGLONGs (__int64) everywhere so I assume the
>compiler already has support for 64-bit integer operations.

Yes, the compiler has support for 64-bit ints, but it implements some of
those operations using library routines, and that routine is missing from
the Win2K libraries. It is a bug in the DDK. Google shows references to
this from 2003.

The easiest solution is to copy int64.lib from lib\wnet\i386 over the top
of lib\w2k\i386 in your DDK.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.