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
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
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@online.no To: "ReactOS Development List" ros-dev@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@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
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")