Ros-dev October 2004

ros-dev@reactos.org

46 participants
92 discussions

Compiler-independence for 64-bit integral constants
by Mike Nordell 14 Oct '04

14 Oct '04

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

9 9

Lockup and multi video driver load.
by James Tabor 13 Oct '04

13 Oct '04

Hi, Managed to get things running again. I'm getting this when compiling ros on ros in lib/msvcrt/stdlib; (create.c:36) <\Win32Pipes.00003775.00000001> = <\Win32Pipes.00003775.00000001>, than it just locked up and had to do a ctrl-c to break out and run make again. Now it is slowing down and you can count the char's type across the console screen. Process 4 thread 50 of csrss is eating kernel time. Process 1 thread 3 has the same or less than process 1 thread 0 (aka IdleProcessThread). Note. We need a standalone idle process (0) and thread (0) out side of SYSTEM. Anyway, it finished with out anymore errors or lockups. Next I noticed both vbemp.sys and vgamp.sys loaded. ModuleName Code Data Bss Paged Init LinkDate ------------------------------------------------------------------------------ ntoskrnl.exe 569344 8192 163840 0 49152 Wed Oct 13 19:53:14 2004 hal.dll 28672 4096 135168 0 0 Wed Oct 13 19:53:31 2004 pci.sys 16384 0 4096 0 0 Wed Oct 13 19:54:09 2004 scsiport.sys 20480 0 4096 0 0 Wed Oct 13 20:14:49 2004 atapi.sys 20480 0 4096 0 0 Wed Oct 13 20:14:42 2004 class2.sys 16384 0 0 0 0 Wed Oct 13 20:14:44 2004 disk.sys 12288 0 0 0 0 Wed Oct 13 20:14:45 2004 vfatfs.sys 57344 4096 4096 0 0 Wed Oct 13 20:13:55 2004 bootvid.sys 8192 4096 4096 0 0 Wed Oct 13 20:13:25 2004 ndis.sys 28672 4096 4096 0 0 Wed Oct 13 20:14:16 2004 floppy.sys 20480 0 20480 0 0 Wed Oct 13 20:14:48 2004 cdrom.sys 8192 0 0 0 0 Wed Oct 13 20:14:43 2004 fs_rec.sys 8192 0 0 0 0 Wed Oct 13 20:13:37 2004 beep.sys 4096 0 0 0 0 Wed Oct 13 20:13:22 2004 null.sys 4096 4096 0 0 0 Wed Oct 13 20:13:24 2004 serial.sys 4096 0 0 0 0 Wed Oct 13 20:13:24 2004 psaux.sys 12288 4096 4096 0 0 Wed Oct 13 20:13:28 2004 keyboard.sys 8192 4096 4096 0 0 Wed Oct 13 20:13:26 2004 mouclass.sys 4096 0 0 0 0 Wed Oct 13 20:13:27 2004 debugout.sys 4096 0 0 0 0 Wed Oct 13 20:13:23 2004 blue.sys 8192 0 0 0 0 Wed Oct 13 20:13:22 2004 videoprt.sys 16384 0 4096 0 0 Wed Oct 13 20:15:05 2004 vbemp.sys 8192 0 0 0 0 Wed Oct 13 20:14:59 2004 vgamp.sys 4096 4096 4096 0 0 Wed Oct 13 20:14:58 2004 msfs.sys 8192 0 0 0 0 Wed Oct 13 20:13:39 2004 npfs.sys 12288 0 0 0 0 Wed Oct 13 20:13:42 2004 kmregtests.sys 8192 0 4096 0 0 Wed Oct 13 19:53:19 2004 freetype.dll 417792 4096 0 0 0 Wed Oct 13 19:58:51 2004 win32k.sys 413696 8192 28672 0 0 Wed Oct 13 20:12:30 2004 kbdus.dll 4096 4096 4096 0 0 Wed Oct 13 20:10:01 2004 tcpip.sys 147456 4096 8192 0 0 Wed Oct 13 20:14:34 2004 afd.sys 40960 4096 0 0 0 Wed Oct 13 20:14:09 2004 framebuf.DLL 8192 4096 0 0 0 Wed Oct 13 20:14:57 2004 ------------------------------------------------------------------------------ Total 1953792 69632 405504 0 49152 FYI, James

1 0

Yet another build failure...
by Richard Campbell 13 Oct '04

13 Oct '04

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.

3 3

Re: [ros-cvs] CVS Update: reactos
by Alex Ionescu 13 Oct '04

13 Oct '04

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 > > >

1 0

Missing debug symbols
by WaxDragon 12 Oct '04

12 Oct '04

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.

2 1

Save FPU on task switch/SSE support
by Gregor Anich 12 Oct '04

12 Oct '04

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

5 12

2GB Boundary
by Alex Ionescu 11 Oct '04

11 Oct '04

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

8 13

Diffs from cvsspam
by David Kredba 10 Oct '04

10 Oct '04

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

5 4

RE: [ros-dev] Re: [ros-cvs] CVS Update: reactos
by PETREOLLE Sylvain 09 Oct '04

09 Oct '04

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. ----------------------------------------------------------------------------

1 0

Re: [ros-cvs] CVS Update: reactos
by James Tabor 09 Oct '04

09 Oct '04

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

1 1

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev October 2004