Ros-dev April 2005

ros-dev@reactos.org

62 participants
114 discussions

Crash at shutdown ( killing Explorer ) in current CVS

by Jan Schiefer

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I hit the start menue entry to kill explorer. I'm running this on QEMU 0.6.1. -user-net is enabled. Then this problem appeared. Just look at the screenshot. I just want to report that problem. Greetings, Jan Schiefer! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCa4SYzC00UKXFdVcRAi8vAKCwVQKvLbisZ2P9qz+TFv5qzf+R0QCfbmwa 2+fVvDWgGnGWGeQ7u/TYkFA= =ow9s -----END PGP SIGNATURE-----

19 years, 8 months

Kernel System Page Table

by Alex Ionescu

Hi Hartmut & Mm Experts, It seems that on ROS, every process has its own Page Table for the Kernel Area/System Table. This needs to be updated with MmUpdatePageDir all the time, and creates a bunch of annoyances in the Context Switching code too (for example, I can't check the trap frame for VM_MASK because at that time the Page Directory hasn't been changed yet. I could change it before but that would screw up the optimizations. Philip Susi and I have researched this and arrived to the common conclusion that every new Process's Page Table should share the same System Page Table. I'm not an expert so maybe I'm not explaining it properly, but the System Page Table shouldn't have to be "inserted/mapped" into every Process's Page Table, it should already be there, shared amongst all processes. I hope that made sense...if not, maybe Philip can fix up my explenation. Is it possible for any of the Mm guys to implement this properly? Thanks a lot.. Best regards, Alex Ionescu

19 years, 8 months

Compile error with DBG=1 and KDBG=0

by Sylvain Petreolle

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

19 years, 8 months

14725 breaks the bootcd and livecd

by WaxDragon

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"

19 years, 8 months

thread lists

by Hartmut Birr

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

19 years, 8 months

Re: [ros-svn] [hpoussin] 14749: Add Green driver, that emulates a VT100 compatible server.

by Alex Ionescu

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

19 years, 8 months

Freeldr changes

by Ge van Geldorp

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.

19 years, 8 months

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

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

19 years, 8 months

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

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

19 years, 8 months

RE: [ros-dev] 7-zip - holy smokes!

by Waldo Alvarez Cañizares

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

19 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev April 2005