Ros-dev

ros-dev@reactos.org

5791 discussions

ReactOS scripts (to make life easy) ;)
by Francisco TLF 17 Oct '04

17 Oct '04

Hi. I made some modifications on scripts to compile ReactOS (on linux, but I don't know if they works in some other plattform). You can check it at: http://telefrancisco.iespana.es/telefrancisco/linux/reactos/ Best regards. ______________________________________________________ Get Paid... With Your Free Email at http://www.zwallet.com/index.html?user=telefrancisco

1 0

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

17 Oct '04

Hartmut Birr wrote: >CVSROOT: /CVS/ReactOS >Module name: reactos >Repository: reactos/ntoskrnl/include/internal/i386/ >Changes by: hbirr(a)mok.osexperts.com 04/10/17 03:53:08 > >Modified files: > reactos/ntoskrnl/include/internal/i386/: ps.h > >Log message: > - Fixed the definition KPCR_SELF and KeGetCurrentKPCR. > >_______________________________________________ >Ros-cvs mailing list >Ros-cvs(a)reactos.com >http://reactos.com/mailman/listinfo/ros-cvs > > > Is that really right? I can swear fs:18h was still used until NT 5.2. Also, it would be of critical importance to: 1) Change the hardcoded offsets to FIELD_OFFSET(...,...) 2) Make the ASM use the defines instead of hardcoding 1Ch/18h Best regards, Alex Ionescu

2 2

Crash in ExWorkerThreadEntryPoint
by Hartmut Birr 16 Oct '04

16 Oct '04

Hi, sometimes I get a crash in ExWorkerThreadEntryPoint/ExInterlockedRemoveHeadList. I've checked all calls to ExQueueWorkItem. It seems that something is wrong in the tcpip/ndis driver. There is a timer dpc which calls ExQueueWorkItem with a static work queue item. If the worker is not execute previous the next timer call, the item is queued for twice. Possible it is the same bug as #425. - Hartmut

1 0

INACCESSIBLE_BOOT_DEVICE
by Enrico Bartky 16 Oct '04

16 Oct '04

Hello, I have attached the error, ....

1 0

INACCESSIBLE_BOOT_DEVICE
by Enrico Bartky 15 Oct '04

15 Oct '04

Hello, if I start the ReactOS Setup from the "make bootcd" I get an INACCESSIBLE_BOOT_DEVICE. I use the CVS Version of ReactOS. Can you help? Thanx, EnricoB

3 4

Memory Leak
by James Tabor 15 Oct '04

15 Oct '04

Hi all, Still running the same kernel and subsystem (see previous post) now for 1 day 5:23 (uptime). System memory is 1.1 GBytes. First build ros on ros started at 5% use of memory. Now after the uptime, 45% after third build. New start has it at 24%. Slow leak~ I did not enable the memory dumps 8^(, So no real data there. The slow action on the cmd win console has not changed, you can still count the chars displaying across the screen. FYI, James

1 0

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

Jump to page:

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