Ros-dev

ros-dev@reactos.org

5788 discussions

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

ReactOS Banner

by Jason Filby

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

19 years, 8 months

problems about ros-diffs and viewcvs

by d_layer

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

19 years, 8 months

Broken!

by James Tabor

Hi, (NTDLL:ldr/utils.c:2039) Failed to create or open dll section of '\??\C:\ReactOS \system32\csrss.exe' (Status c0000135) Unhandled exception Address: 7c924078 C:\ReactOS\system32\ntdll.dll CS:EIP 1b:7c924078 DS 23 ES 23 FS 3b GS 23 EAX: 00a08139 EBX: 008f6500 ECX: 00000004 EDX: 00007269 EBP: 0055d96c ESI: 77a94000 ESP: 0055d964 EDI: 00a08139 EFLAGS: 00010202 Frames: 77a90000+1454 C:\ReactOS\system32\VERSION.dll 77a90000+148d C:\ReactOS\system32\VERSION.dll 400000+115d C:\ReactOS\tools\listdlls.EXE (toolbar.c:411:TOOLBAR_GetImageListForDrawing) bitmap for ID 0, index 1 is not v alid, number of bitmaps in imagelist: 0 (NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 750000) C:\ReactOS\system32\gdi 32.dll (rpcrt4_main.c:156:DllMain) Failed to create master mutex (ps/cid.c:119) CID Obj type mismatch handle 0x4 Thread vs 0x1 mm/mm.c:338 Unhandled exception Address: 4018bf C:\ReactOS\bin\ps.EXE CS:EIP 1b:4018bf DS 23 ES 23 FS 3b GS 23 EAX: 00651aa0 EBX: 0042e000 ECX: 00651938 EDX: 00651b8c EBP: 0064ff88 ESI: 00000000 ESP: 0064fcd0 EDI: 0064fd1e EFLAGS: 00010216 Frames: 400000+11e7 C:\ReactOS\bin\ps.EXE 400000+1238 C:\ReactOS\bin\ps.EXE 7c800000+2876f C:\ReactOS\system32\kernel32.dll Listdll and ps both work with XP so??? What is wrong with ROS? James

19 years, 8 months

RosApps CTM Broken

by James Tabor

Hi, Need to check this one too. make[1]: Entering directory `/home/ros/rosapps/sysutils/ctm' ctm: [CC] ctm.c ctm.c: In function `PerfDataRefresh': ctm.c:356: error: `PSYSTEM_PROCESSES' undeclared (first use in this function) ctm.c:356: error: (Each undeclared identifier is reported only once ctm.c:356: error: for each function it appears in.) ctm.c:356: error: syntax error before "pSPI" ctm.c:361: error: `PSYSTEM_PROCESSORTIME_INFO' undeclared (first use in this function) ctm.c:361: error: syntax error before "SysProcessorTimeInfo" ctm.c:377: error: `SysProcessorTimeInfo' undeclared (first use in this function) ctm.c:377: error: syntax error before "malloc" ctm.c:378: error: `SYSTEM_PROCESSORTIME_INFO' undeclared (first use in this function) ctm.c:382: error: syntax error before ')' token ctm.c:419: error: `pSPI' undeclared (first use in this function) ctm.c:419: error: syntax error before "pBuffer" ctm.c:431: error: syntax error before "pBuffer" make[1]: *** [ctm.o] Error 1 make[1]: Leaving directory `/home/ros/rosapps/sysutils/ctm' James

19 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev