Ros-dev

ros-dev@reactos.org

5790 discussions

Compile error with DBG=1 and KDBG=0
by Sylvain Petreolle 23 Apr '05

23 Apr '05

Trying to compile ros trunk with config set to DBG=1 and KDBG=0, I get the following errors into ntoskrnl. Can someone help ? ke/i386/exp.o: In function `KeRosPrintAddress': /mnt/hdb5/reactos/reactos/ntoskrnl/ke/i386/exp.c:113: undefined reference to `_KdbSymPrintAddress' ex/dbgctrl.o: In function `NtSystemDebugControl': /mnt/hdb5/reactos/reactos/ntoskrnl/ex/dbgctrl.c:38: undefined reference to `_KdbSymLoadUserModuleSymbols' io/driver.o: In function `IoDestroyDriverList': /mnt/hdb5/reactos/reactos/ntoskrnl/io/driver.c:(.text+0x568): undefined reference to `_KdbSymProcessBootSymbols' io/driver.o: In function `IopInitializeBootDrivers': /mnt/hdb5/reactos/reactos/ntoskrnl/io/driver.c:1262: undefined reference to `_KdbSymProcessBootSymbols' io/driver.o: In function `IopInitializeBuiltinDriver': /mnt/hdb5/reactos/reactos/ntoskrnl/io/driver.c:(init+0x67c): undefined reference to `_KdbSymProcessBootSymbols' ldr/loader.o: In function `LdrUnloadModule': /mnt/hdb5/reactos/reactos/ntoskrnl/ldr/loader.c:404: undefined reference to `_KdbSymUnloadDriverSymbols' ldr/loader.o: In function `LdrLoadModule': /mnt/hdb5/reactos/reactos/ntoskrnl/ldr/loader.c:387: undefined reference to `_KdbSymLoadDriverSymbols' ldr/loader.o: In function `LdrUnloadModule': /mnt/hdb5/reactos/reactos/ntoskrnl/ldr/loader.c:422: undefined reference to `_KdbSymInit' Kind regards, Usurp (aka Sylvain Petreolle) humans are like computers, yesterday the BIOS was all - today its just a word

1 0

14725 breaks the bootcd and livecd
by WaxDragon 23 Apr '05

23 Apr '05

After these changes, both the livecd and bootcd hang qemu and cause vmware to stack fault and reboot. WD -- "<tinus_> and also win32k should be fixed up a bit"

4 5

thread lists
by Hartmut Birr 23 Apr '05

23 Apr '05

Hi, our current thread and process structures have two thread lists, one in KPROCESS/KTHREAD and another in EPROCESS/ETHREAD. Do we need both lists? - Hartmut

2 1

Re: [ros-svn] [hpoussin] 14749: Add Green driver, that emulates a VT100 compatible server.
by Alex Ionescu 23 Apr '05

23 Apr '05

hpoussin(a)svn.reactos.com wrote: >Add Green driver, that emulates a VT100 compatible server. >Input won't work as long as we don't have a kdbclass driver. > > > > Why don't you commit tinus' I8042PRT? Best regards, Alex Ionescu

2 1

Freeldr changes
by Ge van Geldorp 22 Apr '05

22 Apr '05

Art, The freeldr changes I just checked in more or less formalize the concepts of a boot volume/partition (containing freeldr.sys and freeldr.ini) and a system volume/partition (containing \ReactOS). Most of the time, the boot volume and system volume will be the same, but it's not required. The main freeldr code no longer knows anything about partitions, this is handled in the architecture-dependent functions now. The main code is given an opaque drive number and the sector number at which a partition/slice/volume starts. There are a number of new Mach functions: BOOL MachDiskGetBootVolume(PULONG DriveNumber, PULONGLONG StartSector, PULONGLONG SectorCount, int *FsType) which should return the boot DriveNumber (the main freeldr code just hands it back to MachDiskReadLogicalSectors when needed), the StartSector of the boot partition/slice/whatever, the SectorCount of the boot partition/slice/whatever and the FsType (FS_FAT, FS_EXT2 etc.). The i386 MachDiskGetBootVolume() uses the boot drive and boot partition passed in by the BIOS/boot sector to set the values, but the ppc implementation is ofcourse free to handle it in its own way. BOOL MachDiskGetSystemVolume(char *SystemPath, char *RemainingPath, PULONG Device, PULONG DriveNumber, PULONGLONG StartSector, PULONGLONG SectorCount, int *FsType) This routine takes a SystemPath, which for i386 is something like multi(0)disk(0)rdisk(0)partition(1)\ReactOS and finds the DriveNumber, StartSector, SectorCount and FsType from that. If RemainingPath is non-NULL, in this example it will return \ReactOS in it. Device can be NULL, if it's not the value appropriate for LoaderBlock.BootDevice will be returned there. The format of the SystemPath passed in is architecture-dependent. It's taken from freeldr.ini and passed on to MachDiskGetSystemVolume() by the main freeldr code without any attempt to interpret it. BOOL MachDiskGetBootPath(char *BootPath, unsigned Size) This constructs a system path for the boot volume. The i386 routine does this by referencing its internal i386BootDrive and i386BootPartition variables. VOID MachDiskGetBootDevice(PULONG BootDevice) Returns a suitable value for LoaderBlock.BootDevice for the boot volume. BOOL MachDiskBootingFromFloppy() Returns TRUE when booting from a low-capacity device. Gé van Geldorp.

2 1

Re: [ros-svn] [ion] 14742: Thread Creation and Context Switching re-write, plus Idle/First Thread minimization attempt. Full changelog on ML, too large to post here
by Alex Ionescu 22 Apr '05

22 Apr '05

ion(a)svn.reactos.com wrote: >Thread Creation and Context Switching re-write, plus Idle/First Thread minimization attempt. Full changelog on ML, too large to post here > > Main Differences in new Task Swithcer: - All written in Intel Syntax - Single file and function handles both cases of System and User thread switching and contexts. - Starting Frame creation during Thread Context Creation is now structure-based instead of a stack array. Cleaner to read and more explicative. - ExceptionList is properly set to -1 when needed. This should make PSEH 2 work. - Context switch routine now has ALL registers available to it, including EBP. - Context switch routine uses access to KPCR through a register, improving speed. - KPCR Stack Data properly updated during context switch. - KTSS CR3 properly updated during context switch. - LDT, CR3 and IOPM are only updated if the new thread's process is different, increasing speed for the simple path. - The LDT and TEB Selectors are written directly in the GDT, bypassing a complicated STDCALL routine which messed up registers and was slow. - Kthread.ContextSwitches is properly incremented now. - Kthread.State is properly set to Running now. The three goals were Speed, Clarity, Completeness. Other Differences: - Threads used to start either in PsBeginThread or PsBeginThreadWithContext. PsBeginThread would lower to passive and call the start routine with the start context, then terminate. PsBeginThreadWithContext also lowered irql, but then restored debug registers and used KiServiceExit to go to user-mode. A new function now exists called KiThreadStartup, based on NT's implementation (see Inside Windows 2000). It lowers IRQL to APC_LEVEL and then calls the System Routine, which is on the stack with the two parameters (StartRoutine and STartcontext). This System Routine ressembles PsBeginThread/PsBeginThreadWithContext. Depending on how the thread was created, it can either by PspSystemThreadStartup, which lowers IRQL to passive and then calls the StartRoutine. Or, it can be PspUserThreadStartup, which queues the User-Mode APC and inserts it, then lowers IRQL to passive and notifies the Debugger. Notice that the APC is now queued here, much later then before. After that, we return to KiThreadStartup, which will bugcheck if the system thread returned (it shouldn't), or will use KiServiceExit2, which does the same as the old ros, which is to restore the debug registers. IT then immediately does an IRET after cleaning the trap frame. Calling KiServiceExit is not correct because it might end up using SYSEXIT when clearly we weren't SYSENTERED. - Idle thread, first thread, first process and idle process are concepts which ROS gets really wrong. I have a patch which fixes these issues, but it is still heavily under testing. Until then, this patch also includes some changes which make the Idle/First Thread much less heavy, and are simple blocks of memory with the minimum amount of data possible to have a working system. They are not objects anymore, nor should they be. This isn't the final implementation but ressembles it and lays the minimal groundwork. - I will make a shorter patch-fix which will make Ki386InitializeThreadWithContext use the KeContextToTrapFrame function and complete it as well, in order to use only the fields which were specified by the caller. Best regards, Alex Ionescu

1 1

Re: [ros-svn] [fireball] 14730: Added xbox video driver information (by GvG), I hope it doesn't interfere anyone, and there will be no need to patch registry everytime to boot under xbox.
by Gge 22 Apr '05

22 Apr '05

fireball(a)svn.reactos.com wrote: > Added xbox video driver information (by GvG), I hope it doesn't interfere anyone, and there will be no need to patch registry everytime to boot under xbox. > > > Updated files: > trunk/reactos/bootdata/hivesys.inf > Is it possible to add also the nic realtek8139 and nvidia display driver informations as well for the same need ? Regards Gerard

1 0

RE: [ros-dev] 7-zip - holy smokes!
by Waldo Alvarez Cañizares 21 Apr '05

21 Apr '05

Hi: I doubt normal Windows users will be downloading sources of anything ever. BTW is a lot more dificult to set the build environment than to decompress the sources using 7zip. Beleiveme is a real pain to download ROS if you have a dialup connection. Why waste our time when we don't need to. Again if still you consider that a zip distribution should still be available for download why not distribute both zip and 7zip. Is that much space? Or it takes to much time to pack? I would answer no to both questions. Regards Waldo -----Original Message----- From: ros-dev-bounces(a)reactos.com on behalf of Andrew Flynn Sent: Thu 4/14/2005 4:28 AM To: ReactOS Development List Subject: Re: [ros-dev] 7-zip - holy smokes! I agree with Michael B. 7Zip is superior to ZIP. You have to remember who will be downloading the source, compressed files. Is it going to be standard windows users that use winzip and nothing else? When it comes to mass distribution of images, the iso format seems like a sensible choice, where the setup programs can utilise whatever compression they like. PKZip may be the most popular, but that does not mean that ReactOS files have to use it. Michael B. Trausch wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: RIPEMD160 > >Thomas Weidenmueller wrote: > > >>I don't think it's a good choice for our public downloads, the avarage >>user most likely will not know this format. zip still is THE standard. >> >> >> > >True, it is. However, end-users will follow whatever trends are set for >them. ZIP got to be big and well-known because of PKZip, honestly. > >If 7-Zip is that much better, then I'd say we go for it and put in >something like red text above the link to the downloads page that we use >7-Zip. > >Or, we could give users their option and offer both. Those concerned >about bandwidth would use the 7-Zip version, and those who don't care >can go with the other one. > >As far as users and .EXE files - End Users download EXE files all of the >time. They don't know any better. They see the box in MSIE and go, >"Yeah, whatever, it's my computer and I wanna download it," click it >away and move on. *shrugs* > >That's why I make money outside of my job, cleaning up after people's >idiotic mistakes, but that's another story altogether. If we offer them >a self-extracting version and a 7-Zip'd version, that'd be even better >in terms of download time/bandwidth. > >Not to mention, if 7-Zip can be distributed with ReactOS, it's a good >way to get it out there. Since it's under LGPL, it'd be something that >could even be built into ReactOS in the same way as .ZIP format support >is built into more recent versions of Windows (and hopefully, just as >easy to disable, because I hate that feature, but plenty of people >absolutely love it). > >Not only all of that, but since it's a superior compression scheme, it'd >be logical to support it and help further it's distribution so that >people would use it. People don't just sit down very frequently and go, >"Hrm. I think I am going to search out a new way to compress my files," >because they figure that compression is compression is compression, and >that's all there is to it. > >All in all, I think it'd be wise, especially over the long-term, to use >and support 7-Zip. > > - Mike > >- -- >Michael B. Trausch <fd0man(a)gmail.com> >Website: http://fd0man.chadeux.net/ Jabber: mtrausch(a)jabber.com >Phone: +1-(678)-522-7934 FAX (US Only): 1-866-806-4647 >=================================================================== >Do you have PGP or GPG? Key at pgp.mit.edu, Please Encrypt E-Mail! > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.1 (MingW32) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iD8DBQFCXcHQPXInbkqM7nwRA4D1AJ93vO8bTantG9QSWgtejVN0CotNiQCfe1rM >z6njCB0ucQYWNIAoofS9bD8= >=d5Zf >-----END PGP SIGNATURE----- >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-dev > > > > _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev

7 6

ReactOS Banner
by Jason Filby 19 Apr '05

19 Apr '05

Hi all I remember someone removed the 'User Site' from the ReactOS banner on our current site. Can that someone please send me the image, it seems people would like to see it on the new site design. Thanks Jason

2 1

problems about ros-diffs and viewcvs
by d_layer 19 Apr '05

19 Apr '05

Hello, Currently I'm experiencing two problems. Is there any plan to fix them? 1. ros-diffs list no longer delivers HTML mails. (since revision 14639) 2. Accessing to http://svn.reactos.com/viewcvs/ now requires an authentication. (I don't know exact date of occurrence) Thanks, -- d_layer

2 1

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