Currently there are quite a few places in ROS src where 64-bit integral
constants are either hard-coded to be GNU C only (?), or almost worse
littered with conditional compilation.
Neither is satisfactory. 1 is making it impossible to compile using e.g. an
MS compiler, and 2 makes the code so ugly that... Well, you understand.
So, in the interest of fixing this once and for all, the only option is to
name a macro to handle these compiler specifics in one place, and then use
that macro when defining 64-bit integral constants. The question is then,
what to name it? The macro will be defined something like (omitting unsigned
here):
#if defined __GNUC__
#define ZZZ(X) X##LL
#elif defined _MSC_VER
#define ZZZ(X) X##i64
#else
#error Unknown compiler for 64-bit integral constant suffix
#endif
Serious suggestions that have surfaced so far are:
DEFINE_INT64
MAKE_INT64
If suggesting something else, keep in mind that
- while short might be beautiful (and fast to type), using short macros is
likely to sooner or later create conflicts.
- leading underscore followed by capital character or another underscore is
not legal for C++.
- It's to make it clear that it's a 64-bit int defined, why suggestions
mentioning LL or i64, as in compiler-specific extensions/implementation
details, are likely not to help or be accepted since that's exactly what we
want to get away from.
Please comment.
/Mike
gcc -I./include -I../include -D__NTOSKRNL__ -Wall -Werror
-D_DISABLE_TIDENTS -
D_SEH_NO_NATIVE_NLG -D__3GB__ -I../include -I../w32api/include -pipe
-march=i486
-D_M_IX86 -D__NTOSKRNL__ -I. -D_SEH_NO_NATIVE_NLG -I../include
-I../w32api/incl
ude -pipe -march=i486 -D_M_IX86 -D__NTOSKRNL__ -I. -D_SEH_NO_NATIVE_NLG
-I../inc
lude -I../w32api/include -pipe -march=i486 -D_M_IX86 -c ke/i386/exp.c -o
ke/i386
/exp.o
ke/i386/exp.c: In function `KiTrapHandler':
ke/i386/exp.c:579: error: `ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY'
undeclared (fi
rst use in this function)
ke/i386/exp.c:579: error: (Each undeclared identifier is reported only once
ke/i386/exp.c:579: error: for each function it appears in.)
mingw32-make[1]: *** [ke/i386/exp.o] Error 1
mingw32-make[1]: Leaving directory `C:/reactos/ntoskrnl'
mingw32-make: *** [ntoskrnl] Error 2
C:\reactos>gcc --version
gcc (GCC) 3.4.1 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I've tried my best to make a working implementaiton of
StackAttach/StackDetach, because it's almost one of the most important
APIs in NT5+ Drivers. I think I've got Detach working properly, but
Attach will require some changes to KeAttach itself so that it can save
the old ApcState & other things. I might get around to fixing it, but at
least the API should work now and allow more drivers to run sucesfully.
Also, if any Intel experts woudl like to check out KeFlushCurrentTb... I
followed the Intel Manual specs, just want to make sure I did it
properly...my GNU Assembler syntax sucks.
Best regards,
Alex Ionescu
ion(a)cvs.reactos.com wrote:
>CVSROOT: /CVS/ReactOS
>Module name: reactos
>Repository: reactos/ntoskrnl/ke/
>Changes by: ion(a)mok.osexperts.com 04/10/12 18:42:15
>
>Modified files:
> reactos/include/ddk/: kefuncs.h
> reactos/ntoskrnl/: Makefile.i386
> reactos/ntoskrnl/include/internal/: ke.h ps.h
> reactos/ntoskrnl/ke/: apc.c device.c dpc.c kthread.c process.c
>
>Log message:
> Implemented KeAreApcsDisabled, KeFlushEntireTb, KeIsExecutingDpc, KeSetKernelStackSwapEnable, KeQueryPriorityThread, KeRevertToUserAffinityThread, KeSetIdealProcessorThread, KeSetSystemAffinityThread, KeTerminateThread, KeStackAttachProcess, KeUnstackDetachProcess
>
>_______________________________________________
>Ros-cvs mailing list
>Ros-cvs(a)reactos.com
>http://reactos.com/mailman/listinfo/ros-cvs
>
>
>
Hello,
For almost a week now my symbols have been missing. It started
with gdb not reading in any symbols when I was trying to hunt down
cygwin problems, then I re-enabled KDBG in config and rebuilt and KDBG
can tell you the function name, but not the file name and line number.
Last night, I deleted my sandbox and checked out a fresh copy from
CVS, only enabling DBG. I think it was Arty who suggested I check to
see if the targets are getting the "-g" flag. I captured the entire
build into a log, and these are the only targets that had "-g" on the
gcc command line:
ntdll (-g)
opengl32 (-g3)
dnsapi (-g)
bzip2 (-g)
oskittcp (-g)
patblt (-g)
primitives (-g)
strechblt (-g)
txtscale (-g)
wm_erasebkgnd (-g)
I checked this against my symbols directory and they correspond to
.sym files that appear to be valid. All the others are 16 bytes, and
don't appear to contain any useful information.
I'm not much of a make guru, so I thought I would report it rather
than continue to hunt it down alone. ;0)
Thanks,
Andrew
--
The cheese stands alone.
Hi!
Since I have seen mesa32 crash with SSE enabled I looked into fixing it
a bit...
When I was looking at ntoskrnl/ke/i386/tskswitch.S I found FIXMEs for
debug/FPU save/restore.
Now I am wondering where should this information be stored? I think it
should be part of the TSS (include/ntos/tss.h) but I am not sure.
For SSE support the SSE registers would also have to be saved/restored
on task switches and some other stuff which I do not yet know I think.
Maybe somebody can tell me where the FPU state should be stored so I can
try to implement it.
Thanks,
blight
Hi,
Anyone against switching ROS to be compiled by default on the 2GB
boundary? (This can always be locally changed by /3GB = 1)
For the sake of consistency and perhaps better driver support, as has
been found in the past.
Then we can start working on a real freeldr PE loader...
Best regards,
Alex Ionescu
Why is CVSspam output generated for only some of the ReactOS developers ?
Reading what was changed is very interesting for me
and CVSspam produces very nice diff.
Thanks, David
--
David Kredba <kredba at ibot.cas.cz>
GPG: ID 1024D/5B6B02DE
Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE
Hi James,
please update to the latest version, this has been fixed.
see
http://cvs.reactos.com/cgi-bin/cvsweb.cgi/reactos/subsys/system/winefile/it.
rc.diff?r1=1.2&r2=1.3
-----Message d'origine-----
De : James Tabor
[mailto:jimtabor@adsl-64-217-116-74.dsl.hstntx.swbell.net]
Envoyé : samedi 9 octobre 2004 03:17
À : ros-dev(a)reactos.com
Objet : [ros-dev] Re: [ros-cvs] CVS Update: reactos
mf(a)cvs.reactos.com wrote:
> CVSROOT: /CVS/ReactOS
> Module name: reactos
> Repository: reactos/subsys/system/winefile/
> Changes by: mf(a)mok.osexperts.com 04/10/08 13:20:15
>
> Modified files:
> reactos/subsys/system/winefile/: winefile.c winefile.h
>
> Log message:
> call vswprintf@msvcrt in Wine's UNICODE version
>
i386-mingw32-windres -D__USE_W32API -DNDEBUG -DWIN32 -D_ROS_ -D__WINDRES__
-DUNICODE --include-dir
../../../include --include-dir ../../../w32api/include winefile.rc -o
winefile.coff
i386-mingw32-windres: it.rc:184: parse error
make: *** [winefile.coff] Error 1
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
----------------------------------------------------------------------------
Ce message ainsi que toutes pièces jointes (le "message") sont confidentiels
et sont exclusivement destinés à l'usage de la personne à laquelle ils sont
adressés. Tout point de vue ou toute opinion contenus dans ce message
expriment la pensée personnelle de leur auteur et ne représentent pas
nécessairement la position des sociétés du Groupe GEFCO. Si vous n'êtes pas
la personne à laquelle ce message est destiné, veuillez noter que vous avez
reçu cet e-mail par erreur et qu'il vous est strictement interdit
d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message.
Si vous avez reçu ce message par erreur, merci de contacter la personne qui
vous l'a adressé et de l'effacer immédiatement. Les sociétés du Groupe GEFCO
déclinent toute responsabilité en cas d'altération, de modification,
d'édition, de diffusion sans autorisation de ce message ou en cas
d'affection de ce message par un virus.
This message and any attachments (the "message") are confidential and
intended solely for the use of the individual to whom they are addressed.
Any views or opinions presented are solely those of the author and do not
necessarily represent those of the GEFCO Group of Companies. If you are not
the intended recipient, be advised that you have received this email in
error and that any use, dissemination, forwarding, printing, or copying of
this message is strictly prohibited. If you have received this message in
error please contact the sender and delete the message immediately. The
GEFCO Group of Companies shall not be liable for the message if altered,
changed, falsified, edited, diffused without authorization or affected by
any virus.
----------------------------------------------------------------------------
