gcc/msvc int64 suffix/LARGE_INTEGER portability macros

[Gunnar Dalsnes]

Suggested gcc/msvc portability macros:
#if defined(_MSC_VER)
   #define MK_INT64(a) (a)
   #define MK_UINT64(a) (a)
   __inline LARGE_INTEGER MK_LARGE_INTEGER(__int64 i)
   {
      LARGE_INTEGER li;
      li.QuadPart = i;
      return li;
   }
   #define LARGE_INTEGER_NULL MK_LARGE_INTEGER(0)
#elif defined (__GNUC__)
   #define MK_INT64(a) (a##LL)
   #define MK_UINT64(a) (a##ULL)
   #define MK_LARGE_INTEGER(a) ((LARGE_INTEGER)(LONGLONG)a)
   #define LARGE_INTEGER_NULL ((LARGE_INTEGER)(LONGLONG)0LL)
#else
   #error Unknown compiler for LARGE_INTEGER/int64 macros
#endif
example:
LARGE_INTEGER test1(LARGE_INTEGER arg)
{
 return MK_LARGE_INTEGER(arg.QuadPart+3);
}
LARGE_INTEGER test2()
{
 LARGE_INTEGER a = LARGE_INTEGER_NULL;
 a.QuadPart += test1(LARGE_INTEGER_NULL).QuadPart;
 a.QuadPart += MK_INT64(1152921504606846975);
 return LARGE_INTEGER_NULL;
}
What do you think?
Gunnar

[Mike Nordell]

Gunnar Dalsnes wrote:
>   Suggested gcc/msvc portability macros:
>  #if defined(_MSC_VER)
>     #define MK_INT64(a) (a)
>     #define MK_UINT64(a) (a) 
Why not the explicit suffix (i.e. "(a##i64)" and "(a##ui64)")?
Especially
the latter is required to be able to create specifically an unsigned 64-bit
integer.
>      __inline LARGE_INTEGER MK_LARGE_INTEGER(__int64 i)
If anything, "static __inline", but there are more problems with this as
I'll explain below.
>      {
>        LARGE_INTEGER li;
>        li.QuadPart = i;
>        return li;
>     }
>     #define LARGE_INTEGER_NULL MK_LARGE_INTEGER(0) 
and this is the problem. It does not evaluate to a LARGE_INTEGER
intitialized to the value zero at compile-time. To verify, just add
  static const LARGE_INTEGER zero = MK_LARGE_INTEGER(0);
at file scope, and see the C compiler complain "initializer is not a
constant".
>  From the looks of it, none of these problems are
> present in the GNUC path. 
Another potential source of confusion could be the use of "NULL", which in
the context of both C and C++ is carved in stone to mean a null-pointer
value. What about the character 0 (zero)?
The initialization of a LARGE_INTEGER is indeed a problem, since it's an
aggregate type, and I don't see a clean and portable solution to that
problem. For the simple case of zero-initializing an external or static
LARGE_INTEGER one can use something like
  LARGE_INTEGER Li0 = { 0 };
but I have seen it suggested this might not be intended to work for
variables with automatic storage duration.
--
/Mike

[Magnus Olsen]

Hi
long long are working as 64 bits in MS visualstuido 7.1
I do not have older version of vc, but I think it work same there
----- Original Message -----
From: "Gunnar Dalsnes" <hardon(a)online.no>
To: "ReactOS Development List" <ros-dev(a)reactos.com>
Sent: Tuesday, February 01, 2005 1:18 PM
Subject: [ros-dev] gcc/msvc int64 suffix/LARGE_INTEGER portability macros
>   Suggested gcc/msvc portability macros:
>  #if defined(_MSC_VER)
>     #define MK_INT64(a) (a)
>     #define MK_UINT64(a) (a)
>     __inline LARGE_INTEGER MK_LARGE_INTEGER(__int64 i)
>     {
>        LARGE_INTEGER li;
>        li.QuadPart = i;
>        return li;
>     }
>     #define LARGE_INTEGER_NULL MK_LARGE_INTEGER(0)
>  #elif defined (__GNUC__)
>     #define MK_INT64(a) (a##LL)
>     #define MK_UINT64(a) (a##ULL)
>     #define MK_LARGE_INTEGER(a) ((LARGE_INTEGER)(LONGLONG)a)
>     #define LARGE_INTEGER_NULL ((LARGE_INTEGER)(LONGLONG)0LL)
>  #else
>     #error Unknown compiler for LARGE_INTEGER/int64 macros
>  #endif
>  example:
>  LARGE_INTEGER test1(LARGE_INTEGER arg)
>  {
>   return MK_LARGE_INTEGER(arg.QuadPart+3);
>  }
>  LARGE_INTEGER test2()
>  {
>   LARGE_INTEGER a = LARGE_INTEGER_NULL;
>   a.QuadPart += test1(LARGE_INTEGER_NULL).QuadPart;
>   a.QuadPart += MK_INT64(1152921504606846975);
>   return LARGE_INTEGER_NULL;
>  }
>  What do you think?
>  Gunnar
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev

[AzeemArif]

Hello ROS-Devs,
I've been sharing some thoughts about DOS subsystem on ReactOS forum. I
am pasting my last post
(http://reactos.com/forum/viewtopic.php?p=2864#2864 )
<http://reactos.com/forum/viewtopic.php?p=2864#2864>
here for your comments
========================================================
hello,
I am back with my silly posts Smile
But this time, after seriously reading and experimenting with FreeDos
and DosEmu code.
As many people suggested FreeDOS as an option to run as ReactOS
subsystem, I concentrated more on FreeDOS.
Something I came to know are
1) We need ReactOS DOS/Win16 subsystem so that we can run 16bit DOS
applications on ReactOS.
2) FreeDOS itself is 16bit system
3) Compiling FreeDOS code with 32bit compiler is so difficult that it
gave birth to a new project FreeDOS-32 (I tried compiling FreeDOS code
with MinGW with no success)
4) FreeDOS-32 is in its infancy. Currently it can't even run simple DOS
applications
5) DOSEmu is really slow
Please give your valuable suggestions.
AcetoliNe: I agree with your last post.
=====================================================================
~AzeemArif
(ReactOS IRC channel - "azar")

[Mike Nordell]

Magnus Olsen wrote:
>   long long are working as 64 bits in MS visualstuido
> 7.1
>  I do not have older version of vc, but I think it work same there 
For at least <= VC6, it doesn't.
/Mike