- Ros-dev - ReactOS.org

by Colin Finck

Hello everybody, Just to let you know, I've just added HTTP/WebDAV access for our read-only Git mirror as requested by a developer. This means that you can also clone from http://git.reactos.org/reactos.git now if you sit behind a firewall blocking the Git protocol. Of course, the previous URL git://git.reactos.org/reactos.git will continue to work. Best regards, Colin

14 years, 10 months

2
2
0 0

platform dependent configuration files

by Matthias Kupfer

HI, recently I had to alter some inf-files for fixing a bug. At present we have for each platform (i386, arm, amd64) separate files, which are hard to maintain because of some identical, that aren't platform dependent. Therefore I suggest the following change and I will write an example and the necessary tool: - combine all platforms to one file and work with special block markers - block markers work like filters, empty markers means all platforms otherwise the platforms limited to are given in comma separated lists - we have to maintain only one single file and the alteration is minimal, because the marker is a simple (syntactically comment) line like ";#platform_a,platform_b#" or ";##" - the needed file is extracted at build time, always up-to-date and shipped in the same way as present General remark: we have to make some efforts to bring (or at least to keep) the project in understandable and maintanable state. We have to use and introduce tools to reduce needless efforts resulted by managing multiple similar files which could be better generated without failures (that people tends to do). This and only this is my intention for this suggestion. Request for comments - other ways or changes with same goal are welcome Matthias -- Matthias Kupfer phone +49 371 236 46 52 Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54 09122 Chemnitz, Germany

14 years, 10 months

2
1
0 0

OpenSource World Conference-Malaga(Spain)

by victor martinez

Hi guys/devs/testers/translators/followers ! I have just received this information from the OSWC organization: "Nos complace comunicarle que su propuesta presentada al Call for Paper ha sido aprobada de forma preliminar por el Comité de Ponencias de la Conferencia Internacional de Software Libre para su comunicación pública. Actualmente el programa de la Conferencia se encuentra en una fase temprana de elaboración, por ello solicitamos de usted nos comunique antes del próximo día 28 de septiembre de 2010, su disponibilidad para estar en Málaga tanto el día 27 de octubre, el 28 o ambos. Agradecemos su dedicación e interés y esperamos disfrutar de su compañía en Málaga Atentamente " You can use Google translator. Or summing up: "We are IN" Thanks to anyone who has voted and wish me good luck :) If anyone is interested about coming, please contact me before 28 September (there is one day just for professionals and closed to the general public) :) Victor Martinez "

14 years, 10 months

2
2
0 0

Re: [ros-dev] 0.3.12 milestones status

by victor martinez

> From: gedmurphy(a)gmail.com > To: ros-dev(a)reactos.org > Date: Thu, 23 Sep 2010 08:09:57 +0100 > Subject: Re: [ros-dev] 0.3.12 milestones status > > victor Martinez wrote: > > > In the same way, and imho, I think it is much better > > to avoid sending critical code one month before the release. > > This isn't how you release. > The whole point in branching for a release is so you can stabalise the > branch whilst trunk continues to be 'bleeding edge' > What's the point in branching otherwise? We may as well just tag trunk and > do away with branching. I am not agree :) As far as i see we have tried to (more or less)stabilize trunk before branching at least in the 2 latest releases. An i.e is the 0.3.12 release, if we are following the "bleeding edge" concept then we should have branched several months ago and just pulled the regression fixes from trunk to the branch. Our approach was different: Stabilizing trunk fixing the known regressions (which,btw,were marked as Milestones) and then branching. There is not an incompatibility with the "stabilizing trunk" and "branching" concepts. First because exists the "Hack-releases" (fixes just applied for the release) and that just can be done in a branch. Second because a (more or less) stabilized trunk doesn't mean a regression-free trunk (but it could be). The first main advantage (about avoid sending critical code in the month we are going to release) is that we will have a whole month to check if the critical changes has waken up underlying bugs (or if the critical changes has introduced Eisenbugs).If we are following the "bleeding edge" approach we can just pray to find those Eisenbugs in the Release Candidate ISO tests and, since there aren't a lot of testers checking the RC ISO, it is quite unprovable. The second main advantage is that we reduce the Release Engineers amount of work. It is not the same bugging them to create just one RC ISO than bugging them to create 2 or 3 because playing with the "bleeding edge" concept.

14 years, 10 months

4
4
0 0

Re: [ros-dev] 0.3.12 milestones status

by victor martinez

> > I am not agree :) As far as i see we have tried to (more or less) > > stabilize trunk before branching at least in the 2 latest releases. > This is because trunk has been in a mess for the past few releases. > Due to its instability it wasn't worth branching it as it was so far from > being releasable. > In the past we had (strived for) a 2 month release cycle. > We branched every 2 months no matter what and then worked on getting that > release out. > This is how linux and most other serious open source projects work. It's all > about discipline. "About discipline" and about having a lot of developers which can cover all the needs a project has. ;) And let me not talk about some "serious open source pojects" with tons developers/users which has introduced and released with critical regressions. > > There is not an incompatibility with the "stabilizing trunk" and > > "branching" concepts. First because exists the "Hack-releases" (fixes > > just applied for the release) and that just can be done in a branch. > > Second because a (more or less) stabilized trunk doesn't mean a > > regression-free trunk (but it could be). > This is exactly what it's for. Branch, fix bugs or hack bugs away. > Merge real bug fixes back into trunk, tag and release. Sure, I was just answering to your "What's the point in branching otherwise?" which seemed to be a question about an incompatibility with "avoiding critical commits" and "stabilizing trunk" before branching. > > The first main advantage (about avoid sending critical code in the > > month we are going to release) is that we will have a whole month to check > > if the critical changes has waken up underlying bugs > > This is the ongoing job of the testers to do both in trunk and more > importantly, in release branch. > If any serious bugs are found late in the process, drop the branch, fix in > trunk and rebranch. Just 2 words: Im-possible. :) You need a testing time frame. There is something called "Probability" of finding a regression(even more finding an eisenbug). If you branch right after a critical commit and that critical commit has introduced a regression you have much less "Probability" to find it that if the last critical commit was made 1 month ago. Even more, Release Candidates are mainly just tested by the Testers. So finding the regression depends mainly on "Probability Testers find a regression in one week" But during that Quarantine month other commits (non critical ones) can be sent and developers can feel/find regressions too. So finding the regressions would depend mainly on "Probability Testers and Devs find a regression in one month". Notice that the testing group is wider and so the time. We don't have Testing manpower to find a regression the next day/week it was commited. > > The second main advantage is that we reduce the Release Engineers amount of work. > But you hamper development. Locking down trunk for a month before every > release is a sure way to drive away all of your developers. > I would refuse to work on a project which worked in this way, as would most > other devs I assume. Who talked about freezing trunk? I should define 1-month Quarantine better: "Avoid commiting to critical areas. The trunk is open for those non-critical ones. You can send meanwhile your critical patches to a branch and after the release pushing them to trunk.". You have a ReactOS branch if needed. > If you're finding when release time comes that no devs work on fixing the > release branch and instead continue adding new code to trunk, then you have > a developer discipline issue not a release process issue. If we pay our developers we can ask for discipline meanwhile we can just accept their patches or refuse them. Will you refuse a Patch? Or maybe revoke a Dev commit access to create discipline? Any useful ideas? > Locking trunk is just a way to work around your developer discipline problem > instead of tackling the real problem, your devs can't be bothered to fix > existing code and continue to ignore their duties and add new code instead. Noone talked about Locking Trunk, and there are no duties. IIRC you were the first person that explained me why there are no dutie$ in this project. > Ged. Vic

14 years, 10 months

2
1
0 0

Trunk freeze

by Aleksey Bragin

Hello, 0.3.12 was branched today, so I removed the lock from trunk. However, I want to really ask everyone not to jump into modern fancy features but pay more attention to fixing core parts of the system. Victor is doing the change log draft, and if Colin has time I would like to ask him to apply our usual release stuff. WBR, Aleksey Bragin.

14 years, 10 months

1
0
0 0

0.3.12 Changelog Sum up.

by victor martinez

You have done a pretty cool work. 0.3.12 Changelog is opened, I have added a "Regression", "General Bugs" section where i reflect the Bugs fixed from 0.3.11 to 0.3.12. This is a little bit more user-friendly. You can find it here: http://www.reactos.org/wiki/ChangeLog-0.3.12#General The Bugzilla stats shows the next: - There were 259 General Bugs fixed (Regressions fixed are not counted here) - There were 20 Translations sent in 11 different Languages. - And you fixed 61 Regressions So more than 320 bugs has been fixed in less than 300 days. (Without counting Bugfixes in branch) You have killed more than 10 bugs older than 3 years old. And the eldest one is "#969 Minimized windows are shown on desktop" which is 5 years old. Congratz :)

14 years, 10 months

1
0
0 0

Debug Build is Broken

by James Tabor

[CC] dll/win32/kernel32/file/file.c cc1: warnings being treated as errors dll/win32/kernel32/file/dir.c:21: error: 'gDebugChannel' defined but not used make: *** [/mnt/ramdisk/buildbot/release/obj/dll/win32/kernel32/file/dir_kernel32.o] Error 1 make: *** Waiting for unfinished jobs....

14 years, 10 months

2
2
0 0

Unable to use FreeLDR

by Ros Arm

Hello, After the switch in 48124 to PE FreeLDR, I am unable to boot FreeLDR any longer. I have tried official, as well as various unofficial freeldr.sys, none worked. 47892 version works fine, 48124 does not. On a 512MB IDE disk, I got the "_" VGA cursor scrolling endlessly/randomly on the screen, before even seeing "Loading FreeLDR..." With a 1GB SCSI disk, tested also with a 6GB IDE disk, it remains stuck at "Loading FreeLDR...". This seems strange: "Now booting from fat partitions (looks like that's what sysreg does) works again. It's safe under the condition that the cluster size is at least 4352 bytes, which is true for harddisks of sizes bigger than 272MB. Booting from smaller fat disks, like floppy breaks when freeldr.sys gets fragmented, which should rarely happen." Please advise. -r

14 years, 10 months

3
7
0 0

Re: [ros-dev] [ros-diffs] [sir_richard] 48825: [MISC]: Fix several compiler issues on my main build box. Some of the Unicode translations in kernel32 fail to compile, while other libraries don't build because old C library ...

by Aleksey Bragin

On Sep 20, 2010, at 10:30 AM, sir_richard(a)svn.reactos.org wrote: > Author: sir_richard > Date: Mon Sep 20 06:30:21 2010 > New Revision: 48825 > + <define name="lseek">_lseek</define> > + <define name="read">_read</define> Please use TABs in .rbuild files for indentation. Thanks, Aleksey Bragin.

14 years, 10 months

1
0
0 0

pefixup doesnot set IMAGE_SCN_MEM_NOT_PAGED for .rdata WDM section

by Pavel Pisa

Hello all, I have noticed, that pxefixup does not set IMAGE_SCN_MEM_NOT_PAGED flag for read-only data section ".rdata". May it be, that it is problem for my own build of tools 586-mingw32-gcc (GCC) 4.4.2 and GNU ld (GNU Binutils) 2.20.51.20100608 I have fixed the problem by preparing modified LD script version which collect object files .rdata section into .text section for my driver build. But .rdata is legitimate section and it is automatically generated by GCC. I have not found information in Wiki or list archives, that there is some way/patch to deal with this situation. But if it is allowed, that WDM driver binaries contains readonly section then data paging could lead to horrible consequences. Possible fix diff --git a/reactos/tools/pefixup.c b/reactos/tools/pefixup.c index f908a9a..d6ec1f4 100644 --- a/reactos/tools/pefixup.c +++ b/reactos/tools/pefixup.c @@ -381,6 +381,7 @@ int main(int argc, char **argv) if (!strcmp((char*)section_header->Name, ".text") || !strcmp((char*)section_header->Name, ".data") || !strcmp((char*)section_header->Name, ".idata") || + !strcmp((char*)section_header->Name, ".rdata") || !strcmp((char*)section_header->Name, ".bss")) { section_header->Characteristics |= htodl(IMAGE_SCN_MEM_NOT_PAGED); If .rdata are not allowed or should be used only for pseudo_reloc, then the ldscript for kernel code should be provided. Missing flag for .rdata section in objdump ouput $ i586-mingw32-objdump --headers ul_wdm.sys BFD: ul_wdm.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .text BFD: ul_wdm.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .data BFD: ul_wdm.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .bss BFD: ul_wdm.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .idata ul_wdm.sys: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0000cabc 00011000 00011000 00001000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 000000e8 0001e000 0001e000 0000e000 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .rdata 00003c20 0001f000 0001f000 0000f000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .bss 00000050 00023000 00023000 00000000 2**2 ALLOC 4 .edata 00000033 00024000 00024000 00013000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .idata 000008c4 00025000 00025000 00014000 2**2 CONTENTS, ALLOC, LOAD, DATA 6 .rsrc 0000035c 00026000 00026000 00015000 2**2 CONTENTS, ALLOC, LOAD, DATA 7 .reloc 00000cd4 00027000 00027000 00016000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .rossym 0001576d 00028000 00028000 00017000 2**2 CONTENTS, READONLY, NEVER_LOAD, EXCLUDE

14 years, 10 months

2
2
0 0

reactos in lguest

by Enrico Weigelt

Hi folks, did anyone already do some research on whether ReactOS could run in lguest ? Maybe this could be a nice for development/debugging and attracting more people ;-) cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt(a)metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------

14 years, 10 months

5
6
0 0

0.3.12 TODO list

by Olaf Siejka

As we progress into regression fixing, we are now in the good moment to decide upon upcoming release. It would be great if we could manage with the 0.3.12 for the October Chemnitz event, where we are invited again to participate, not to mention that its the time for such release. Right now, in my opinion we should decide without futher delay on the following: - reviewing the REGRESSION list, this is - to confirm entries with 0.3.12 milestone already set, as well as doublecheck the rest, to see if any should be promoted to said milestone. This is the action of most utter importance, as there is no way to know how much time will be spent on futher research, testing and fixing them; - decide upon bugs originated with last ole/comctl sync - are we haxing them locally, risking another winesync or perhaps reverting? - reviewing patches stored at http://www.reactos.org/wiki/Bug_Filters as well as deciding if any should be adapted for current release. Those actions, first of them especially, should be performed as swift as possible, else we might risk considerable delay and nervous finish before the Chemnitz.

14 years, 10 months

5
6
0 0

ASSERT while shutting down ReactOS with VirtualBox Guest Additions installed

by Javier Agustìn Fernàndez Arroyo

hello, this is to sir_richard, mostly, i got this crash (assert) when shutting down ReactOS with the VirtualBox Guest Additions installed. i think the video driver is guilty for some reason i cannot understand... probably you know :) http://www.reactos.org/paste/index.php/7731/

14 years, 10 months

6
13
0 0

uLan USB driver for ReactOS - query for help if possible

by Pavel Pisa

Hello to all ReactOS developers, thanks for great work. I introduce our case first. -------------------------------------------------------------------- We have developed, maintain and use uLan RS-485 multi-master protocol for years - sources traced to 1992 year. The protocol is used by multiple companies and individuals for broad range of applications from laboratory instruments control, home automation to agriculture feeding and milking systems. We started by Linux support. But due to customers demand, we have added Windows KDM and later WDM support as well. I remember, that pointer to our driver has been mentioned as one of little fully open-source drivers available for Windows on ReactOS list many many years ago. The uLan project homepage http://ulan.sourceforge.net/ The uLan driver code can be compiled for Linux, Windows NT KDM, Win98/2k/Vista WDM, plain DOS, system-less ARM and other devices. The old legacy UART, PCI addon cards and USB converters are supported for Linux and WDM version. All builds form same sources with unification layer of macros which unifies systems to something more close to Linux driver model. The code is not so elegant and readable, the portability layers are quite complex and sometimes hairy tasks. The traces of old age of project can be seen there as well. But it works and may it be, it could be some example and source of helpers functions for porting of Linux USB drivers to WDM model. The ReactOS has got to the stage where it is able to run one of our user applications utilizing our control protocol link. Because I believe in open technologies, I would be very happy if the project is usable even on RectOS - even that I do not expect that our users could and want to switch anytime soon or ever. The Open Chromatography Station - CHROMuLAN http://sourceforge.net/projects/chromulan/ If you think that it worth, it can be added to the list of applications working with ReactOS 0.4-git/svn. -------------------------------------------------------------------- As for the uLan driver. I have maneged it build for WDF with PCI and UART support only to run on ReactOS and whole CHROMuLAN setup seems to be functional. I have even interrest to build driver code with ReactOS to test it more, find incompatibilities and continue with 64-bit testing in future. The effort seems to be not so far form success. The driver builds with RectOS build under Linux when USB support is disabled. The build with USB seems to be near as well. There are two main problems: 1) We need to include usbdlib.h in the driver build, but DECLSPEC_EXPORT in this header is not declared/maintained. We use this file for next types declaration USBD_INTERFACE_LIST_ENTRY PUSBD_INTERFACE_LIST_ENTRY struct _USBD_INTERFACE_LIST_ENTRY' May it be, we should use different include headers, but next setup works for years with Microsoft WDF #include "wdm.h" #include "usbdi.h" #include "usbdlib.h" 2) If we overcome by some hack problem 1) the link fails on undefined references to __imp__USBD_ParseConfigurationDescriptorEx@28 __imp__USBD_CreateConfigurationRequestEx@8 There seems to be traces of implementation of these functions in ReactOS old/disabled USB code. The functions are even included in usbd.sys, usbd.exp and drivers/usb/usbd . But import library seems to be missing. Am I right? Is there way to use them or plan to solve that. Thanks for reply in advance. Even that we do not much expect to use ReactOS build in production environment the option has value for us. It allows to test Windows builds in Linux environment without need to start Wine for WDF. ReactOS build even helped us to find some real bugs in our code because rectos runtime is more strict in some checks then Windows systems. Please, keep my email addres in reply, I do not expect (have ability) to follow ReactOS development closely between my other duties. It is unfortunate a little, that only way to contact developers on the list is to subscribe. Best wishes, Pavel -- Pavel Pisa e-mail: pisa(a)cmp.felk.cvut.cz www: http://cmp.felk.cvut.cz/~pisa university: http://dce.fel.cvut.cz/ company: http://www.pikron.com/

14 years, 10 months

4
4
0 0

From what to start?

by Captain Sandro

What can you advice me to start from? Which module needed in programming? And which tools and methods are used for writing code?

14 years, 10 months

3
2
0 0

Errata

by Olaf Siejka

Altough i mentioned Chemitz, it should be of course OpenSource World Conference in Spain. Sorry

14 years, 10 months

1
0
0 0

Windows & ReactOS installed simultaneously

by Javier Agustìn Fernàndez Arroyo

Hello devs, Few users at spanish ReactOS blog ( http://reactos.wordpress.com ) are asking about having both Windows and ReactOS installed in different partitions at the same time... And i wanted you to answer, rather than me... :P What would you say? Is it currently possible?

14 years, 10 months

7
10
0 0

A room for improvement?

by Pierre Schweitzer

Hi, while working on GPT handling for ReactOS, one thing appeared: Microsoft (at least in Windows 2003 SP1) is using hardcoded partition entry size, ie it assumes that every partition entry in GPT will be 128 bytes big. Even if that assertion is largely right, it might exist cases where it's wrong. That's even why there's a field in GPT header that contains such size. Furthermore, reading Apple technical note(1) about GPT precise one more thing: "Do not hardwire the current size of the partition entry (128 bytes).". As we have no commercial issues with Apple, perhaps could we drop a bit compatibility with Windows 2003 and fix something obvious? In most cases, users won't see any difference. Only difference would be that ReactOS could properly handle GPT with exotic partition entry size when Windows can't. Any opinion on that subject? Best regards, P. Schweitzer (1): http://developer.apple.com/library/mac/#technotes/tn2006/tn2166.html

14 years, 10 months

2
2
0 0

48748 "Goodbye" Confusion

by Ros Arm

Hello, eVb checked in one of his final patches yesterday from his development machine in China, where we worked on a final pass on the driver. Unfortunately, my last two (unrelated) check ins were done from his machine (as most of you know, I was in China for the past month), and he was not used to SVN caching the credentials of the last user. Revision 48748 was a checkin from eVb, and his "goodbye" was in reference to my departure. Since it used my cached credentials from the same machine, it must've caused a lot of confusion. Many apologies and thanks for understanding. -r

14 years, 10 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [fireball] 48745: [NTOS] - Daniel Zimmermann: Fix POPF bugs in VDM mode, namely truncation of the stackpointer to 16 bit and setting proper flags in the trapframe eflags register. This fixes proble...

by Timo Kreuzer

fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Sat Sep 11 09:20:26 2010 > New Revision: 48745 > ... > /* Save EFlags */ > + Esp -= 4; > + *(PULONG)(Esp - 2) = V86EFlags; > This looks wrong to me. The (Esp - 2) I mean. > + if (KiVdmGetPrefixFlags(Flags) & PFX_FLAG_OPER32) > + { > + /* Read EFlags */ > + EFlags = *(PULONG)Esp; > + Esp += 4; > + } > + else > + { > + /* Read EFlags */ > + EFlags = *(PUSHORT)Esp; > + Esp += 2; > /* Read correct flags and use correct stack address */ > - Esp -= 2; > EFlags &= 0xFFFF; > Here the comment got broken a bit. > /* Set new ESP */ > - TrapFrame->HardwareEsp = Esp; > + TrapFrame->HardwareEsp = (USHORT)Esp; > This is not correct. We earlier calculated the flat Esp from Ss and Sp. Example: HardwareSegSs = 0x10, HardwareEsp = 0x10 -> flat Esp = 0x110, then you substract 4, and get 0x10C. But this is not the value of the new HardwareEsp. TrapFrame->HardwareEsp needs to be either modified in parallel to the flat Esp or calculated like (USHORT)(Esp - (TrapFrame->HardwareSegSs << 4)). Regards, Timo

14 years, 10 months

1
0
0 0

Pacth: Freeldr disk geometry bug

by Eric Kohl

Hi! This patch fixes the disk geometry bug I mentioned in my previous mail. It enables disk.sys and usetup.exe to use the same disk geometry that is used by the BIOS. Due to another bug or workaround in the 1st stage setup, the 2nd stage setup will not boot at all. Regards, Eric Index: boot/freeldr/freeldr/arch/i386/hardware.c =================================================================== --- boot/freeldr/freeldr/arch/i386/hardware.c (revision 48722) +++ boot/freeldr/freeldr/arch/i386/hardware.c (working copy) @@ -327,7 +327,6 @@ { PCM_PARTIAL_RESOURCE_LIST PartialResourceList; PCM_DISK_GEOMETRY_DEVICE_DATA DiskGeometry; - EXTENDED_GEOMETRY ExtGeometry; GEOMETRY Geometry; ULONG Size; @@ -362,16 +361,8 @@ DiskGeometry = (PVOID)(((ULONG_PTR)PartialResourceList) + sizeof(CM_PARTIAL_RESOURCE_LIST)); /* Get the disk geometry */ - ExtGeometry.Size = sizeof(EXTENDED_GEOMETRY); - if (DiskGetExtendedDriveParameters(DriveNumber, &ExtGeometry, ExtGeometry.Size)) + if(MachDiskGetDriveGeometry(DriveNumber, &Geometry)) { - DiskGeometry->BytesPerSector = ExtGeometry.BytesPerSector; - DiskGeometry->NumberOfCylinders = ExtGeometry.Cylinders; - DiskGeometry->SectorsPerTrack = ExtGeometry.SectorsPerTrack; - DiskGeometry->NumberOfHeads = ExtGeometry.Heads; - } - else if(MachDiskGetDriveGeometry(DriveNumber, &Geometry)) - { DiskGeometry->BytesPerSector = Geometry.BytesPerSector; DiskGeometry->NumberOfCylinders = Geometry.Cylinders; DiskGeometry->SectorsPerTrack = Geometry.Sectors; Index: boot/freeldr/freeldr/arch/i386/pcdisk.c =================================================================== --- boot/freeldr/freeldr/arch/i386/pcdisk.c (revision 48722) +++ boot/freeldr/freeldr/arch/i386/pcdisk.c (working copy) @@ -296,12 +296,25 @@ BOOLEAN PcDiskGetDriveGeometry(ULONG DriveNumber, PGEOMETRY Geometry) { + EXTENDED_GEOMETRY ExtGeometry; REGS RegsIn; REGS RegsOut; ULONG Cylinders; DPRINTM(DPRINT_DISK, "DiskGetDriveGeometry()\n"); + /* Try to get the extended geometry first */ + ExtGeometry.Size = sizeof(EXTENDED_GEOMETRY); + if (DiskGetExtendedDriveParameters(DriveNumber, &ExtGeometry, ExtGeometry.Size)) + { + Geometry->Cylinders = ExtGeometry.Cylinders; + Geometry->Heads = ExtGeometry.Heads; + Geometry->Sectors = ExtGeometry.SectorsPerTrack; + Geometry->BytesPerSector = ExtGeometry.BytesPerSector; + + return TRUE; + } + /* BIOS Int 13h, function 08h - Get drive parameters * AH = 08h * DL = drive (bit 7 set for hard disk)

14 years, 10 months

5
8
0 0

Severe bug found: Freeldr passes wrong disk geometry to ntoskrnl.exe and disk.sys

by Eric Kohl

Hi! I just found a severe bug in hardware detection code of Freeldr. It uses two configuration nodes in the hardware tree to pass information about detected hard-disks to ntoskrnl.exe and disk.sys. First, hard-disk information is passed as a DiskPeripheral node attached to a DiskController node. Second, hard-disk information is passed as an array of CM_INT13_DRIVE_PARAMETER entries in a special system configuration node, if the disks were detected by the BIOS. As part of the boot process, the special system configuration node is used by disk.sys to determine the disk geometry used by the BIOS. Unfortunately, this configuration node did not use the extended disk geometry (LBA geometry) but the old CHS geometry even if the LBA geometry was available. I already fixed this bug in my local source tree and suddenly Freeldr, disk.sys and usetup.exe report exactly the same disk geometry as gparted (http://gparted.sourceforge.net/download.php). Unfortunately, using this patch breaks the 2nd stage setup. I will provide a patch that fixes the Freeldr issue as soon as I have cleaned up the source tree. Please help me find the remaining bug or workaround that keeps ReactOS from booting into 2nd stage setup! I guess it is either part of usetup or somewhere in the partition management routines. Regards, Eric

14 years, 10 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [akhaldi] 48687: [FREELDR] - Convert fat12/16 boot sector helper code to gas syntax. Brought to you by the Arty. [CMAKE] - Add freeldr and setupldr to build.

by Alex Ionescu

This is retarded, GAS supports Intel syntax. Why did this require rewriting everything in AT&T syntax and introducing bugs? And what's up with calling AT&T syntax "GAS" Syntax. I wonder what Brian would say.... It's funny how this project gets rid of old developers, gets new developers, and has them make the same mistakes/idiotic things the old developers left for in the first place... Good job! Best regards, Alex Ionescu On Thu, Sep 2, 2010 at 10:39 AM, <akhaldi(a)svn.reactos.org> wrote: > Author: akhaldi > Date: Thu Sep 2 17:39:45 2010 > New Revision: 48687 > > URL: http://svn.reactos.org/svn/reactos?rev=48687&view=rev > Log: > [FREELDR] > - Convert fat12/16 boot sector helper code to gas syntax. Brought to you by the Arty. > [CMAKE] > - Add freeldr and setupldr to build. > > Added: > branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.S > - copied, changed from r48568, branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm > Removed: > branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm > Modified: > branches/cmake-bringup/boot/CMakeLists.txt > > Modified: branches/cmake-bringup/boot/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/branches/cmake-bringup/boot/CMakeLists.t… > ============================================================================== > --- branches/cmake-bringup/boot/CMakeLists.txt [iso-8859-1] (original) > +++ branches/cmake-bringup/boot/CMakeLists.txt [iso-8859-1] Thu Sep 2 17:39:45 2010 > @@ -5,3 +5,203 @@ > CreateBootSectorTarget(fat ${CMAKE_CURRENT_SOURCE_DIR}/freeldr/bootsect/fat.asm ${CMAKE_CURRENT_BINARY_DIR}/freeldr/bootsect/fat.bin) > CreateBootSectorTarget(isoboot ${CMAKE_CURRENT_SOURCE_DIR}/freeldr/bootsect/isoboot.asm ${CMAKE_CURRENT_BINARY_DIR}/freeldr/bootsect/isoboot.bin) > CreateBootSectorTarget(isobtrt ${CMAKE_CURRENT_SOURCE_DIR}/freeldr/bootsect/isobtrt.asm ${CMAKE_CURRENT_BINARY_DIR}/freeldr/bootsect/isobtrt.bin) > + > +include_directories(BEFORE freeldr/freeldr/include) > +include_directories(${REACTOS_SOURCE_DIR}/ntoskrnl/include) > + > +if(ARCH MATCHES i386) > +list(APPEND FREELDR_STARTUP_SOURCE > + freeldr/freeldr/arch/i386/fathelp.S > + freeldr/freeldr/arch/i386/arch.S) > +elseif(ARCH MATCHES amd64) > +list(APPEND FREELDR_STARTUP_SOURCE > + freeldr/freeldr/arch/amd64/fathelp.S > + freeldr/freeldr/arch/amd64/arch.S) > +endif(ARCH MATCHES i386) > + > +if(ARCH MATCHES i386) > +list(APPEND FREELDR_BASE64K_SOURCE > + freeldr/freeldr/arch/i386/boot.S > + freeldr/freeldr/arch/i386/drvmap.S > + freeldr/freeldr/arch/i386/i386cpu.S > + freeldr/freeldr/arch/i386/i386idt.S > + freeldr/freeldr/arch/i386/i386pnp.S > + freeldr/freeldr/arch/i386/i386trap.S > + freeldr/freeldr/arch/i386/int386.S > + freeldr/freeldr/arch/i386/linux.S > + freeldr/freeldr/arch/i386/mb.S) > +elseif(ARCH MATCHES amd64) > +list(APPEND FREELDR_BASE64K_SOURCE > + freeldr/freeldr/arch/amd64/drvmap.S > + freeldr/freeldr/arch/amd64/i386cpu.S > + freeldr/freeldr/arch/amd64/i386idt.S > + freeldr/freeldr/arch/amd64/i386trap.S > + freeldr/freeldr/arch/amd64/mb.S) > +endif(ARCH MATCHES i386) > + > +set_source_files_properties(${FREELDR_BASE64K_SOURCE} PROPERTIES COMPILE_DEFINITIONS "_NTHAL_") > + > +include_directories(${REACTOS_SOURCE_DIR}/lib/cmlib) > + > +list(APPEND FREELDR_BASE_SOURCE > + freeldr/freeldr/arcemul/mm.c > + freeldr/freeldr/arcemul/time.c > + freeldr/freeldr/cache/blocklist.c > + freeldr/freeldr/cache/cache.c > + freeldr/freeldr/comm/rs232.c > + freeldr/freeldr/disk/disk.c > + freeldr/freeldr/disk/partition.c > + freeldr/freeldr/disk/ramdisk.c > + freeldr/freeldr/fs/ext2.c > + freeldr/freeldr/fs/fat.c > + freeldr/freeldr/fs/fs.c > + freeldr/freeldr/fs/iso.c > + freeldr/freeldr/fs/ntfs.c > + freeldr/freeldr/inifile/ini_init.c > + freeldr/freeldr/inifile/inifile.c > + freeldr/freeldr/inifile/parse.c > + freeldr/freeldr/mm/meminit.c > + freeldr/freeldr/mm/mm.c > + freeldr/freeldr/reactos/registry.c > + freeldr/freeldr/reactos/arcname.c > + freeldr/freeldr/reactos/archwsup.c > + freeldr/freeldr/reactos/binhive.c > + freeldr/freeldr/reactos/reactos.c > + freeldr/freeldr/reactos/imageldr.c > + freeldr/freeldr/rtl/bget.c > + freeldr/freeldr/rtl/libsupp.c > + freeldr/freeldr/ui/directui.c > + freeldr/freeldr/ui/gui.c > + freeldr/freeldr/ui/minitui.c > + freeldr/freeldr/ui/noui.c > + freeldr/freeldr/ui/tui.c > + freeldr/freeldr/ui/tuimenu.c > + freeldr/freeldr/ui/ui.c > + freeldr/freeldr/video/fade.c > + freeldr/freeldr/video/palette.c > + freeldr/freeldr/video/video.c > + freeldr/freeldr/windows/conversion.c > + freeldr/freeldr/windows/peloader.c > + freeldr/freeldr/windows/winldr.c > + freeldr/freeldr/windows/wlmemory.c > + freeldr/freeldr/windows/wlregistry.c > + freeldr/freeldr/freeldr.c > + freeldr/freeldr/debug.c > + freeldr/freeldr/version.c > + freeldr/freeldr/cmdline.c > + freeldr/freeldr/machine.c > + freeldr/freeldr/options.c > + freeldr/freeldr/linuxboot.c > + freeldr/freeldr/oslist.c) > + > +if(ARCH MATCHES i386) > +list(APPEND FREELDR_BASE_SOURCE freeldr/freeldr/disk/scsiport.c) > +endif(ARCH MATCHES i386) > + > +set_source_files_properties(${FREELDR_BASE_SOURCE} PROPERTIES COMPILE_DEFINITIONS "_NTHAL_;_BLDR_;_NTSYSTEM_") > + > +include_directories(${REACTOS_SOURCE_DIR}/include/reactos/libs) > +include_directories(${REACTOS_SOURCE_DIR}/include/reactos/elf) > + > +if(ARCH MATCHES i386) > +list(APPEND FREELDR_ARCH_SOURCE > + freeldr/freeldr/arch/i386/_alloca.S > + freeldr/freeldr/arch/i386/archmach.c > + freeldr/freeldr/arch/i386/custom.c > + freeldr/freeldr/arch/i386/drivemap.c > + freeldr/freeldr/arch/i386/halstub.c > + freeldr/freeldr/arch/i386/hardware.c > + freeldr/freeldr/arch/i386/hwacpi.c > + freeldr/freeldr/arch/i386/hwapm.c > + freeldr/freeldr/arch/i386/hwpci.c > + freeldr/freeldr/arch/i386/i386disk.c > + freeldr/freeldr/arch/i386/i386rtl.c > + freeldr/freeldr/arch/i386/i386vid.c > + freeldr/freeldr/arch/i386/loader.c > + freeldr/freeldr/arch/i386/machpc.c > + freeldr/freeldr/arch/i386/miscboot.c > + freeldr/freeldr/arch/i386/ntoskrnl.c > + freeldr/freeldr/arch/i386/pccons.c > + freeldr/freeldr/arch/i386/pcdisk.c > + freeldr/freeldr/arch/i386/pcmem.c > + freeldr/freeldr/arch/i386/pcrtc.c > + freeldr/freeldr/arch/i386/pcvideo.c > + freeldr/freeldr/arch/i386/machxbox.c > + freeldr/freeldr/arch/i386/xboxcons.c > + freeldr/freeldr/arch/i386/xboxdisk.c > + freeldr/freeldr/arch/i386/xboxfont.c > + freeldr/freeldr/arch/i386/xboxhw.c > + freeldr/freeldr/arch/i386/xboxi2c.c > + freeldr/freeldr/arch/i386/xboxmem.c > + freeldr/freeldr/arch/i386/xboxrtc.c > + freeldr/freeldr/arch/i386/xboxvideo.c > + freeldr/freeldr/windows/i386/ntsetup.c > + freeldr/freeldr/windows/i386/wlmemory.c) > +else() > +#TBD > +endif(ARCH MATCHES i386) > + > +set_source_files_properties(${FREELDR_ARCH_SOURCE} PROPERTIES COMPILE_DEFINITIONS "_NTHAL_;_BLDR_;_NTSYSTEM_") > + > +list(APPEND SETUPLDR_MAIN_SOURCE > + freeldr/freeldr/bootmgr.c > + freeldr/freeldr/inffile/inffile.c > + freeldr/freeldr/reactos/setupldr.c) > + > +if(ARCH MATCHES i386) > +list(APPEND SETUPLDR_MAIN_SOURCE freeldr/freeldr/windows/setupldr2.c) > +elseif(ARCH MATCHES amd64) > +list(APPEND SETUPLDR_MAIN_SOURCE freeldr/freeldr/windows/setupldr2.c) > +endif(ARCH MATCHES i386) > + > +set_source_files_properties(${SETUPLDR_MAIN_SOURCE} PROPERTIES COMPILE_DEFINITIONS "_NTHAL_;FREELDR_REACTOS_SETUP" COMPILE_FLAGS "-ffreestanding -fno-builtin -fno-inline -fno-zero-initialized-in-bss") > + > +set(CMAKE_C_CREATE_SHARED_LIBRARY "<CMAKE_C_COMPILER> <CMAKE_SHARED_LIBRARY_C_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS> -o <TARGET> <OBJECTS> <LINK_LIBRARIES>") > + > +list(APPEND FREELDR_SOURCE > + freeldr/freeldr/bootmgr.c > + ${FREELDR_STARTUP_SOURCE} > + ${FREELDR_BASE64K_SOURCE} > + ${FREELDR_BASE_SOURCE} > + ${FREELDR_ARCH_SOURCE}) > + > +add_library(freeldr SHARED > + ${CMAKE_CURRENT_BINARY_DIR}/freeldr_freeldr.h.gch > + ${FREELDR_SOURCE}) > + > +set_target_properties(freeldr PROPERTIES LINK_FLAGS "-Wl,--strip-all -Wl,-entry,_mainCRTStartup -Wl,--image-base,0x8000 -Wl,--exclude-all-symbols -Wl,--subsystem,native" SUFFIX ".sys") > + > +if(ARCH MATCHES i386) > +target_link_libraries(freeldr mini_hal) > +endif(ARCH MATCHES i386) > + > +target_link_libraries(freeldr > + rossym > + cmlib > + rtl > + libcntpr) > +add_pch(freeldr ${CMAKE_CURRENT_SOURCE_DIR}/freeldr/freeldr/include/freeldr.h ${FREELDR_SOURCE}) > + > +list(APPEND SETUPLDR_SOURCE > + ${FREELDR_STARTUP_SOURCE} > + ${FREELDR_BASE64K_SOURCE} > + ${FREELDR_BASE_SOURCE} > + ${FREELDR_ARCH_SOURCE} > + ${SETUPLDR_MAIN_SOURCE}) > + > +add_library(setupldr SHARED > + ${CMAKE_CURRENT_BINARY_DIR}/freeldr_freeldr.h.gch > + ${SETUPLDR_SOURCE}) > + > +set_target_properties(setupldr PROPERTIES LINK_FLAGS "-Wl,--strip-all -Wl,-entry,_mainCRTStartup -Wl,--image-base,0x8000 -Wl,--exclude-all-symbols -Wl,--subsystem,native" SUFFIX ".sys") > + > +if(ARCH MATCHES i386) > +target_link_libraries(setupldr mini_hal) > +endif(ARCH MATCHES i386) > + > +target_link_libraries(setupldr > + rossym > + cmlib > + rtl > + libcntpr) > +add_pch(setupldr ${CMAKE_CURRENT_SOURCE_DIR}/freeldr/freeldr/include/freeldr.h ${SETUPLDR_SOURCE}) > > Copied: branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.S (from r48568, branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm) > URL: http://svn.reactos.org/svn/reactos/branches/cmake-bringup/boot/freeldr/free… > ============================================================================== > --- branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm [iso-8859-1] (original) > +++ branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.S [iso-8859-1] Thu Sep 2 17:39:45 2010 > @@ -1,226 +1,222 @@ > -; FATHELP.ASM > -; FAT12/16 Boot Sector Helper Code > -; Copyright (c) 1998, 2001, 2002, 2003 Brian Palmer > - > - > - > -;org 8000h > - > -segment .text > - > -bits 16 > - > - > -BootSectorStackTop equ 0x7bf2 > -DataAreaStartHigh equ 0x2 > -DataAreaStartLow equ 0x4 > -BiosCHSDriveSizeHigh equ 0x6 > -BiosCHSDriveSizeLow equ 0x8 > -BiosCHSDriveSize equ 0x8 > -ReadSectorsOffset equ 0xa > -ReadClusterOffset equ 0xc > -PutCharsOffset equ 0xe > - > -OEMName equ 3 > -BytesPerSector equ 11 > -SectsPerCluster equ 13 > -ReservedSectors equ 14 > -NumberOfFats equ 16 > -MaxRootEntries equ 17 > -TotalSectors equ 19 > -MediaDescriptor equ 21 > -SectorsPerFat equ 22 > -SectorsPerTrack equ 24 > -NumberOfHeads equ 26 > -HiddenSectors equ 28 > -TotalSectorsBig equ 32 > -BootDrive equ 36 > -Reserved equ 37 > -ExtendSig equ 38 > -SerialNumber equ 39 > -VolumeLabel equ 43 > -FileSystem equ 54 > - > -BootPartition equ 0x7dfd > +// FATHELP.ASM > +// FAT12/16 Boot Sector Helper Code > +// Copyright (c) 1998, 2001, 2002, 2003 Brian Palmer > + > + .text > + .code16 > + .intel_syntax > + > +#define BootSectorStackTop 0x7bf2 > +#define DataAreaStartHigh 0x2 > +#define DataAreaStartLow 0x4 > +#define BiosCHSDriveSizeHigh 0x6 > +#define BiosCHSDriveSizeLow 0x8 > +#define BiosCHSDriveSize 0x8 > +#define ReadSectorsOffset 0xa > +#define ReadClusterOffset 0xc > +#define PutCharsOffset 0xe > + > +#define OEMName 3 > +#define BytesPerSector 11 > +#define SectsPerCluster 13 > +#define ReservedSectors 14 > +#define NumberOfFats 16 > +#define MaxRootEntries 17 > +#define TotalSectors 19 > +#define MediaDescriptor 21 > +#define SectorsPerFat 22 > +#define SectorsPerTrack 24 > +#define NumberOfHeads 26 > +#define HiddenSectors 28 > +#define TotalSectorsBig 32 > +#define BootDrive 36 > +#define Reserved 37 > +#define ExtendSig 38 > +#define SerialNumber 39 > +#define VolumeLabel 43 > +#define FileSystem 54 > + > +#define BootPartition 0x7dfd > > > -; This code will be stored in the first 512 bytes > -; of freeldr.sys. The first 3 bytes will be a jmp > -; instruction to skip past the FAT helper code > -; that is stored in the rest of the 512 bytes. > -; > -; This code is loaded at 0000:8000 so we have to > -; encode a jmp instruction to jump to 0000:8200 > - > -global _mainCRTStartup ; For Mingw32 builds where the linker looks for this symbol > +// This code will be stored in the first 512 bytes > +// of freeldr.sys. The first 3 bytes will be a jmp > +// instruction to skip past the FAT helper code > +// that is stored in the rest of the 512 bytes. > +// > +// This code is loaded at 0000:8000 so we have to > +// encode a jmp instruction to jump to 0000:8200 > + > +.globl _mainCRTStartup /* For Mingw32 builds where the linker looks for this symbol */ > _mainCRTStartup: > -global start > +.globl start > start: > - db 0xe9 > - db 0xfd > - db 0x01 > - > -; Now starts the extra boot code that we will store > -; in the first 512 bytes of freeldr.sys. This code > -; allows the FAT12/16 bootsector to navigate the > -; FAT table so that we can still load freeldr.sys > -; even if it is fragmented. > + .byte 0xe9 > + .byte 0xfd > + .byte 0x01 > + > +// Now starts the extra boot code that we will store > +// in the first 512 bytes of freeldr.sys. This code > +// allows the FAT12/16 bootsector to navigate the > +// FAT table so that we can still load freeldr.sys > +// even if it is fragmented. > > > FatHelperEntryPoint: > > - push ax ; First save AX - the start cluster of freeldr.sys > - > - > - ; Display "Loading FreeLoader..." message > - mov esi,msgLoading ; Loading message > - call [bp-PutCharsOffset] ; Display it > + push %ax /* First save AX - the start cluster of freeldr.sys */ > + > + > + // Display "Loading FreeLoader..." message > + mov %esi,msgLoading /* Loading message */ > + call [%bp-PutCharsOffset] /* Display it */ > > > call ReadFatIntoMemory > > - pop ax ; Restore AX (start cluster) > - ; AX has start cluster of freeldr.sys > - > - mov bx,800h > - mov es,bx > + pop %ax /* Restore AX (start cluster) */ > + // AX has start cluster of freeldr.sys > + > + mov %bx,0x800 > + mov %es,%bx > > LoadFile: > - push ax > + push %ax > call IsFat12 > - pop ax > + pop %ax > jnc LoadFile2 > - cmp ax,0ff8h ; Check to see if this is the last cluster in the chain > + cmp %ax,0xff8 /* Check to see if this is the last cluster in the chain */ > jmp LoadFile3 > LoadFile2: > - cmp ax,0fff8h > + cmp %ax,0xfff8 > LoadFile3: > - jae LoadFile_Done ; If so continue, if not then read then next one > - push ax > - xor bx,bx ; Load ROSLDR starting at 0000:8000h > - push es > - call [bp-ReadClusterOffset] > - pop es > - > - xor bx,bx > - mov bl,BYTE [BYTE bp+SectsPerCluster] > - shl bx,5 ; BX = BX * 512 / 16 > - mov ax,es ; Increment the load address by > - add ax,bx ; The size of a cluster > - mov es,ax > + jae LoadFile_Done /* If so continue, if not then read then next one */ > + push %ax > + xor %bx,%bx /* Load ROSLDR starting at 0000:8000h */ > + push %es > + call [%bp-ReadClusterOffset] > + pop %es > + > + xor %bx,%bx > + mov %bl,BYTE [%bp+SectsPerCluster] > + shl %bx,5 /* BX = BX * 512 / 16 */ > + mov %ax,%es /* Increment the load address by */ > + add %ax,%bx /* The size of a cluster */ > + mov %es,%ax > > call IsFat12 > - pop ax > - push es > + pop %ax > + push %es > jnc LoadFile4 > - call GetFatEntry12 ; Get the next entry > + call GetFatEntry12 /* Get the next entry */ > jmp LoadFile5 > LoadFile4: > call GetFatEntry16 > LoadFile5: > - pop es > - > - jmp LoadFile ; Load the next cluster (if any) > + pop %es > + > + jmp LoadFile /* Load the next cluster (if any) */ > > LoadFile_Done: > - mov dl,BYTE [BYTE bp+BootDrive] ; Load the boot drive into DL > - mov dh,[BootPartition] ; Load the boot partition into DH > - > - push 0 ; push segment (0x0000) > - mov bx, [0x8000 + 0xA8] ; load the RVA of the EntryPoint into eax > - add bx, 0x8000 ; RVA -> VA and skip 3 bytes (jump to fathelper code) > - push bx ; push offset > - retf ; Transfer control to FreeLoader > - > -; Reads the entire FAT into memory at 7000:0000 > + mov %dl,BYTE [%bp+BootDrive] /* Load the boot drive into DL */ > + mov %dh,[BootPartition] /* Load the boot partition into DH */ > + > + push 0 /* push segment (0x0000) */ > + mov %bx, [0x80A8] /* load the RVA of the EntryPoint into eax */ > + add %bx, 0x8000 /* RVA -> VA and skip 3 bytes (jump to fathelper code) */ > + push %bx /* push offset */ > + retf /* Transfer control to FreeLoader */ > + > +// Reads the entire FAT into memory at 7000:0000 > ReadFatIntoMemory: > - mov ax,WORD [BYTE bp+HiddenSectors] > - mov dx,WORD [BYTE bp+HiddenSectors+2] > - add ax,WORD [BYTE bp+ReservedSectors] > - adc dx,byte 0 > - mov cx,WORD [BYTE bp+SectorsPerFat] > - mov bx,7000h > - mov es,bx > - xor bx,bx > - call [bp-ReadSectorsOffset] > - ret > - > - > -; Returns the FAT entry for a given cluster number for 16-bit FAT > -; On entry AX has cluster number > -; On return AX has FAT entry for that cluster > + mov %ax,WORD [%bp+HiddenSectors] > + mov %dx,WORD [%bp+HiddenSectors+2] > + add %ax,WORD [%bp+ReservedSectors] > + adc %dx,0 > + mov %cx,WORD [%bp+SectorsPerFat] > + mov %bx,0x7000 > + mov %es,%bx > + xor %bx,%bx > + call [%bp-ReadSectorsOffset] > + ret > + > + > +// Returns the FAT entry for a given cluster number for 16-bit FAT > +// On entry AX has cluster number > +// On return AX has FAT entry for that cluster > GetFatEntry16: > > - mov cx,2 ; AX = AX * 2 (since FAT16 entries are 2 bytes) > - mul cx > - shl dx,12 > - > - mov bx,7000h > - add bx,dx > - mov es,bx > - mov bx,ax ; Restore FAT entry offset > - mov ax,WORD [es:bx] ; Get FAT entry > - > - ret > - > - > -; Returns the FAT entry for a given cluster number for 12-bit FAT > -; On entry AX has cluster number > -; On return AX has FAT entry for that cluster > + mov %cx,2 /* AX = AX * 2 (since FAT16 entries are 2 bytes) */ > + mul %cx > + shl %dx,12 > + > + mov %bx,0x7000 > + add %bx,%dx > + mov %es,%bx > + mov %bx,%ax /* Restore FAT entry offset */ > + es mov %ax,WORD [%bx] /* Get FAT entry */ > + > + ret > + > + > +// Returns the FAT entry for a given cluster number for 12-bit FAT > +// On entry AX has cluster number > +// On return AX has FAT entry for that cluster > GetFatEntry12: > > - push ax > - mov cx,ax > - shr ax,1 > - add ax,cx ; AX = AX * 1.5 (AX = AX + (AX / 2)) (since FAT12 entries are 12 bits) > - > - mov bx,7000h > - mov es,bx > - mov bx,ax ; Put FAT entry offset into BX > - mov ax,WORD [es:bx] ; Get FAT entry > - pop cx ; Get cluster number from stack > - and cx,1 > + push %ax > + mov %cx,%ax > + shr %ax,1 > + add %ax,%cx /* AX = AX * 1.5 (AX = AX + (AX / 2)) (since FAT12 entries are 12 bits) */ > + > + mov %bx,0x7000 > + mov %es,%bx > + mov %bx,%ax /* Put FAT entry offset into BX */ > + es mov %ax,WORD [%bx] /* Get FAT entry */ > + pop %cx /* Get cluster number from stack */ > + and %cx,1 > jz UseLow12Bits > - and ax,0fff0h > - shr ax,4 > + and %ax,0xfff0 > + shr %ax,4 > jmp GetFatEntry12_Done > > UseLow12Bits: > - and ax,0fffh > + and %ax,0x0fff > > GetFatEntry12_Done: > > ret > > > -; Returns CF = 1 if this is a FAT12 file system > -; Otherwise CF = 0 for FAT16 > +// Returns CF = 1 if this is a FAT12 file system > +// Otherwise CF = 0 for FAT16 > IsFat12: > > - mov ebx,DWORD [BYTE bp-DataAreaStartLow] > - ; EBX now has the number of the starting sector of the data area > - ; starting from the beginning of the disk, so subtrace hidden sectors > - sub ebx,DWORD [BYTE bp+HiddenSectors] > - > - > - xor eax,eax > - mov ax,WORD [BYTE bp+TotalSectors] > - cmp ax,byte 0 > + mov %ebx,DWORD [%bp-DataAreaStartLow] > + // EBX now has the number of the starting sector of the data area > + // starting from the beginning of the disk, so subtrace hidden sectors > + sub %ebx,DWORD [%bp+HiddenSectors] > + > + > + xor %eax,%eax > + mov %ax,WORD [%bp+TotalSectors] > + cmp %ax,0 > jnz IsFat12_2 > - mov eax,DWORD [BYTE bp+TotalSectorsBig] > - > - ; EAX now contains the number of sectors on the volume > + mov %eax,DWORD [%bp+TotalSectorsBig] > + > + // EAX now contains the number of sectors on the volume > > IsFat12_2: > - sub eax,ebx ; Subtract data area start sector > - xor edx,edx ; from total sectors of volume > - > - ; EDX:EAX now contains the number of data sectors on the volume > - movzx ebx,BYTE [BYTE bp+SectsPerCluster] > - div ebx > - ; EAX now has the number of clusters on the volume > + sub %eax,%ebx /* Subtract data area start sector */ > + xor %edx,%edx /* from total sectors of volume */ > + > + // EDX:EAX now contains the number of data sectors on the volume > + xor %ebx,%ebx > + mov %bl,BYTE [%bp+SectsPerCluster] > + div %ebx > + // EAX now has the number of clusters on the volume > stc > - cmp eax,4085 > + cmp %eax,4085 > jb IsFat12_Done > clc > > @@ -229,7 +225,9 @@ > > > > -msgLoading db 'Loading FreeLoader...',0dh,0ah,0 > - > - times 510-($-$$) db 0 ; Pad to 510 bytes > - dw 0aa55h ; BootSector signature > +msgLoading: > + .asciz "Loading FreeLoader...\r\n" > + > + .org 0x1fe > +blockend: > + .word 0x0aa55 /* BootSector signature */ > > Removed: branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm > URL: http://svn.reactos.org/svn/reactos/branches/cmake-bringup/boot/freeldr/free… > ============================================================================== > --- branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm [iso-8859-1] (original) > +++ branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm (removed) > @@ -1,235 +1,0 @@ > -; FATHELP.ASM > -; FAT12/16 Boot Sector Helper Code > -; Copyright (c) 1998, 2001, 2002, 2003 Brian Palmer > - > - > - > -;org 8000h > - > -segment .text > - > -bits 16 > - > - > -BootSectorStackTop equ 0x7bf2 > -DataAreaStartHigh equ 0x2 > -DataAreaStartLow equ 0x4 > -BiosCHSDriveSizeHigh equ 0x6 > -BiosCHSDriveSizeLow equ 0x8 > -BiosCHSDriveSize equ 0x8 > -ReadSectorsOffset equ 0xa > -ReadClusterOffset equ 0xc > -PutCharsOffset equ 0xe > - > -OEMName equ 3 > -BytesPerSector equ 11 > -SectsPerCluster equ 13 > -ReservedSectors equ 14 > -NumberOfFats equ 16 > -MaxRootEntries equ 17 > -TotalSectors equ 19 > -MediaDescriptor equ 21 > -SectorsPerFat equ 22 > -SectorsPerTrack equ 24 > -NumberOfHeads equ 26 > -HiddenSectors equ 28 > -TotalSectorsBig equ 32 > -BootDrive equ 36 > -Reserved equ 37 > -ExtendSig equ 38 > -SerialNumber equ 39 > -VolumeLabel equ 43 > -FileSystem equ 54 > - > -BootPartition equ 0x7dfd > - > - > -; This code will be stored in the first 512 bytes > -; of freeldr.sys. The first 3 bytes will be a jmp > -; instruction to skip past the FAT helper code > -; that is stored in the rest of the 512 bytes. > -; > -; This code is loaded at 0000:8000 so we have to > -; encode a jmp instruction to jump to 0000:8200 > - > -global _mainCRTStartup ; For Mingw32 builds where the linker looks for this symbol > -_mainCRTStartup: > -global start > -start: > - db 0xe9 > - db 0xfd > - db 0x01 > - > -; Now starts the extra boot code that we will store > -; in the first 512 bytes of freeldr.sys. This code > -; allows the FAT12/16 bootsector to navigate the > -; FAT table so that we can still load freeldr.sys > -; even if it is fragmented. > - > - > -FatHelperEntryPoint: > - > - push ax ; First save AX - the start cluster of freeldr.sys > - > - > - ; Display "Loading FreeLoader..." message > - mov esi,msgLoading ; Loading message > - call [bp-PutCharsOffset] ; Display it > - > - > - call ReadFatIntoMemory > - > - pop ax ; Restore AX (start cluster) > - ; AX has start cluster of freeldr.sys > - > - mov bx,800h > - mov es,bx > - > -LoadFile: > - push ax > - call IsFat12 > - pop ax > - jnc LoadFile2 > - cmp ax,0ff8h ; Check to see if this is the last cluster in the chain > - jmp LoadFile3 > -LoadFile2: > - cmp ax,0fff8h > -LoadFile3: > - jae LoadFile_Done ; If so continue, if not then read then next one > - push ax > - xor bx,bx ; Load ROSLDR starting at 0000:8000h > - push es > - call [bp-ReadClusterOffset] > - pop es > - > - xor bx,bx > - mov bl,BYTE [BYTE bp+SectsPerCluster] > - shl bx,5 ; BX = BX * 512 / 16 > - mov ax,es ; Increment the load address by > - add ax,bx ; The size of a cluster > - mov es,ax > - > - call IsFat12 > - pop ax > - push es > - jnc LoadFile4 > - call GetFatEntry12 ; Get the next entry > - jmp LoadFile5 > -LoadFile4: > - call GetFatEntry16 > -LoadFile5: > - pop es > - > - jmp LoadFile ; Load the next cluster (if any) > - > -LoadFile_Done: > - mov dl,BYTE [BYTE bp+BootDrive] ; Load the boot drive into DL > - mov dh,[BootPartition] ; Load the boot partition into DH > - > - push 0 ; push segment (0x0000) > - mov bx, [0x8000 + 0xA8] ; load the RVA of the EntryPoint into eax > - add bx, 0x8000 ; RVA -> VA and skip 3 bytes (jump to fathelper code) > - push bx ; push offset > - retf ; Transfer control to FreeLoader > - > -; Reads the entire FAT into memory at 7000:0000 > -ReadFatIntoMemory: > - mov ax,WORD [BYTE bp+HiddenSectors] > - mov dx,WORD [BYTE bp+HiddenSectors+2] > - add ax,WORD [BYTE bp+ReservedSectors] > - adc dx,byte 0 > - mov cx,WORD [BYTE bp+SectorsPerFat] > - mov bx,7000h > - mov es,bx > - xor bx,bx > - call [bp-ReadSectorsOffset] > - ret > - > - > -; Returns the FAT entry for a given cluster number for 16-bit FAT > -; On entry AX has cluster number > -; On return AX has FAT entry for that cluster > -GetFatEntry16: > - > - mov cx,2 ; AX = AX * 2 (since FAT16 entries are 2 bytes) > - mul cx > - shl dx,12 > - > - mov bx,7000h > - add bx,dx > - mov es,bx > - mov bx,ax ; Restore FAT entry offset > - mov ax,WORD [es:bx] ; Get FAT entry > - > - ret > - > - > -; Returns the FAT entry for a given cluster number for 12-bit FAT > -; On entry AX has cluster number > -; On return AX has FAT entry for that cluster > -GetFatEntry12: > - > - push ax > - mov cx,ax > - shr ax,1 > - add ax,cx ; AX = AX * 1.5 (AX = AX + (AX / 2)) (since FAT12 entries are 12 bits) > - > - mov bx,7000h > - mov es,bx > - mov bx,ax ; Put FAT entry offset into BX > - mov ax,WORD [es:bx] ; Get FAT entry > - pop cx ; Get cluster number from stack > - and cx,1 > - jz UseLow12Bits > - and ax,0fff0h > - shr ax,4 > - jmp GetFatEntry12_Done > - > -UseLow12Bits: > - and ax,0fffh > - > -GetFatEntry12_Done: > - > - ret > - > - > -; Returns CF = 1 if this is a FAT12 file system > -; Otherwise CF = 0 for FAT16 > -IsFat12: > - > - mov ebx,DWORD [BYTE bp-DataAreaStartLow] > - ; EBX now has the number of the starting sector of the data area > - ; starting from the beginning of the disk, so subtrace hidden sectors > - sub ebx,DWORD [BYTE bp+HiddenSectors] > - > - > - xor eax,eax > - mov ax,WORD [BYTE bp+TotalSectors] > - cmp ax,byte 0 > - jnz IsFat12_2 > - mov eax,DWORD [BYTE bp+TotalSectorsBig] > - > - ; EAX now contains the number of sectors on the volume > - > -IsFat12_2: > - sub eax,ebx ; Subtract data area start sector > - xor edx,edx ; from total sectors of volume > - > - ; EDX:EAX now contains the number of data sectors on the volume > - movzx ebx,BYTE [BYTE bp+SectsPerCluster] > - div ebx > - ; EAX now has the number of clusters on the volume > - stc > - cmp eax,4085 > - jb IsFat12_Done > - clc > - > -IsFat12_Done: > - ret > - > - > - > -msgLoading db 'Loading FreeLoader...',0dh,0ah,0 > - > - times 510-($-$$) db 0 ; Pad to 510 bytes > - dw 0aa55h ; BootSector signature > > >

14 years, 10 months

9
11
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 48722: [USETUP] Allocate a drive layout buffer that is l

by Pierre Schweitzer

Hi, why reimplementing an unsecure IoReadPartitionTable version? It even looks like IoReadPartitionTableEx() which may arrive soon in ReactOS ;). Best regards, P. Schweitzer

14 years, 10 months

1
0
0 0

Re: [ros-dev] Usetup

by Love Nystrom

Hi, What You say makes sense of course. I can't find time to dig into the code, but it sounds like you acted correctly. We can of course improve the setup behavior as time goes and we learn how to do it right with various boot managers, no need to take after Microsoft here, but there will always be cases when we don't know how to wedge the boot in. We can always, as long as there is a free partition or free space to create one, get as far as installing the OS and it's partition boot, but may be unable to install a master boot, if the user has an unknown boot manager we don't recognize One way to deal with it would be to chain the master boot. That is, we save the original master boot to a file, and implement a query in our own master boot, whether the user want to boot ROS, or continue with the original master boot. It would be a small matter to load the original master boot and giving control over to it if need be. Sure, it's one more pit-stop on the way to OS, but it would take care of all the cases we cannot know, or cannot handle. Best Regards L from Hell Eric Kohl <eric.kohl(a)t-online.de> wrote: > Hi! > > Being cooperative was my intention when I wrote this part of usetup. > The bad thing about this approach is that usetup needs to deal with > all kinds of different situations that developers cannot even think > about. The only proper way to fix this situation was: "Don't touch it > if you don't know how to deal with it!" The result was that usetup > could only handle empty harddisks and Windows boot managers correctly. > Except for these two cases there are lots of different situations that > a setup application cannot deal with. That's where the user must fix > things. That's why usetup enables users to save the bootsector to a > floppy disk. This enables them to fix the unknown situations > themselves. Unfortunately this means that newbies might not be able to > install the bootcode properly. But I thought it was better not to > overwrite a bootsector that to unintentionally damage a system. > > The question how to handle this correctly is a difficult one. > Microsoft chose the easy way as they behave like they are the owner of > the system and overwrite everything as they see fit. But implementing > this part of the setup in a way that fits everyones needs is a very > difficult task. Just think about the different filesystems and > different versions of LILO and GRUB and what about other third-party > boot-managers... > > Regards, > Eric

14 years, 10 months

1
0
0 0

[ros-diffs] [cgutman] 48700: [USETUP] - Remove code that was corrupting disk data and causing setup to fail in rare cases - Write the MBR in all cases (Windows setup behavior too) - We can overwrite GRUB and L...

by James Tabor

Hi! Please test this with GRUB and LILO, since I use LILO on my main hardware test. I do not have access to it for the moment. During the installation of the boot CD, I do not overwrite the MBR. I just hope it works when I get back to work with the project. Thanks, James

14 years, 11 months

5
4
0 0

Re: [ros-dev] Convert fat12/16 boot sector helper code to gas syntax.

by Love Nystrom

Second that. If it ain't broke, don't bloody "fix" it. Best Regards L from Hell Alex Ionescu <ionucu(a)videotron.ca>: > This is retarded, GAS supports Intel syntax. Why did this require > rewriting everything in AT&T syntax and introducing bugs? And what's > up with calling AT&T syntax "GAS" Syntax. > > I wonder what Brian would say.... > > It's funny how this project gets rid of old developers, gets new > developers, and has them make the same mistakes/idiotic things the old > developers left for in the first place... > > Good job! > > Best regards, > Alex Ionescu > >

14 years, 11 months

2
1
0 0

Bugzilla Workflow project

by Olaf Siejka

Allow me to present a small sub-project Gabriel and I are working on. We did a small scale consulting, but its the time to present it on a more wider scale. As a comment, specifically to Timo's post: 2nd class tags should not be conflicting with Component field when possible. In case of Kernel and win32k, a submodule should be used instead of module name: for example in case of kernel bugs, Components should be set to Kernel, whereas 2nd class tag should be pointing to kernel submodule, like iomgr:, ob:, mm: etc. All opinions are most welcome Best regards

14 years, 11 months

1
0
0 0

Bugzilla interface

by Timo Kreuzer

Hi I'd like to propose an overhaul of our bugzilla interface. The reason is that the current interface is ugly and confusing and I think we can make filing and handling bugs less unenjoyable ;-) First I think it would be very useful, if we could edit the description field of the bugs. This way we don't need to browse through dozens of comments to find all neccessary info, while the description only contains useless stuff. This should be restricted to the original reporter and testers / developers. Then when filing a new bug or looking at a bug that is already filed, the layout is horrible. I'm not a webdesigner, so it's hard for me to say how it should look like, but definately not the way it is. This might be appropriate for projects whose website look like http://www.gnu.org/software/binutils/ but I'm sure, we can do better. Then when filing a bug there are the following fields: - reporter - I know who I am, so why show it to me? Unneccessary - Component: I don't think this field is really useful as it is. First: Patches are definately not a component. Then it's often hard to tell where the bug is. for example, if rapps doesn't download anything, is that related to network or is it a kernel bug or win32 or rapps or is only the server down? You often don't know it when filing a bug. Also win32 covers a lot from win32k to shell32, but are these more closely related than drivers and networking? - Severity: while I think this field is useful and important, it should only be editable by testers and developers and should not appear when a bug is filed. - Platform: should be removed - OS: should be removed - AssignTo, Cc: rarely used on first filing, should IMO only be editable by testers / developers - URL: While we use this field from time to time, I think the URL could as well, if neccessary be put into the description field (provided, it was editable). This versatile field should imo change it's purpose from URL to TAG. So we can add different tags, like REGRESSION, PATCH, HACK, that are currently put into the summery field. It could also contain the regression range or guilty version - Alias: we don't use this, or rather currently only misuse this for the guilty version, which is problematic, as soon as 2 bugs have the same guilty version, IMO unneccessary - Summery: should be as wide as the description field - Description: To get better bugreports, I suggest dividing this field into "Steps to reproduce:" "Experienced behaviour:" "Remarks" These fields can very well be automatically merged into one field, It's just to show people that they must provide steps to reproduce, instead of writing dozens of lines about their hardware configuration and how they feel about the bug. Regards, Timo

14 years, 11 months

6
10
0 0

Regarding 48632

by Ros Arm

Hello, Many thanks for fixing this idiotic oversight of mine. I apologies for the long hours of debugging I must have caused. This fix is somewhat incomplete/at the wrong place; could this be marked as such in the code, perhaps with a FIXME under my name, so that I may fix this correctly upon my return to the US? Much obliged! -r Author: mjmartin Date: Sat Aug 28 00:26:02 2010 New Revision: 48632 URL: http://svn.reactos.org/svn/reactos?rev=48632&view=rev Log: [ntoskrnl/ps] - When deleting a Process remove the Process from the MmProcessList. Fixes random NonPaged Pool corruptions. Thanks aicom for assistance. Modified: trunk/reactos/ntoskrnl/ps/kill.c Modified: trunk/reactos/ntoskrnl/ps/kill.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/kill.c?rev=486… ============================================================================== --- trunk/reactos/ntoskrnl/ps/kill.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/ps/kill.c [iso-8859-1] Sat Aug 28 00:26:02 2010 @@ -300,6 +300,8 @@ /* Detach */ KeUnstackDetachProcess(&ApcState); + + RemoveEntryList(&Process->MmProcessLinks); /* Completely delete the Address Space */ MmDeleteProcessAddressSpace(Process);

14 years, 11 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 48593: [DHCPCSVC] - Write the DNS servers in a REG_MULTI_SZ value [IPHLPAPI] - Rewrite the registry reading code - Use HeapFree to free memory from the allocated from heap

by Timo Kreuzer

It looks like this change has caused some regressions in sysreg http://www.reactos.org/testman/compare.php?ids=3934,3935 cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Sun Aug 22 22:22:27 2010 > New Revision: 48593 > > URL: http://svn.reactos.org/svn/reactos?rev=48593&view=rev > Log: > [DHCPCSVC] > - Write the DNS servers in a REG_MULTI_SZ value > [IPHLPAPI] > - Rewrite the registry reading code > - Use HeapFree to free memory from the allocated from heap > > Modified: > trunk/reactos/dll/win32/dhcpcsvc/dhcp/dhclient.c > trunk/reactos/dll/win32/iphlpapi/iphlpapi_private.h > trunk/reactos/dll/win32/iphlpapi/registry.c > trunk/reactos/dll/win32/iphlpapi/resinfo_reactos.c > > Modified: trunk/reactos/dll/win32/dhcpcsvc/dhcp/dhclient.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/dhcpcsvc/dhcp/dh… > ============================================================================== > --- trunk/reactos/dll/win32/dhcpcsvc/dhcp/dhclient.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/dhcpcsvc/dhcp/dhclient.c [iso-8859-1] Sun Aug 22 22:22:27 2010 > @@ -507,24 +507,25 @@ > char *nsbuf; > int i, addrs = > new_lease->options[DHO_DOMAIN_NAME_SERVERS].len / sizeof(ULONG); > - > - nsbuf = malloc( addrs * sizeof(IP_ADDRESS_STRING) ); > + int len = 0; > + > + nsbuf = malloc( addrs * sizeof(IP_ADDRESS_STRING) + 1 ); > > if( nsbuf) { > - nsbuf[0] = 0; > + memset(nsbuf, 0, addrs * sizeof(IP_ADDRESS_STRING) + 1); > for( i = 0; i < addrs; i++ ) { > nameserver.len = sizeof(ULONG); > memcpy( nameserver.iabuf, > new_lease->options[DHO_DOMAIN_NAME_SERVERS].data + > (i * sizeof(ULONG)), sizeof(ULONG) ); > strcat( nsbuf, piaddr(nameserver) ); > - if( i != addrs-1 ) strcat( nsbuf, "," ); > + len += strlen(nsbuf) + 1; > } > > DH_DbgPrint(MID_TRACE,("Setting DhcpNameserver: %s\n", nsbuf)); > > - RegSetValueExA( RegKey, "DhcpNameServer", 0, REG_SZ, > - (LPBYTE)nsbuf, strlen(nsbuf) + 1 ); > + RegSetValueExA( RegKey, "DhcpNameServer", 0, REG_MULTI_SZ, > + (LPBYTE)nsbuf, len + 1 ); > free( nsbuf ); > } > > > Modified: trunk/reactos/dll/win32/iphlpapi/iphlpapi_private.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/iphlpapi/iphlpap… > ============================================================================== > --- trunk/reactos/dll/win32/iphlpapi/iphlpapi_private.h [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/iphlpapi/iphlpapi_private.h [iso-8859-1] Sun Aug 22 22:22:27 2010 > @@ -139,6 +139,7 @@ > PWCHAR GetNthChildKeyName( HANDLE RegHandle, DWORD n ); > void ConsumeChildKeyName( PWCHAR Name ); > PWCHAR QueryRegistryValueString( HANDLE RegHandle, PWCHAR ValueName ); > +PWCHAR *QueryRegistryValueStringMulti( HANDLE RegHandle, PWCHAR ValueName ); > void ConsumeRegValueString( PWCHAR NameServer ); > BOOL isInterface( TDIEntityID *if_maybe ); > BOOL hasArp( HANDLE tcpFile, TDIEntityID *arp_maybe ); > > Modified: trunk/reactos/dll/win32/iphlpapi/registry.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/iphlpapi/registr… > ============================================================================== > --- trunk/reactos/dll/win32/iphlpapi/registry.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/iphlpapi/registry.c [iso-8859-1] Sun Aug 22 22:22:27 2010 > @@ -66,25 +66,123 @@ > if (Name) HeapFree( GetProcessHeap(), 0, Name ); > } > > -PWCHAR QueryRegistryValueString( HANDLE RegHandle, PWCHAR ValueName ) { > - PWCHAR Name; > - DWORD ReturnedSize = 0; > +PVOID QueryRegistryValue(HANDLE RegHandle, PWCHAR ValueName, LPDWORD RegistryType, LPDWORD Length) > +{ > + PVOID ReadValue = NULL; > + DWORD Error; > > - if (RegQueryValueExW( RegHandle, ValueName, NULL, NULL, NULL, > - &ReturnedSize ) != 0) { > - return 0; > - } else { > - Name = malloc( ReturnedSize); > - RegQueryValueExW( RegHandle, ValueName, NULL, NULL, (PVOID)Name, > - &ReturnedSize ); > - return Name; > - } > + *Length = 0; > + *RegistryType = REG_NONE; > + > + while (TRUE) > + { > + Error = RegQueryValueExW(RegHandle, ValueName, NULL, RegistryType, ReadValue, Length); > + if (Error == ERROR_SUCCESS) > + { > + if (ReadValue) break; > + } > + else if (Error == ERROR_MORE_DATA) > + { > + HeapFree(GetProcessHeap(), 0, ReadValue); > + } > + else break; > + > + ReadValue = HeapAlloc(GetProcessHeap(), 0, *Length); > + if (!ReadValue) return NULL; > + } > + > + if (Error != ERROR_SUCCESS) > + { > + if (ReadValue) HeapFree(GetProcessHeap(), 0, ReadValue); > + > + *Length = 0; > + *RegistryType = REG_NONE; > + ReadValue = NULL; > + } > + > + return ReadValue; > +} > + > +PWCHAR TerminateReadString(PWCHAR String, DWORD Length) > +{ > + PWCHAR TerminatedString; > + > + TerminatedString = HeapAlloc(GetProcessHeap(), 0, Length + sizeof(WCHAR)); > + if (TerminatedString == NULL) > + return NULL; > + > + memcpy(TerminatedString, String, Length); > + > + TerminatedString[Length / sizeof(WCHAR)] = UNICODE_NULL; > + > + return TerminatedString; > +} > + > +PWCHAR QueryRegistryValueString( HANDLE RegHandle, PWCHAR ValueName ) > +{ > + PWCHAR String, TerminatedString; > + DWORD Type, Length; > + > + String = QueryRegistryValue(RegHandle, ValueName, &Type, &Length); > + if (!String) return NULL; > + if (Type != REG_SZ) > + { > + DbgPrint("Type mismatch for %S (%d != %d)\n", ValueName, Type, REG_SZ); > + //HeapFree(GetProcessHeap(), 0, String); > + //return NULL; > + } > + > + TerminatedString = TerminateReadString(String, Length); > + HeapFree(GetProcessHeap(), 0, String); > + if (!TerminatedString) return NULL; > + > + return TerminatedString; > } > > void ConsumeRegValueString( PWCHAR Value ) { > - if (Value) free(Value); > + if (Value) HeapFree(GetProcessHeap(), 0, Value); > } > > PWCHAR *QueryRegistryValueStringMulti( HANDLE RegHandle, PWCHAR ValueName ) { > - return 0; /* FIXME if needed */ > + PWCHAR String, TerminatedString, Tmp; > + PWCHAR *Table; > + DWORD Type, Length, i, j; > + > + String = QueryRegistryValue(RegHandle, ValueName, &Type, &Length); > + if (!String) return NULL; > + if (Type != REG_MULTI_SZ) > + { > + DbgPrint("Type mismatch for %S (%d != %d)\n", ValueName, Type, REG_MULTI_SZ); > + //HeapFree(GetProcessHeap(), 0, String); > + //return NULL; > + } > + > + TerminatedString = TerminateReadString(String, Length); > + HeapFree(GetProcessHeap(), 0, String); > + if (!TerminatedString) return NULL; > + > + for (Tmp = TerminatedString, i = 0; *Tmp; Tmp++, i++) while (*Tmp) Tmp++; > + > + Table = HeapAlloc(GetProcessHeap(), 0, (i + 1) * sizeof(PWCHAR)); > + if (!Table) > + { > + HeapFree(GetProcessHeap(), 0, TerminatedString); > + return NULL; > + } > + > + for (Tmp = TerminatedString, j = 0; *Tmp; Tmp++, j++) > + { > + PWCHAR Orig = Tmp; > + > + for (i = 0; *Tmp; i++, Tmp++); > + > + Table[j] = HeapAlloc(GetProcessHeap(), 0, i * sizeof(WCHAR)); > + memcpy(Table[j], Orig, i * sizeof(WCHAR)); > + } > + > + Table[j] = NULL; > + > + HeapFree(GetProcessHeap(), 0, TerminatedString); > + > + return Table; > } > > Modified: trunk/reactos/dll/win32/iphlpapi/resinfo_reactos.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/iphlpapi/resinfo… > ============================================================================== > --- trunk/reactos/dll/win32/iphlpapi/resinfo_reactos.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/iphlpapi/resinfo_reactos.c [iso-8859-1] Sun Aug 22 22:22:27 2010 > @@ -122,47 +122,24 @@ > > void EnumNameServers( HANDLE RegHandle, PWCHAR Interface, > PVOID Data, EnumNameServersFunc cb ) { > - PWCHAR NameServerString = > - QueryRegistryValueString(RegHandle, L"DhcpNameServer"); > + PWCHAR *NameServerString = > + QueryRegistryValueStringMulti(RegHandle, L"DhcpNameServer"); > + DWORD i; > > if (!NameServerString) > - NameServerString = QueryRegistryValueString(RegHandle, L"NameServer"); > - > - if (NameServerString) { > - /* Now, count the non-empty comma separated */ > - DWORD ch; > - DWORD LastNameStart = 0; > - for (ch = 0; NameServerString[ch]; ch++) { > - if (NameServerString[ch] == ',') { > - if (ch - LastNameStart > 0) { /* Skip empty entries */ > - PWCHAR NameServer = > - malloc(((ch - LastNameStart) + 1) * sizeof(WCHAR)); > - if (NameServer) { > - memcpy(NameServer,NameServerString + LastNameStart, > - (ch - LastNameStart) * sizeof(WCHAR)); > - NameServer[ch - LastNameStart] = 0; > - cb( Interface, NameServer, Data ); > - free(NameServer); > - LastNameStart = ch +1; > - } > - } > - LastNameStart = ch + 1; /* The first one after the comma */ > - } > - } > - if (ch - LastNameStart > 0) { /* A last name? */ > - PWCHAR NameServer = malloc(((ch - LastNameStart) + 1) * sizeof(WCHAR)); > - if (NameServer) { > - memcpy(NameServer,NameServerString + LastNameStart, > - (ch - LastNameStart) * sizeof(WCHAR)); > - NameServer[ch - LastNameStart] = 0; > - cb( Interface, NameServer, Data ); > - free(NameServer); > - } > - } > - ConsumeRegValueString(NameServerString); > - } > -} > - > + NameServerString = QueryRegistryValueStringMulti(RegHandle, L"NameServer"); > + > + if (!NameServerString) return; > + > + for (i = 0; NameServerString[i]; i++) > + { > + cb(Interface, NameServerString[i], Data); > + > + HeapFree(GetProcessHeap(), 0, NameServerString[i]); > + } > + > + HeapFree(GetProcessHeap(), 0, NameServerString); > +} > static void CreateNameServerListEnumNamesFuncCount( PWCHAR Interface, > PWCHAR Server, > PVOID _Data ) { > > > >

14 years, 11 months

4
4
0 0

Fedora 13 Build Error

by James Tabor

I ran into this on Fedora 13, [HOST-CC] tools/cabman/cabinet.cxx tools/cabman/cabinet.cxx: In member function ‘bool CCabinet::CreateSimpleCabinet()’: tools/cabman/cabinet.cxx:2177: error: no matching function for call to ‘stat::stat(char [260], stat*)’ /usr/include/bits/stat.h:40: note: candidates are: stat::stat() /usr/include/bits/stat.h:40: note: stat::stat(const stat&) from http://code.google.com/p/libproxy/issues/detail?id=122 the patch is based on this; http://code.google.com/p/libproxy/issues/attachmentText?id=122&aid=20023750… Index: tools/cabman/cabinet.cxx =================================================================== --- tools/cabman/cabinet.cxx (revision 48297) +++ tools/cabman/cabinet.cxx (working copy) @@ -21,7 +21,8 @@ #if !defined(WIN32) # include <dirent.h> #endif -#if defined(__FreeBSD__) || defined(__APPLE__) +#if !defined(WIN32) || defined(__FreeBSD__) || defined(__APPLE__) +# include <sys/types.h> # include <sys/stat.h> #endif // __FreeBSD__ #include "cabinet.h" Not sure this is right, so~ posted here for fast review and fix, James

14 years, 11 months

3
4
0 0

Re: [ros-dev] [ros-diffs] [akhaldi] 48535: [CMAKE] - Add calc to build.

by Colin Finck

akhaldi(a)svn.reactos.org wrote: > +++ branches/cmake-bringup/base/applications/calc/CMakeLists.txt > [...] > > +file(GLOB_RECURSE SOURCE *.c) > +list(REMOVE_ITEM SOURCE > + ${CMAKE_CURRENT_SOURCE_DIR}/fun_mpfr.c > + ${CMAKE_CURRENT_SOURCE_DIR}/rpn_mpfr.c > + ${CMAKE_CURRENT_SOURCE_DIR}/utl_mpfr.c) Should GLOB_RECURSE and later removing unwanted source files really be the way to go? The only advantage I see are smaller CMakeLists files. On the contrary, it is quite an uncommon way and just adding a single unrelated file into an application's directory could render it unbuildable. Additionally, please take a look at http://public.kitware.com/pipermail/cmake/2010-July/037833.html. According to this user, CMake cannot automatically detect added files when using GLOB_RECURSE. In my opinion, we should list every source file to be included to prevent unexpected side effects. Cheers, Colin

14 years, 11 months

3
2
0 0

Truncating ros-diffs subject lines

by Colin Finck

Hi everybody, Looking at http://www.reactos.org/pipermail/ros-diffs/2010-August/038197.html and the same message in Thunderbird, I now see a need to automatically truncate all subject lines in ros-diffs' mails to 200 characters. I don't think that anybody reads the full commit messages through subject lines, so 200 characters should be enough to identify a commit easily. If there are no objections, I'll try to change this in the next few days. Cheers, Colin

14 years, 11 months

4
4
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 48576: [WIN32K] - co_IntTranslateMouseMessage: properly initialize *HitTest and only send WM_NCHITTEST when the message is going to be removed - co_IntPeekMessage: Prevent possible use of uninitialized HitTest by ProcessMou

by Monkey Libre

2010/8/20, tkreuzer(a)svn.reactos.org <tkreuzer(a)svn.reactos.org>: > Author: tkreuzer > Date: Fri Aug 20 19:24:48 2010 > New Revision: 48576 > > URL: http://svn.reactos.org/svn/reactos?rev=48576&view=rev > Log: > [WIN32K] > - co_IntTranslateMouseMessage: properly initialize *HitTest and only send > WM_NCHITTEST when the message is going to be removed > - co_IntPeekMessage: Prevent possible use of uninitialized HitTest by > ProcessMouseMessage() > - Patch by Jan Roeloffzen [jroeloffzen at hotmail dot com] > - Fixes bug 2139 > > Modified: > trunk/reactos/subsystems/win32/win32k/ntuser/message.c > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/message.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/message.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/message.c [iso-8859-1] Fri > Aug 20 19:24:48 2010 > @@ -579,14 +579,20 @@ > return TRUE; > } > > + *HitTest = HTCLIENT; > + > UserRefObjectCo(Window, &Ref); > > if ( ThreadQueue == Window->pti->MessageQueue && > ThreadQueue->CaptureWindow != Window->hSelf) > { > /* only send WM_NCHITTEST messages if we're not capturing the window! > */ > - *HitTest = co_IntSendMessage(Window->hSelf, WM_NCHITTEST, 0, > - MAKELONG(Msg->pt.x, Msg->pt.y)); > + if (Remove ) > + { > + *HitTest = co_IntSendMessage(Window->hSelf, WM_NCHITTEST, 0, > + MAKELONG(Msg->pt.x, Msg->pt.y)); > + } > + /* else we are going to see this message again, but then with Remove > == TRUE */ > > if (*HitTest == (USHORT)HTTRANSPARENT) > { > @@ -625,10 +631,6 @@ > UserDerefObjectCo(DesktopWindow); > } > } > - } > - else > - { > - *HitTest = HTCLIENT; > } > > if ( gspv.bMouseClickLock && > @@ -800,6 +802,8 @@ > * WM_TIMER messages > */ > CheckMessages: > + > + HitTest = HTNOWHERE; > > Present = FALSE; > > > > -- My translator and tester profile: https://launchpad.net/~monkey-libre -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkq9LEMACgkQY9l6fYUypMPuvACeIZFzQSH3yxMy4wHpQpjK5y9t l34An2b5eHl/hA/AaB8GKbJczM2v0UcT =4iFN -----END PGP SIGNATURE-----

14 years, 11 months

1
0
0 0

MyReactOS: A Proof of Concept

by victor martinez

Hello everyone! In the latest 6 months, Niski and I have been working on a testing ground/proof of concept of a ReactOS community site, currently called the ReactOS Portal. The idea of a ReactOS community site has been floating around for years due to the fact that our followers (Users and Non-Users) keep expecting more info and more features. For this purpose, and having in mind that a ReactOS community site needs to focus on the followers' needs, we've created a light, eyecandy, easy to maintain Drupal-based site, to serve as a testing ground, and also as a proof of concept for the ReactOS Community idea. Despite the fact that the community site is mainly targeted towards the project followers, we didn't forget our developers and official testers needs. We've already included some (hopefully) useful features, and we welcome ideas and suggestions. The community site is made for everyone, by everyone. To avoid quite a lengthy email, we'll enumerate the Top Features we've added. We've also prepared a PDF and a Video, that you can download from this URL: http://download.myreactos.com/?dir=Vicmarcal ) ************ALL+IN+1*********** All the info in ONE click (latest blog posts, forum replies, commits, ML posts and wiki activity) ******Multiblogging System***** Several blogs, managed from just one Blogging System. Easy to post and maintain. ***********IRC-CHAT************ An integrated IRC client for the ReactOS communiy. *********Contact Page********** Redesigned, full of info. **************FAQ************* A much more user oriented FAQ with new Tester and Translator sections. ************RosKarma*********** A new forum module : "More Karma an User has, more reliable he is" and a new Autobanning System : "Bye,bye Trolls". *********Answered Post********* Another new forum module : Answered topics turn Green(easy to spot) and get locked ("No more Necromancy"). ***********Rosquests*********** Another new Forum module : "Use Forum Users skills for ReactOS project". How? Read the PDF or watch the video for more details. **********MultivideoBox******** "An image is worth than thousand words". Videotutorials, ReactOS presentations... and much more. *******Social Networking******* "Facebook, Vimeo, Youtube, and Tweeter integration". And after getting some feedback we've added more features : ***Unlimited/Free FTP account*** Now Official Developers/Testers can have FTP accounts to easily and conveniently share ReactOS ISOs (or any other files). We're also considering integrating the Software Compatibility Database into the Portal. We hope you like it, your feedback is very important, so that we can create a comfortable, highly efficient Community Site. More info in the Video+PDF: http://download.myreactos.com/?dir=Vicmarcal Thanks to all the ReactOS members that are joining, posting and translating. Thanks to everyone involved ;) Victor Martinez Calvo Maciej Bialas www.myreactos.com

14 years, 11 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 48522: [MSAFD] - Update lpcbBytesReturned when FIONREAD is called - Fix the value inside lpErrno when XxxSocketInformation() fails - Pass the unrecognized IOCTLs to the winsock helper (no behavior change for this yet because wsh

by Gabriel ilardi

Was this meant for trunk instead of a branch ? After this commit DNS resolution doesn't work. Thanks. Gabriel. > Date: Thu, 12 Aug 2010 13:13:21 +0000 > To: ros-diffs(a)reactos.org > From: cgutman(a)svn.reactos.org > Subject: [ros-diffs] [cgutman] 48522: [MSAFD] - Update lpcbBytesReturned when FIONREAD is called - Fix the value inside lpErrno when XxxSocketInformation() fails - Pass the unrecognized IOCTLs to the winsock helper (no behavior change for this yet because wshtcpip's WSHIoctl is unimplemented) > > Author: cgutman > Date: Thu Aug 12 13:13:19 2010 > New Revision: 48522 > > URL: http://svn.reactos.org/svn/reactos?rev=48522&view=rev > Log: > [MSAFD] > - Update lpcbBytesReturned when FIONREAD is called > - Fix the value inside lpErrno when XxxSocketInformation() fails > - Pass the unrecognized IOCTLs to the winsock helper (no behavior change for this yet because wshtcpip's WSHIoctl is unimplemented) > > Modified: > trunk/reactos/dll/win32/msafd/misc/dllmain.c > > Modified: trunk/reactos/dll/win32/msafd/misc/dllmain.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msafd/misc/dllma… > ============================================================================== > --- trunk/reactos/dll/win32/msafd/misc/dllmain.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/msafd/misc/dllmain.c [iso-8859-1] Thu Aug 12 13:13:19 2010 > @@ -1910,6 +1910,7 @@ > OUT LPINT lpErrno) > { > PSOCKET_INFORMATION Socket = NULL; > + BOOLEAN NeedsCompletion; > > /* Get the Socket Structure associate to this Socket*/ > Socket = GetSocketStructure(Handle); > @@ -1918,6 +1919,8 @@ > *lpErrno = WSAENOTSOCK; > return SOCKET_ERROR; > } > + > + *lpcbBytesReturned = 0; > > switch( dwIoControlCode ) > { > @@ -1928,17 +1931,44 @@ > return SOCKET_ERROR; > } > Socket->SharedData.NonBlocking = *((PULONG)lpvInBuffer) ? 1 : 0; > - return SetSocketInformation(Socket, AFD_INFO_BLOCKING_MODE, (PULONG)lpvInBuffer, NULL); > + *lpErrno = SetSocketInformation(Socket, AFD_INFO_BLOCKING_MODE, (PULONG)lpvInBuffer, NULL); > + if (*lpErrno != NO_ERROR) > + return SOCKET_ERROR; > + else > + return NO_ERROR; > case FIONREAD: > if( cbOutBuffer < sizeof(INT) || IS_INTRESOURCE(lpvOutBuffer) ) > { > *lpErrno = WSAEFAULT; > return SOCKET_ERROR; > } > - return GetSocketInformation(Socket, AFD_INFO_RECEIVE_CONTENT_SIZE, (PULONG)lpvOutBuffer, NULL); > + *lpErrno = GetSocketInformation(Socket, AFD_INFO_RECEIVE_CONTENT_SIZE, (PULONG)lpvOutBuffer, NULL); > + if (*lpErrno != NO_ERROR) > + { > + *lpcbBytesReturned = sizeof(ULONG); > + return SOCKET_ERROR; > + } > + else > + return NO_ERROR; > default: > - *lpErrno = WSAEINVAL; > - return SOCKET_ERROR; > + *lpErrno = Socket->HelperData->WSHIoctl(Socket->HelperContext, > + Handle, > + Socket->TdiAddressHandle, > + Socket->TdiConnectionHandle, > + dwIoControlCode, > + lpvInBuffer, > + cbInBuffer, > + lpvOutBuffer, > + cbOutBuffer, > + lpcbBytesReturned, > + lpOverlapped, > + lpCompletionRoutine, > + (LPBOOL)&NeedsCompletion); > + > + if (*lpErrno != NO_ERROR) > + return SOCKET_ERROR; > + else > + return NO_ERROR; > } > } > > >

14 years, 11 months

1
0
0 0

[ros-diffs] [akhaldi] 48502: [PSDK] - Move INPUTCONTEXT and ImmLockIMC to the wine imm.h - Add wingdi.h inclusion.

by James Tabor

Hi! Should INPUTCONTEXT be moved or added to dimm.h? Wine headers should be used for wine specific stuff not DDK, SDK or WDK.... James Reference: http://msdn.microsoft.com/en-us/library/aa741229(VS.85).aspx

14 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [sir_richard] 48475: [KERNEL32]: While working on the CMAKE branch, Amine and myself discovered a rather serious issue in kernel32 (and perhaps other libraries as well). Unlike rbuild, CMake does not allow you to export non-existant DLL functions (try it: add "poopyhead" in kernel32's exports under RBuild, and will it export "poopyhead", God knowing what that will actually link to). As an additional feature on top of the "allow non-existing functions to be exported" "feature", beca

by Timo Kreuzer

sir_richard(a)svn.reactos.org wrote: > Author: sir_richard > Date: Sat Aug 7 05:02:58 2010 > New Revision: 48475 > > URL: http://svn.reactos.org/svn/reactos?rev=48475&view=rev > Log: > [KERNEL32]: While working on the CMAKE branch, Amine and myself discovered a rather serious issue in kernel32 (and perhaps other libraries as well). I'm sure noone else could have discovered this issue before. cmake was the key! ;-) > Unlike rbuild, CMake does not allow you to export non-existant DLL functions (try it: add "poopyhead" in kernel32's exports under RBuild, and will it export "poopyhead", God knowing what that will actually link to). > That's an undocumented rbuild feature, called api-out-of-thin-air. To understand how it works, you must study quantum chaos theory. > there already exists a function for: *RtlSetLastNtStatusFromWin32Error*. > I see, with cmake, this feature works on ntdll as well ;-p Regards, Timo PS: build is broken.

14 years, 11 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [sir_richard] 48475: [KERNEL32]: While working on the CMAKE branch, Amine and myself discovered a rather serious issue in kernel32 (and perhaps other libraries as well). Unlike rbuild, CMake does not allow you to export non-existant DLL functions (try it: add "poopyhead" in kernel32's exports under RBuild, and will it export "poopyhead", God knowing what that will actually link to). As an additional feature on top of the "allow non-existing functions to be exported" "feature", beca

by Aleksey Bragin

I have a couple of questions/suggestions. Even if it was a mistake to commit it to trunk, I still express my opinion because I think it's important for the changes to stay in trunk. 1. Channel-based system is preferred to the plain NDEBUG/DPRINT one. Kernel32 should not really be an exception. If there is something wrong, it's better to put some more time into it and fix the actual problem in that debug library. Everyone who ever tried to debug any usermode app in ROS, would understand. 2. .pspec file was also invented as a consistent way to be compatible with different compilers. Winebuild generates stubs for entries marked as "stub", so it's quite controllable. 3. Everything else is great, nice to see that mess being finally cleaned up. WBR, Aleksey Bragin. On Aug 7, 2010, at 9:02 AM, sir_richard(a)svn.reactos.org wrote: > Author: sir_richard > Date: Sat Aug 7 05:02:58 2010 > New Revision: 48475 > > URL: http://svn.reactos.org/svn/reactos?rev=48475&view=rev > Log: > [KERNEL32]: While working on the CMAKE branch...

14 years, 12 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [jgardou] 48465: [WIN32K] - Rewrite NtGdiStretchDIBitsInternal : clearer, faster, stronger (+1 wine test)

by Timo Kreuzer

Hi, Please take care about proper protection of the user mode buffer. The current solution: probe and forget is not safe. Possibilities are: 1) SEH protected copying of the buffer, pass the copy of the buffer to lower level functions -> Easy to do, large overhead for large bitmaps. 2) SEH protected call to a lower level function, passing the user mode buffer. -> Not possible if the lower level function is either allocating any resources (unless also protected by SEH + finally) or can pass execution to 3rd party provided code, like drivers. 3) Be sure to have SEH at the lowest level (DIB) -> Not possible as the function might end up in a driver. 4) Use Mm to protect the buffer. Either with MmSecureVirtualMemory or double mapping using MmProbeAndLockPages + MmGetSystemAddressForMdlSafe. I think 4 is the way to go. While the overhead of remapping should be relatively small compared to a full copy, we are still wasting large ammounts of system address space. MmSecureVirtualMemory might at first sound like a good solution, but beware, it has some pitfalls. While it protects a memory range from being freed, it doesn't protect it from being paged out. That wouldn't be a problem, unless the memory is not backed by the page file, but let say a network resource, which becomes unavailable after a page was paged out. In this case we would get an in page error when trying to access the page, leading to a kernel crash. So unless we can be sure that the memory is backed by the page file, we need to additionally lock the pages into memory to be safe. Final thing to note is that MmSecureVirtualMemory is not implemented yet, but I hope with current work on the VAD code, we'll soon get a present (hint). Regards, Timo jgardou(a)svn.reactos.org wrote: > Author: jgardou > Date: Thu Aug 5 21:12:57 2010 > New Revision: 48465 > > URL: http://svn.reactos.org/svn/reactos?rev=48465&view=rev > Log: > [WIN32K] > - Rewrite NtGdiStretchDIBitsInternal : clearer, faster, stronger (+1 wine test) > > Modified: > branches/reactos-yarotows/subsystems/win32/win32k/objects/dibobj.c > > Modified: branches/reactos-yarotows/subsystems/win32/win32k/objects/dibobj.c > URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/subsystems/win… > ============================================================================== > --- branches/reactos-yarotows/subsystems/win32/win32k/objects/dibobj.c [iso-8859-1] (original) > +++ branches/reactos-yarotows/subsystems/win32/win32k/objects/dibobj.c [iso-8859-1] Thu Aug 5 21:12:57 2010 > @@ -290,7 +290,7 @@ > > if(!(psurfSrc && psurfDst)) > { > - DPRINT1("Error, could not lock surfaces.\n"); > + DPRINT1("Error, could not lock surfaces\n"); > goto cleanup; > } > > @@ -663,15 +663,15 @@ > if(pbmci) > { > pbmci->bmciHeader.bcWidth = psurf->SurfObj.sizlBitmap.cx; > - pbmci->bmciHeader.bcHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > - -psurf->SurfObj.sizlBitmap.cy : > + pbmci->bmciHeader.bcHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > + -psurf->SurfObj.sizlBitmap.cy : > psurf->SurfObj.sizlBitmap.cy; > pbmci->bmciHeader.bcPlanes = 1; > pbmci->bmciHeader.bcBitCount = BitsPerFormat(psurf->SurfObj.iBitmapFormat); > } > Info->bmiHeader.biWidth = psurf->SurfObj.sizlBitmap.cx; > - Info->bmiHeader.biHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > - -psurf->SurfObj.sizlBitmap.cy : > + Info->bmiHeader.biHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > + -psurf->SurfObj.sizlBitmap.cy : > psurf->SurfObj.sizlBitmap.cy;; > Info->bmiHeader.biPlanes = 1; > Info->bmiHeader.biBitCount = BitsPerFormat(psurf->SurfObj.iBitmapFormat); > @@ -711,15 +711,15 @@ > case 8: > Info->bmiHeader.biClrUsed = 0; > > - /* If the bitmap if a DIB section and has the same format than what > + /* If the bitmap if a DIB section and has the same format than what > * we're asked, go ahead! */ > - if((psurf->hSecure) && > + if((psurf->hSecure) && > (BitsPerFormat(psurf->SurfObj.iBitmapFormat) == bpp)) > { > if(Usage == DIB_RGB_COLORS) > { > unsigned int colors = min(psurf->ppal->NumColors, 1 << bpp); > - > + > if(pbmci) > { > for(i=0; i < colors; i++) > @@ -773,7 +773,7 @@ > rgbTriples[i].rgbtGreen = pDcPal->IndexedColors[i].peGreen; > rgbTriples[i].rgbtBlue = pDcPal->IndexedColors[i].peBlue; > } > - > + > rgbQuads[i].rgbRed = pDcPal->IndexedColors[i].peRed; > rgbQuads[i].rgbGreen = pDcPal->IndexedColors[i].peGreen; > rgbQuads[i].rgbBlue = pDcPal->IndexedColors[i].peBlue; > @@ -822,7 +822,7 @@ > { > for(g = 0; g <= 5; g++) > { > - for(b = 0; b <= 5; b++) > + for(b = 0; b <= 5; b++) > { > colorTriple->rgbtRed = (r * 0xff) / 5; > colorTriple->rgbtGreen = (g * 0xff) / 5; > @@ -935,7 +935,7 @@ > /* Restore them */ > Info->bmiHeader.biWidth = width; > Info->bmiHeader.biHeight = height; > - > + > if(!hBmpDest) > { > DPRINT1("Unable to create a DIB Section!\n"); > @@ -972,7 +972,7 @@ > _SEH2_TRY > { > RtlCopyMemory(Bits, pDIBits, DIB_GetDIBImageBytes (width, height, bpp)); > - } > + } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > { > Status = _SEH2_GetExceptionCode(); > @@ -1021,95 +1021,104 @@ > UINT cjMaxBits, > HANDLE hcmXform) > { > - HBITMAP hBitmap, hOldBitmap = NULL; > - HDC hdcMem = NULL; > + PDC pdc; > + INT ret = 0; > + LONG height; > + LONG width; > + WORD planes, bpp; > + DWORD compr, size; > + HBITMAP hBitmap; > + BOOL fastpath = FALSE; > NTSTATUS Status = STATUS_SUCCESS; > - PVOID pvDIBits; > - INT Ret = 0; > + > > if (!Bits || !BitsInfo) > - { > - SetLastWin32Error(ERROR_INVALID_PARAMETER); > return 0; > - } > - > - /* Create a DIB Section, data will be probed there */ > - hBitmap = NtGdiCreateDIBSection(hDC, > - NULL, > - 0, > - BitsInfo, > - Usage, > - 0, > - 0, > - 0, > - &pvDIBits); > - > - if(!hBitmap) > - { > - DPRINT1("Failed to create a DIB.\n"); > - return 0; > - } > - > - /* Set bits */ > - _SEH2_TRY > - { > - ProbeForRead(Bits, cjMaxBits, 1); > - RtlCopyMemory(pvDIBits, Bits, DIB_GetDIBImageBytes(BitsInfo->bmiHeader.biWidth, > - BitsInfo->bmiHeader.biHeight, > - BitsInfo->bmiHeader.biBitCount)); > - } > - _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > - { > - Status = _SEH2_GetExceptionCode(); > - } > - _SEH2_END > - > - if(!NT_SUCCESS(Status)) > - { > - DPRINT1("Error : Could not read DIB bits\n"); > - SetLastNtError(Status); > - goto cleanup; > - } > - > - hdcMem = NtGdiCreateCompatibleDC(0); > - if(!hdcMem) > - { > - DPRINT1("Failed to create a memory DC!"); > - goto cleanup; > - } > - > - hOldBitmap = NtGdiSelectBitmap(hdcMem, hBitmap); > - if(!hOldBitmap) > - { > - DPRINT1("Could not select the DIB into the memory DC\n"); > - goto cleanup; > - } > - > - /* Do we want to stretch ? */ > - if((SrcWidth == DestWidth) && (SrcHeight == DestHeight)) > - { > - Ret = NtGdiBitBlt(hDC, XDest, YDest, XDest + DestWidth, YDest + DestHeight, > - hdcMem, XSrc, YSrc, ROP, 0, 0); > - } > - else > - { > - Ret = NtGdiStretchBlt(hDC, XDest, YDest, XDest + DestWidth, YDest + DestHeight, > - hdcMem, XSrc, YSrc, XSrc + SrcWidth, YSrc + SrcHeight, > - ROP, 0); > - } > - > - if(Ret) > - Ret = SrcHeight ; > - > + > + if (!(pdc = DC_LockDc(hDC))) return 0; > + > + > + _SEH2_TRY > + { > + ProbeForRead(BitsInfo, cjMaxInfo, 1); > + ProbeForRead(Bits, cjMaxBits, 1); > + if (DIB_GetBitmapInfo( &BitsInfo->bmiHeader, &width, &height, &planes, &bpp, &compr, &size ) == -1) > + { > + DPRINT1("Invalid bitmap\n"); > + Status = STATUS_INVALID_PARAMETER; > + } > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Status = _SEH2_GetExceptionCode(); > + } > + _SEH2_END > + > + if(!NT_SUCCESS(Status)) > + { > + DPRINT1("Error, failed to read the DIB bits\n"); > + goto cleanup; > + } > + > + if (width < 0) > + { > + DPRINT1("Bitmap has a negative width\n"); > + return 0; > + } > + > + hBitmap = NtGdiGetDCObject(hDC, OBJ_BITMAP); > + > + if (XDest == 0 && YDest == 0 && XSrc == 0 && XSrc == 0 && > + DestWidth == SrcWidth && DestHeight == SrcHeight && > + compr == BI_RGB && > + ROP == SRCCOPY) > + { > + BITMAP bmp; > + if (IntGdiGetObject(hBitmap, sizeof(bmp), &bmp) == sizeof(bmp)) > + { > + if (bmp.bmBitsPixel == bpp && > + bmp.bmWidth == SrcWidth && > + bmp.bmHeight == SrcHeight && > + bmp.bmPlanes == planes) > + fastpath = TRUE; > + } > + } > + > + if (fastpath) > + { > + /* fast path */ > + DPRINT1("using fast path\n"); > + ret = IntSetDIBits( pdc, hBitmap, 0, height, Bits, BitsInfo, Usage); > + } > + else > + { > + /* slow path - need to use StretchBlt */ > + HBITMAP hOldBitmap; > + HPALETTE hpal = NULL; > + HDC hdcMem; > + PVOID pvBits; > + > + hdcMem = NtGdiCreateCompatibleDC( hDC ); > + hBitmap = DIB_CreateDIBSection(pdc, BitsInfo, Usage, &pvBits, NULL, 0, 0); > + RtlCopyMemory(pvBits, Bits, cjMaxBits); > + hOldBitmap = NtGdiSelectBitmap( hdcMem, hBitmap ); > + > + /* Origin for DIBitmap may be bottom left (positive biHeight) or top > + left (negative biHeight) */ > + ret = NtGdiStretchBlt( hDC, XDest, YDest, DestWidth, DestHeight, > + hdcMem, XSrc, abs(height) - SrcHeight - YSrc, > + SrcWidth, SrcHeight, ROP, 0 ); > + if(hpal) > + GdiSelectPalette(hdcMem, hpal, FALSE); > + if(ret) > + ret = SrcHeight; > + NtGdiSelectBitmap( hdcMem, hOldBitmap ); > + NtGdiDeleteObjectApp( hdcMem ); > + GreDeleteObject( hBitmap ); > + } > cleanup: > - if(hdcMem) > - { > - if(hOldBitmap) NtGdiSelectBitmap(hdcMem, hOldBitmap); > - NtGdiDeleteObjectApp(hdcMem); > - } > - GreDeleteObject(hBitmap); > - > - return Ret; > + DC_UnlockDc(pdc); > + return ret; > } > > > @@ -1462,7 +1471,7 @@ > hpal = (HPALETTE) 0xFFFFFFFF; > } > } > - else > + else > { > hpal = BuildDIBPalette(bmi); > } > @@ -1563,7 +1572,7 @@ > * Get the info from a bitmap header. > * Return 0 for COREHEADER, 1 for INFOHEADER, -1 for error. > */ > -int > +int > FASTCALL > DIB_GetBitmapInfo( const BITMAPINFOHEADER *header, LONG *width, > LONG *height, WORD *planes, WORD *bpp, DWORD *compr, DWORD *size ) > @@ -1575,7 +1584,7 @@ > *height = core->bcHeight; > *planes = core->bcPlanes; > *bpp = core->bcBitCount; > - *compr = 0; > + *compr = BI_RGB; > *size = 0; > return 0; > } > @@ -1692,10 +1701,10 @@ > ppalEntries[i].peBlue = 0; > ppalEntries[i].peFlags = 0; > } > - > + > lpIndex++; > } > - > + > hpal = PALETTE_AllocPalette(PAL_INDEXED, nNumColors, (ULONG*)ppalEntries, 0, 0, 0); > > ExFreePoolWithTag(ppalEntries, TAG_COLORMAP); > > > >

14 years, 12 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 48461: [NTOSKRNL] - Fixed FsRtlIsNameInExpression to make it properly handle * in expressions - Fix formatting - Patch by Pierre Schweitzer - Fixes everything See issue #5541 for more details.

by Colin Finck

tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Thu Aug 5 12:23:23 2010 > New Revision: 48461 > > URL: http://svn.reactos.org/svn/reactos?rev=48461&view=rev > Log: > [NTOSKRNL] > - Fixed FsRtlIsNameInExpression to make it properly handle * in expressions > - Fix formatting > - Patch by Pierre Schweitzer > - Fixes everything Could you add a test for this to one of our (Winetest-compatible) kernel-mode testing frameworks, so that nobody breaks this again? I know that we haven't decided on a radical test-based development approach yet, but it would certainly be helpful to avoid long trunk locks in the future. Cheers, Colin

14 years, 12 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 48461: [NTOSKRNL] - Fixed FsRtlIsNameInExpression to make it properly handle * in expressions - Fix formatting - Patch by Pierre Schweitzer - Fixes everything See issue #5541 for more details.

by Ged Murphy

tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Thu Aug 5 12:23:23 2010 > New Revision: 48461 > > URL: http://svn.reactos.org/svn/reactos?rev=48461&view=rev > Log: > [NTOSKRNL] > - Fixed FsRtlIsNameInExpression to make it properly handle * in expressions > - Fix formatting > - Patch by Pierre Schweitzer > - Fixes everything Reactos v1.0?

14 years, 12 months

1
0
0 0

Trunk locked

by Aleksey Bragin

Hi, trunk is locked due to reaching critical level of regressions again. Currently the following people have write access: tkreuzer, sir_richard, fireball. If you would like to be on bugfix-committers team, please drop me a line. WBR, Aleksey Bragin.

15 years

3
2
0 0

[ros-diffs] [jgardou] 48359: [WIN32K] - Rewrite NtGdiGetDIBitsInternal, with WINE as a reference. - Get back DIB Section creation to classic BITMAPINFO. This si the beginnig of the end for all this BITMAPV5INFO stuff. It is horrible, BITMAPCOREINFO->

by James Tabor

Hi! BitmapCoreInfo !Should Be! handled in Gdi32 and converted there! The latest BitmapInfo "must be" handled in win32k. So not get it confused. James

15 years

3
4
0 0

Re: [ros-dev] [ros-diffs] [fireball] 48380: - Fix incorrect function definitions. To be submitted upstream.

by Timo Kreuzer

fireball(a)svn.reactos.org schrieb: > - Fix incorrect function definitions. To be submitted upstream. > > I remember just recently joking about all our "Needs to be ...", "Someone should ...", "Please someone ..." commit messages, which usually mean "I'm too lazy to ..." and result in things never being done ;-) Timo

15 years

2
1
0 0

Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch for cmake bringup.

by Ged Murphy

This may be a good time to restructure the tree? http://www.reactos.org/wiki/Techwiki:File_Layout <http://www.reactos.org/wiki/Techwiki:File_Layout> This will make ros much more modular and allow things like minwin to be built. Ged. On 24 July 2010 19:52, <akhaldi(a)svn.reactos.org> wrote: > Author: akhaldi > Date: Sat Jul 24 18:52:44 2010 > New Revision: 48236 > > URL: http://svn.reactos.org/svn/reactos?rev=48236&view=rev > Log: > Create a branch for cmake bringup. > > Added: > branches/cmake-bringup/ (props changed) > - copied from r48235, trunk/reactos/ > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > --- bugtraq:logregex (added) > +++ bugtraq:logregex Sat Jul 24 18:52:44 2010 > @@ -1,0 +1,2 @@ > +([Ii]ssue|[Bb]ug)s? #?(\d+)(,? ?#?(\d+))*(,? ?(and |or )?#?(\d+))? > +(\d+) > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > bugtraq:message = See issue #%BUGID% for more details. > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > bugtraq:url = http://www.reactos.org/bugzilla/show_bug.cgi?id=%BUGID% > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > --- svn:ignore (added) > +++ svn:ignore Sat Jul 24 18:52:44 2010 > @@ -1,0 +1,14 @@ > +*.iso > +makefile.auto > +makefile-*.auto > +config-*.rbuild > +obj-* > +output-* > +reactos > +reactos.* > +RosBE-Logs > +*.sln > +*.ncb > +*.suo > +versionreport.xml > +config.rbuild > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > --- svn:mergeinfo (added) > +++ svn:mergeinfo Sat Jul 24 18:52:44 2010 > @@ -1,0 +1,4 @@ > +/branches/header-work:45691-47721 > +/branches/reactos-yarotows:46372,46848,46966,47800,48026,48064 > +/branches/ros-amd64-bringup:36852 > > +/branches/ros-amd64-bringup/reactos:34711-34712,34741,34743,34770,34780-34782,34803,34812,34839,34842,34864,34870,34874,34877,34908-34909,34917,34965,35323-35324,35347-35348,35361,35436,35509,35515,35588,35655,35683,35739,35746,35762,35771,35777,35781,35789,35805,35823,35827,35902,35904-35906,35942,35947-35949,35952-35953,35966,36011-36013,36172,36360,36380,36388-36389,36393,36397,36445,36475,36502-36503,36505,36570,36614,36852,36898-36899,36930,36936,36949,36951,36958,36961,36964,36969,36972,36987-36988,36990,36992,37019,37322-37323,37333-37334,37434,37472,37475,37536,37820-37821,37868-37869,37873,37990-37991,38013-38014,38092,38100,38148-38151,38264-38265,38268,38355,39151,39333,39335,39345,39639,40120,40122-40123,40125,40127-40128,40155,40247,40324,40608,40753,40926-40928,40986-40987,40989,40991,40993,40995-40996,41000-41001,41027-41030,41044-41045,41047-41050,41052,41070,41082-41086,41097-41098,41101,41449,41479-41480,41484-41485,41499-41500,41502,41531,41536,41540,41546-41547,41549,43080,43426,43451,43454,43506,43566,43574,43598,43600-43602,43604-43605,43677,43682,43757,43775,43836,43838-43840,43852,43857-43858,43860,43905-43907,43952,43954,43965,43969,43979,43981,43992,44002,44036-44037,44039-44040,44044-44045,44053,44065,44095,44123,44143-44144,44205,44238,44257,44259,44294,44338-44339,44385,44389,44391,44426,44460,44467-44468,44470-44471,44499,44501,44503-44504,44506,44510-44512,44521,44523-44526,44530,44540,44601,44634,44639,44772,44818,45124,45126-45127,45430,46394,46404,46478,46511,46523-46524,46526,46534-46535,46537-46539,46589,46805,46868,47472,47846-47847,47878,47882 > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > tsvn:logminsize = 10 > > >

15 years

11
30
0 0

Re: [ros-dev] [ros-diffs] [jgardou] 48359: [WIN32K] - Rewrite NtGdiGetDIBitsInternal, with WINE as a reference. - Get back DIB Section creation to classic BITMAPINFO. This si the beginnig of the end for all this BITMAPV5INFO stuff. It is horrible, BI

by James Tabor

Hi! 2010/7/30 Jérôme Gardou <jerome.gardou(a)laposte.net>: > That's why I began to revert all of this stuff, which is horrible :-) > Regards. > Jérôme. > Oh! That is great news! Good work! James

15 years

1
0
0 0

Rose server will be down for hardware maintenance

by Colin Finck

Hi all, After ongoing sudden crashes on our third server Rose (currently only serving the BuildBot and primary DNS), I highly suspect a hardware failure. This is why I'll let the hosting provider conduct a hardware stress test tomorrow and eventually replace broken parts. So don't be surprised if these services are down tomorrow. I'll do my best to get them up reliably again as soon as possible. Cheers, Colin

15 years

1
1
0 0

Flash player regressed?

by Javier Agustìn Fernàndez Arroyo

could anyone take a look at this? http://www.reactos.org/compat/?show=version&id=839 i have sent a private message to the user asking for a debug log and a bug report...

15 years

1
0
0 0

ReactOS & the Opensource World Conference (Malaga, 2010)

by victor martinez

Opensource World Conference (Malaga, 2010), is accepting papers for the meeting that is going to take place on 27/28 October. "The Open Source World Conference (OSWC) is probably the most important European event related to open source technologies. Following six editions of this conference organized by the regional governments of Andalusia and Extremadura in collaboration with the most important companies in the sector, this conference has become a unique event open to everyone interested in the field of software innovation, from users, social agents and developers, through to business leaders, investors and members of public administrations." Andalusia and Extremadura governments are pushing quite hard toward the Opensource administration.They are working together to use just Opensource apps and OSes in their Universities and Administrations. Actually they have created some Opensource OSes as Guadalinex(a Linux distro) and some opensource organizations to push and support opensource ideas. In this conference companies and investors will meet, so maybe we can find some kind of Companies or Government support. Projects, this year, will be elected by votes. Other projects are pushing quite hard. So as this is not another OpenSource meeting but THE OpenSource meeting, I want you to push and vote. We made in Sourceforge Awards and we can do it again. Creating an user takes less than 1 minute: http://www.opensourceworldconference.com/malaga10/?q=en/user/register Vote "5-star" in this page(after Login): http://www.opensourceworldconference.com/malaga10/?q=node/953 I promise to make my best PR to find in this meeting any ReactOS opportunity. If there is any, I will find it. :) _________________________________________________________________ Accede a tu Hotmail en un solo clic ¡Descárgate Internet Explorer 8 y empieza a disfrutar de todas las ventajas! http://www.ayudartepodria.com/

15 years

1
0
0 0

Re: [ros-dev] [ros-diffs] [akhaldi] 48293: [CMAKE] - Add dxsdk interfaces to build.

by Timo Kreuzer

> +MACRO (MACRO_ADD_DXSDK_INTERFACES) > + > + FOREACH(_in_FILE ${ARGN}) > + > + GET_FILENAME_COMPONENT(FILE ${_in_FILE} NAME_WE) > + > + ADD_CUSTOM_COMMAND( > + OUTPUT ${REACTOS_BINARY_DIR}/include/dxsdk/${FILE}.h > + COMMAND native-widl -I${REACTOS_SOURCE_DIR}/include/dxsdk -I. -I${REACTOS_SOURCE_DIR}/include -I${REACTOS_SOURCE_DIR}/include/psdk -m32 --win32 -h -H ${REACTOS_BINARY_DIR}/include/dxsdk/${FILE}.h ${REACTOS_SOURCE_DIR}/include/dxsdk/${FILE}.idl > + DEPENDS native-widl > + ) > + > + SET_SOURCE_FILES_PROPERTIES( > + ${REACTOS_BINARY_DIR}/include/dxsdk/${FILE}.h > + PROPERTIES > + GENERATED TRUE > + ) > + > + LIST(APPEND DXSDK_HEADERS ${REACTOS_BINARY_DIR}/include/dxsdk/${FILE}.h) > + > + ENDFOREACH(_in_FILE ${ARGN}) > + > +ENDMACRO (MACRO_ADD_DXSDK_INTERFACES) > + > +file(GLOB_RECURSE SOURCE "*.idl") > + > +LIST(REMOVE_ITEM SOURCE ${REACTOS_SOURCE_DIR}/include/dxsdk/axcore.idl) > +LIST(REMOVE_ITEM SOURCE ${REACTOS_SOURCE_DIR}/include/dxsdk/axextend.idl) > +LIST(REMOVE_ITEM SOURCE ${REACTOS_SOURCE_DIR}/include/dxsdk/devenum.idl) > +LIST(REMOVE_ITEM SOURCE ${REACTOS_SOURCE_DIR}/include/dxsdk/dshowasf.idl) > +LIST(REMOVE_ITEM SOURCE ${REACTOS_SOURCE_DIR}/include/dxsdk/dyngraph.idl) > +LIST(REMOVE_ITEM SOURCE ${REACTOS_SOURCE_DIR}/include/dxsdk/vmrender.idl) > + > +MACRO_ADD_DXSDK_INTERFACES(${SOURCE}) > + > +ADD_CUSTOM_TARGET(dxsdk ALL DEPENDS ${DXSDK_HEADERS}) > Beautiful!

15 years

1
0
0 0

Freetype Patented Hinting

by Ros Arm

Hello, A recent CMAKE commit has made me notice that a NOSWPAT option determines if FreeType hinting should be used or not. Please note that the Apple patent on the technology recently expired, and this option is not needed anymore, as hinting should always be enabled. -r

15 years

3
2
0 0

ReactOS x64 edition

by Timo Kreuzer

Hi, I'd like to announce that as of r48278, you can build a full x64 bootcd (including rostests, not rosapps) from trunk. That means from now on, I can quickly see when someone breaks 64 bit compatibility: http://reactos.ath.cx:8081/waterfall So please don't cast PVOID to ULONG ;-) Regards, Timo PS: no, it doesn't boot to desktop

15 years

3
2
0 0

freeldr as PE file

by Timo Kreuzer

Hi I'd like to propose a small change: converting freeldr into a PE file. The current freeldr / setupldr are raw binaries, which makes them easy to handle for the bootsector but it disqualifies them from proper debugging with gdb. A solution is to convert them into PE format. As there is no space to implement a real PE loader in the bootsector, the image must not use a .bss section, this can easily be done with a linker script. I have this working in my WC. With the result we can use gdb for debugging freeldr including symbols. The only thing still to solve is how to remove rsym data from the files, without stripping all symbols. Rsym data makes the file twice as big, too big to be loaded in to real mode memory. Any objections / suggestions? Regards, Timo

15 years

2
3
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 48221: - Fix epic naming fail (DhcpEnabled -> EnableDH

by Johannes Anderwald

> - DWORD Error = ERROR_SUCCESS, DhcpEnabled; > + DWORD Error = ERROR_SUCCESS, DhcpEnabled, Length; > [...] > + Error = RegQueryValueEx(AdapterKey, "EnableDHCP", NULL, NULL, (LPBYTE)&DhcpEnabled, &Length); IMO Length needs to be initialized first > + > + if (Error != ERROR_SUCCESS || Length != sizeof(DWORD)) > DhcpEnabled = 1; > > CloseHandle(AdapterKey); regards Johannes [1] http://msdn.microsoft.com/en-us/library/ms724911%28VS.85%29.aspx

15 years

1
0
0 0

Re: [ros-dev] [ros-diffs] [dreimer] 48036: Bug 5501: [PATCH] Adding Wing32support by Carlo Bramini

by Aleksey Bragin

What's that massive reactos.dff change introduced with this rev? -------------------------------------------------- From: <dreimer(a)svn.reactos.org> Sent: Wednesday, July 14, 2010 2:59 PM To: <ros-diffs(a)reactos.org> Subject: [ros-diffs] [dreimer] 48036: Bug 5501: [PATCH] Adding Wing32support by Carlo Bramini > Author: dreimer > Date: Wed Jul 14 10:59:32 2010 > New Revision: 48036 > > URL: http://svn.reactos.org/svn/reactos?rev=48036&view=rev > Log: > Bug 5501: [PATCH] Adding Wing32 support by Carlo Bramini > > Added: > trunk/reactos/dll/win32/wing32/ > trunk/reactos/dll/win32/wing32/wing32.c (with props) > trunk/reactos/dll/win32/wing32/wing32.rbuild (with props) > trunk/reactos/dll/win32/wing32/wing32.spec (with props) > Modified: > trunk/reactos/boot/bootdata/packages/reactos.dff > trunk/reactos/dll/win32/win32.rbuild

15 years

5
4
0 0

ReactOS compatibility Database --- Still testing in 0.3.11

by Javier Agustìn Fernàndez Arroyo

Hi all, im visiting the compatibility database page frequently, and im still seeing people testing applications against 0.3.1 .... 0.3.11 is too old currently, there have been tons of bugfixes, new features, and overall changes that affect many applications since 0.3.11 release. Lots of them have changed their behavior into ReactOS since those changes. What i want to say is, compatibility with 0.3.11 is quite meaningful right now, due to massive changes in ReactOS lately. Lets use HEAD revisions to test new apps, and report bugs against it :) cheers!

15 years, 1 month

1
0
0 0

[ros-diffs] [jgardou] 47802: Merge 47800 from yarotows branch.

by James Tabor

Jérôme, Need to go through your commit list and check and see which ones need to be pushed to the trunk. So far as I see (read), the changes look good. Thanks, James

15 years, 1 month

3
3
0 0

Build process changes...

by Timo Kreuzer

After Olaf's mentioning of increased buildtimes I'd like to throw 2 different, independent and major changes to our build process into discussion. One is about rbuild and one is about the file layout. I'd like to start with the rbuild related topic. What I suggest only for consideration, is a move away from rbuild and instead using CMake. CMake is available for Windows and *nix, for Windows both as commandline ans as a lightweight gui tool. It is capable of translating a portable buildfile format into different makefile formats, including nmake and project files for VS and CodeBlocks. It seems incredibly fast compared to rbuild and probably provides every feature we ever need. Although the syntax is a tiny bit more complex than rbuild files, it's much better than writing makefiles. Adding support for building with MSVC should be relatively easy. It's not really a suggestion, as I'm not sure about all the details, but I think it's worth reviewing and taking into consideration. The second thing is about the file layout. I will post a seperate mail soon. Regards, Timo

15 years, 1 month

9
11
0 0

Removing the autoregister feature from rbuild

by Eric Kohl

Hi! I want to remove the "autoregister" feature from rbuild. Let me explain why I want to do this. The "autoregister" feature in rbuild is used to automatically add dlls to the syssetup.inf file which require an ole server registration. The ole servers in these dlls will then be registered in the 2nd setup stage. The gain of adding the ole server dlls to syssetup.inf automatically is almost non existant as a developer needs to add an 'autoregister' element to the rbuild file of the dll. For example: <autoregister infsection="OleControlDlls" type="DllInstall" /> The corresponding line in the 'OleControlsDll' section of syssetup.inf is: 11,,comctl32.dll,2 Please remember that the line above only needs to be added once. Now, what do we loose by generating syssetup.inf automatically? Right now it is only the comments in this file as it is parsed and serialized by the inflib library. OTOH, my future plans for syssetup.inf are severely hampered by the way rbuild handles syssetup.inf because rbuild is not able to create or modify a Unicode version of syssetup.inf. But, a Unicode version of syssetup.inf is required in order to replace the hard-coded creation of the start menu and desktop links in syssetup.dll by a configurable, localizable and Windows compatible inf-based method. And finally since Timo suggested to replace rbuild by cmake: The autoregister feature would surely be one of the victims of this change. So why not drop this almost useless feature now? What do you think? Regards, Eric

15 years, 1 month

5
4
0 0

WHY YOU'VE MADE ROS_SECTION_OBJECT RATHER THAN SECTION?

by Mariusz Gliwiński

Recently, I've been watching MiLoadImageSection(). It takes PVOID casted to ROS_SECTION_OBJECT parameter. Why is that? Furthermore, it isn't really a same definition as on MS Windows (XP). Why You've made this difference? -- Pozdrawiam, Mariusz Gliwiński

15 years, 1 month

1
0
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 47761: [FBTUSB] - Import the FreeBT USB generic bluetooth driver (abandoned) - Some slight modifications to make it build - WMI is currently commented out because our WMI headers are lacking (particularly wmistr.h)

by Ged Murphy

Not again. Why on earth do we need a bluetooth driver when we don't even have a stable OS to run it on? On 12 June 2010 13:46, Aleksey Bragin <aleksey(a)reactos.org> wrote: > Even though it's abandoned, I feel it's going to be abandoned in our source > tree too. > > WBR, > Aleksey Bragin. > > > On Jun 12, 2010, at 4:29 AM, cgutman(a)svn.reactos.org wrote: > > Author: cgutman >> Date: Sat Jun 12 00:29:09 2010 >> New Revision: 47761 >> >> URL: http://svn.reactos.org/svn/reactos?rev=47761&view=rev >> Log: >> [FBTUSB] >> - Import the FreeBT USB generic bluetooth driver (abandoned) >> - Some slight modifications to make it build >> - WMI is currently commented out because our WMI headers are lacking >> (particularly wmistr.h) >> - Not building by default for now >> > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

15 years, 1 month

5
5
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 47761: [FBTUSB] - Import the FreeBT USB generic bluetooth driver (abandoned) - Some slight modifications to make it build - WMI is currently commented out because our WMI headers are lacking (particularly wmistr.h) - Not building by default for now

by Aleksey Bragin

Even though it's abandoned, I feel it's going to be abandoned in our source tree too. WBR, Aleksey Bragin. On Jun 12, 2010, at 4:29 AM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Sat Jun 12 00:29:09 2010 > New Revision: 47761 > > URL: http://svn.reactos.org/svn/reactos?rev=47761&view=rev > Log: > [FBTUSB] > - Import the FreeBT USB generic bluetooth driver (abandoned) > - Some slight modifications to make it build > - WMI is currently commented out because our WMI headers are > lacking (particularly wmistr.h) > - Not building by default for now

15 years, 1 month

1
0
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 47761: [FBTUSB] - Import the FreeBT USB generic bluetooth driver (abandoned) - Some slight modifications to make it build - WMI is currently commented out because our WMI headers are lacking (particularly wmistr.h) - Not bui

by Ged Murphy

On 12 June 2010 01:29, <cgutman(a)svn.reactos.org> wrote: > > - WMI is currently commented out because our WMI headers are lacking > (particularly wmistr.h > WMI is completely missing from reactos in every way

15 years, 1 month

1
0
0 0

Re: [ros-dev] [ros-diffs] [fireball] 47757: - Merge in changes from Wine-1.1.44 related to supporting the ETO_PDY flag. Unregresses the text rendering in FF 3.5. Thanks to Jan Roeloffzen for help finding this problem and suggesting the right solution.

by Aleksey Bragin

I beg my pardon, I accidentally pasted wrong name there. The real thanks goes to Maarten Kroese (nickname Drazic in the Freenode network). WBR, Aleksey Bragin. On Jun 12, 2010, at 12:19 AM, fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Fri Jun 11 20:18:59 2010 > New Revision: 47757 > > URL: http://svn.reactos.org/svn/reactos?rev=47757&view=rev > Log: > - Merge in changes from Wine-1.1.44 related to supporting the > ETO_PDY flag. Unregresses the text rendering in FF 3.5. Thanks to > Jan Roeloffzen for help finding this problem and suggesting the > right solution. > > Modified: > branches/arwinss/reactos/dll/win32/winent.drv/font.c > branches/arwinss/reactos/subsystems/win32/win32k/gre/font.c

15 years, 1 month

1
0
0 0

Re: [ros-dev] I have a lot of Questions

by Ged Murphy

Hi Ian, Your help would be very much welcome and appreciated. You've actually come at a very good time. Our whole backend, known as RosCMS has just been rewritten and is now at version 4. It's a content management system similar to Joomla, but written to better serve the needs of this project. Whilst the backend is now running and stable, the frontend needs a complete rewrite. We had a design contest a few months ago and this was the winning design : http://img200.imageshack.us/img200/7833/reactoswebsitedesign4.png So far no one has had the time to make a start on it, so we're still running on the now outdated site. What we need is for someone to get involved in bringing this new layout to life. It's probably best if you join the IRC channel and chat to our web designer. He's called Danny and he goes by the nick of DangerGround in IRC. He should be able to give you more info and guidance on what is required. I'm posting this mail to the ros-dev mailing list so he and our other web guys can pick it up. You can continue to converse with me via private mail if you prefer to. Regards, Ged Murphy. From: Ian Hilton [mailto:ian7hilton@gmail.com] Sent: 04 June 2010 02:13 To: dev-interest(a)reactos.org Subject: I have a lot of Questions Hi My name is Ian Joseph Hilton I am a freshman in community college. I consider myself a website developer of sorts in training, and for the past year or so been familiarizing myself with website coding. I have been mostly using Google based programs as my platform, and have so far just barely stuck my toe in the water in attempting to write extensions for Google's chrome browser. My main project is what I call Titanways Teaching (or Tutoring) In Terrific And New ways and was my High school Exhibition project required by the state of California to graduate, and it has got moderate attention. the link is here : http://sites.google.com/site/titanwayssite/ I know what you must be thinking by now most likely that I have lack of what you need and as my Uncle who currently writes programs for Medical Equipment says I need at least two years or so to be taken seriously and not laughed, but it never hurts to ask some things and worst comes to worse I learn some things to point me in new directions which is always great. Anyway I of course have been aware of your ReactOS project for a few years and only recently has it occurred to me that I should inquire somethings regarding it. Note I have not been "Tainted" at all as whatever you are talking about with Microsoft's source code totally goes over my head. I do use XP as my operating system However on a Toshiba NB 305 net-book. This is because a lot of my programs I am satisfied with run on this operating system. My point to that is my net-book has further taught me terms like debugging as not every program will run on it without a little help by doing various things like editing a config file to fit its 1024x600 resolution frame. I has also used Linux Ubuntu and am familiar with Macintosh interface via that is the main platform students use at general educational institutions. Now to get right to the point, right now I might not know much but if there is anyway in the future that I may offer assistance in any form I would be happy to, and also any helpful training or guidance you can point me in in regards to coding website components for ReactOS would be even better. I use mostly opensource alternatives to windows programs anyway such as Open Office.org as I kinda share that feeling with you that Microsoft kinda took a monopolistic view to its commercial applications. I wish to ask how compatible is it currently with opensource apps that run on Java platforms if it is integrated with as well as the web browsers that it is compatible with? I have been familiarizing myself with all three of the basic website rendering engines Trident, Gecko, and Web-kit via the experimental triple engine browser being developed by a Japanese software Company and is known as Lunascape. I also want to know if this OS can support docking software such as Object dock or Rocket-dock and if not what would I say need to do to learn how to make that kind of thing a possibility. I will conclude by saying once again right now you may view me as inexperienced but that I am quickly learning and any pointers I take gratefully and with interest in consideration. High Regards to you, Ian P.S. will be taking Computer Classes in future semesters however it is my opinion that the best in the field should try to learn from scratch ,and so I am going to start by attempting to teach myself to write programs in C/C++ coding and see where that leads

15 years, 1 month

2
1
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 47561: revert 47559 and 47560 (once again... sigh)

by Ged Murphy

Windows buildbot! :) -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of tkreuzer(a)svn.reactos.org Sent: 04 June 2010 01:50 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [tkreuzer] 47561: revert 47559 and 47560 (once again... sigh) Author: tkreuzer Date: Fri Jun 4 02:49:33 2010 New Revision: 47561 URL: http://svn.reactos.org/svn/reactos?rev=47561&view=rev Log: revert 47559 and 47560 (once again... sigh)

15 years, 1 month

2
1
0 0

Communication Problems re 47514 & co.

by Ros Arm

Hello, First I was asked if a certain developer could talk to me regarding ARM3. I said yes, never heard back, and then saw commits done to pfnlist.c. While interesting and useful code, some communication would've been nice in order to talk about the goals, since much of that code is in flux (I feel bad when someone improves a function that I will later remove, as two of the improved functions are only temporary -- the changes to the other functions will remain, obviously). Normally, this would not have been a problem, if not for the strange formatting and the fact this code was now broken and causing a boot regression. I showed up in the #reactos-dev channel and instructed developers on how to fix the problem: remove the entire function and use MiInsertPageInFreeList instead, or fix MiInitializePagingLists to perform its work at DISPATCH_LEVEL instead, by acquiring the PFN lock as it should do. None of this was done, instead "janderwald", in 47514, "Fixed" the ASSERT by saying "Any IRQL lower than DISPATCH_LEVEL" is okay. Janderwald, whoever you are, do you even understand this code? Are you even a kernel-mode developer? Does it make to you that the code would need to assert for low IRQL? The whole point is to validate that the PFN lock is being held. Even if you are not a kernel-mode dev, isn't it clear that all the other assertions are also checking for DISPATCH_LEVEL+? And even if that's not clear, I had written down the solution in the #reactos-dev channel, expecting that probably not many people would figure it out. So I guess some lessons to learn for this project: 1) If you modify someone's code, make sure you test your changes (and preferably don't mess up the formatting) so their code is not now blamed for a boot regression. 2) If someone tells you how to fix their code after it's been messed up, apply the fix. 3) If you choose to roll your own fix, write something useful instead of breaking the function (logic-wise) even more. Again, I'm afraid the problem is most of you are students and don't have work ethics of real employees -- this seems to be the root of many problems this project has had since the last 2 years I've been watching and working on the ARM port. Next steps: - Janderwald: remove your ASSERT hack. Either 1) Remove the ASSERT (stop checking for an invariant that doesn't happen) or 2) Fix the caller (so the invariant holds) - Arthur: changes are appreciated, but let's talk more so you don't end up improving dead code. Carry on! -r

15 years, 2 months

2
2
0 0

Some proposals for roadmap

by Javier Agustìn Fernàndez Arroyo

hello, i have thinking about an easy way to show people the ReactOS roadmap, and there came to my mind two projects where i have submitted some bug reports before joining ReactOS. They use the "milestone" field in their bug reports for the roadmaps, and its a quite clean way to show it, IMO Here are the links Is there any way to do something similar using Bugzilla? (none of these 2 projects use this Bug Management System) http://www.kdenlive.org/mantis/roadmap_page.php http://developer.pidgin.im/roadmap

15 years, 2 months

2
1
0 0

Testbots fail to boot ReactOS since 47510

by Olaf Siejka

Since arty's commit in rev 47510, one of his asserts is being triggered in bot qemu and vbox. This practically lock down both testbots as they cannot cont it. I have two requests: - Could you all refrain from commiting until this problem is resolved? - If this issue is not to be fixed soon enough, can this particular assert be commented out for the time being? Debug log below: WARNING: HalStopProfileInterrupt at hal\halx86\generic\profil.c:24 is UNIMPLEMENTED! Assertion 'KeGetCurrentIrql() == DISPATCH_LEVEL' failed at ARMÂł::PFNLIST line 61 Entered debugger on embedded INT3 at 0x0008:0x808e9b7e. kdb:> bt Eip: <808e9b7f (DbgBreakPoint)> Frames: <8089840f (ARM┬│::PFNLIST:61 (MiInsertInListTail@8))> <808a26cd (ntoskrnl/mm/freelist.c:499 (MmInitializePageList@0))> <8089088b (ARM┬│::INIT:X86:521 (MiInitMachineDependent@4))> <80896a61 (ARM┬│::INIT:1846 (MmArmInitSystem@8))> <808a51f7 (ntoskrnl/mm/mminit.c:388 (MmInitSystem@8))> <8084404b (ntoskrnl/ex/init.c:1008 (ExpInitializeExecutive@8))> <8080450b (ntoskrnl/ke/i386/kiinit.c:564 (KiInitializeKernel@24))> <8080467e (ntoskrnl/include//internal/arch/../i386/ke.h:235 (KiSystemStartupBootStack@0))> <0000000e> Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0x0007767C could not be read: Page not present. *** Fatal System Error: 0x0000001e (0xC0000005,0x80877985,0x80967DC0,0x00000000) Entered debugger on embedded INT3 at 0x0008:0x808e9b84.

15 years, 2 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [janderwald] 47509: [NPFS] - Add more buffer checks - Clear DO_DEVICE_INITIALIZING flag

by Ged Murphy

janderwald(a)svn.reactos.org wrote: > + DeviceObject->Flags &= ~DO_DEVICE_INITIALIZING; This is done by the IO manager for any device objects created in DriverEntry If it's not then we have a bug, but I'm fairly sure it does otherwise we wouldn't be able to open devices from umode :) Ged.

15 years, 2 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 47484: - add explicit braces to avoid ambiguous 'else' - fix deprecated conversion from string constant to 'char*'

by Ged Murphy

This is Wine code, it'll get lost in the next sync On 31 May 2010 05:13, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Mon May 31 06:13:40 2010 > New Revision: 47484 > > URL: http://svn.reactos.org/svn/reactos?rev=47484&view=rev > Log: > - add explicit braces to avoid ambiguous 'else' > - fix deprecated conversion from string constant to 'char*' > > Modified: > trunk/reactos/dll/win32/browseui/internettoolbar.cpp > > Modified: trunk/reactos/dll/win32/browseui/internettoolbar.cpp > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/browseui/interne… > > ============================================================================== > --- trunk/reactos/dll/win32/browseui/internettoolbar.cpp [iso-8859-1] > (original) > +++ trunk/reactos/dll/win32/browseui/internettoolbar.cpp [iso-8859-1] Mon > May 31 06:13:40 2010 > @@ -414,10 +414,16 @@ > { > SMINFO *infoPtr = (SMINFO *)lParam; > if ((infoPtr->dwMask & SMIM_FLAGS) != 0) > + { > if (psmd->uId == FCIDM_MENU_FAVORITES) > + { > infoPtr->dwFlags |= > SMIF_DROPCASCADE; > - else{ > - infoPtr->dwFlags |= > SMIF_TRACKPOPUP;} > + } > + else > + { > + infoPtr->dwFlags |= > SMIF_TRACKPOPUP; > + } > + } > if ((infoPtr->dwMask & SMIM_ICON) != 0) > infoPtr->iIcon = -1; > } > @@ -1213,7 +1219,7 @@ > CComPtr<IObjectWithSite> > objectWithSite; > CComPtr<IContextMenu> contextMenu; > CMINVOKECOMMANDINFO > commandInfo; > - char > *searchGUID = "{169A0691-8DF9-11d1-A1C4-00C04FD75D13}"; > + const char > *searchGUID = "{169A0691-8DF9-11d1-A1C4-00C04FD75D13}"; > HRESULT > hResult; > > // TODO: Query shell if this command is enabled first > > >

15 years, 2 months

2
2
0 0

Re: [ros-dev] [ros-diffs] [mjmartin] 47393: [win32k] - The timer is created usingUserCreateObject. It may be a good idea to save the handle in the timer object so that it can be deleted later. - Dereference the object before attempting to delete it.

by Ged Murphy

There's no lock on the list access. On 29 May 2010 07:51, <mjmartin(a)svn.reactos.org> wrote: > Author: mjmartin > Date: Sat May 29 08:51:03 2010 > New Revision: 47393 > > URL: http://svn.reactos.org/svn/reactos?rev=47393&view=rev > Log: > [win32k] > - The timer is created usingUserCreateObject. It may be a good idea to save > the handle in the timer object so that it can be deleted later. > - Dereference the object before attempting to delete it. > > Modified: > trunk/reactos/subsystems/win32/win32k/ntuser/timer.c > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/timer.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/timer.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/timer.c [iso-8859-1] Sat > May 29 08:51:03 2010 > @@ -50,13 +50,21 @@ > if (!FirstpTmr) > { > FirstpTmr = UserCreateObject(gHandleTable, NULL, &Handle, otTimer, > sizeof(TIMER)); > - if (FirstpTmr) InitializeListHead(&FirstpTmr->ptmrList); > + if (FirstpTmr) > + { > + FirstpTmr->head.h = Handle; > + InitializeListHead(&FirstpTmr->ptmrList); > + } > Ret = FirstpTmr; > } > else > { > Ret = UserCreateObject(gHandleTable, NULL, &Handle, otTimer, > sizeof(TIMER)); > - if (Ret) InsertTailList(&FirstpTmr->ptmrList, &Ret->ptmrList); > + if (Ret) > + { > + Ret->head.h = Handle; > + InsertTailList(&FirstpTmr->ptmrList, &Ret->ptmrList); > + } > } > return Ret; > } > @@ -66,14 +74,17 @@ > FASTCALL > RemoveTimer(PTIMER pTmr) > { > + BOOL Ret = FALSE; > if (pTmr) > { > /* Set the flag, it will be removed when ready */ > RemoveEntryList(&pTmr->ptmrList); > - UserDeleteObject( UserHMGetHandle(pTmr), otTimer); > - return TRUE; > - } > - return FALSE; > + UserDereferenceObject(pTmr); > + Ret = UserDeleteObject( UserHMGetHandle(pTmr), otTimer); > + } > + if (!Ret) DPRINT1("Warning unable to delete timer\n"); > + > + return Ret; > } > > PTIMER > @@ -528,9 +539,7 @@ > { > if ((pTmr) && (pTmr->pti == pti) && (pTmr->pWnd == Window)) > { > - RemoveEntryList(&pTmr->ptmrList); > - UserDeleteObject( UserHMGetHandle(pTmr), otTimer); > - TimersRemoved = TRUE; > + TimersRemoved = RemoveTimer(pTmr); > } > pLE = pTmr->ptmrList.Flink; > pTmr = CONTAINING_RECORD(pLE, TIMER, ptmrList); > @@ -557,9 +566,7 @@ > { > if ((pTmr) && (pTmr->pti == pti)) > { > - RemoveEntryList(&pTmr->ptmrList); > - UserDeleteObject( UserHMGetHandle(pTmr), otTimer); > - TimersRemoved = TRUE; > + TimersRemoved = RemoveTimer(pTmr); > } > pLE = pTmr->ptmrList.Flink; > pTmr = CONTAINING_RECORD(pLE, TIMER, ptmrList); > > >

15 years, 2 months

4
4
0 0

Recent Bootvid Commit

by Ros Arm

Hello! While the state of the original code is horrendous, and removing it was a step in the good direction, this simplified implementation omits many of the optimizations and specific VGA tricks that the original "author" of the code had intended to duplicate. If you'd like, I would be open to talking to eVb (we both have some experience with VGA programming) to create an efficient 4BitBlt routine similar to the original one that has been removed, but one that actually has basis in actual fact and isn't of the nature this original implementation was. I can see the original code was converting packed data into per-plane (planar) data and had special edge handling, but it looks like the original author did not realize this, and most of the modulo-and-shifts appear as bitwise ANDs (compiler optimizations), which is just plain confusing. Since the rest of bootvid is probably the same "quality", we could take a good look at it, both from a coding and legal standpoint, if you'd like. -r Author: gschneider Date: Sun May 30 01:54:47 2010 New Revision: 47431 URL: http://svn.reactos.org/svn/reactos?rev=47431&view=rev Log: [BOOTVID] Dramatically simplify 4bpp blitting routine See issue #5103 for more details. Modified: trunk/reactos/drivers/base/bootvid/i386/vga.c Modified: trunk/reactos/drivers/base/bootvid/i386/vga.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/bootvid/i386/… ============================================================================== --- trunk/reactos/drivers/base/bootvid/i386/vga.c [iso-8859-1] (original) +++ trunk/reactos/drivers/base/bootvid/i386/vga.c [iso-8859-1] Sun May 30 01:54:47 2010 @@ -402,33 +402,20 @@ IN ULONG BitsPerPixel, IN ULONG Delta) { - ULONG LeftAnd, LeftShifted, LeftPlusOne, LeftPos; - ULONG lMask, rMask; - UCHAR NotlMask; - ULONG Distance; - ULONG DistanceMinusLeftBpp; - ULONG SomeYesNoFlag, SomeYesNoFlag2; - PUCHAR PixelPosition, m; - PUCHAR i, k; - ULONG j; - ULONG x; - ULONG Plane; - UCHAR LeftArray[84]; - PUCHAR CurrentLeft; - PUCHAR l; - ULONG LoopCount; - UCHAR pMask, PlaneShift; - BOOLEAN Odd; - UCHAR Value; + ULONG sx, dx, dy; + UCHAR color; + ULONG offset = 0; + const ULONG Bottom = Top + Height; + const ULONG Right = Left + Width; /* Check if the buffer isn't 4bpp */ if (BitsPerPixel != 4) { /* FIXME: TODO */ DbgPrint("Unhandled BitBlt\n" - "%lxx%lx @ (%lx,%lx)\n" - "Bits Per Pixel %lx\n" - "Buffer: %p. Delta: %lx\n", + "%lux%lu @ (%lu|%lu)\n" + "Bits Per Pixel %lu\n" + "Buffer: %p. Delta: %lu\n", Width, Height, Left, @@ -439,181 +426,28 @@ return; } - /* Get the masks and other values */ - LeftAnd = Left & 0x7; - lMask = lMaskTable[LeftAnd]; - Distance = Width + Left; - rMask = rMaskTable[(Distance - 1) & 0x7]; - Left >>= 3; - - /* Set some values */ - SomeYesNoFlag = FALSE; - SomeYesNoFlag2 = FALSE; - Distance = (Distance - 1) >> 3; - DistanceMinusLeftBpp = Distance - Left; - - /* Check if the distance is equal to the left position and add the masks */ - if (Left == Distance) lMask += rMask; - - /* Check if there's no distance offset */ - if (DistanceMinusLeftBpp) - { - /* Set the first flag on */ - SomeYesNoFlag = TRUE; - - /* Decrease offset and check if we still have one */ - if (--DistanceMinusLeftBpp) - { - /* Still have a distance offset */ - SomeYesNoFlag2 = TRUE; - } - } - - /* Calculate initial pixel position */ - PixelPosition = (PUCHAR)VgaBase + (Top * 80) + Left; - - /* Set loop buffer variable */ - i = Buffer; - - /* Switch to mode 0 */ - ReadWriteMode(0); - - /* Leave now if the height is 0 */ - if (Height <= 0) return; - - /* Set more weird values */ - CurrentLeft = &LeftArray[Left]; - NotlMask = ~(UCHAR)lMask; - LeftPlusOne = Left + 1; - LeftShifted = (lMask << 8) | 8; - j = Height; - - /* Start the height loop */ + /* 4bpp blitting */ + dy = Top; do { - /* Start the plane loop */ - Plane = 0; + sx = 0; do { - /* Clear the current value */ - *CurrentLeft = 0; - LoopCount = 0; - - /* Set the buffer loop variable for this loop */ - k = i; - - /* Calculate plane shift and pixel mask */ - PlaneShift = 1 << Plane; - pMask = PixelMask[LeftAnd]; - - /* Check if we have a width */ - if (Width > 0) - { - /* Loop it */ - l = CurrentLeft; - x = Width; - do - { - /* Check if we're odd and increase the loop count */ - Odd = LoopCount & 1 ? TRUE : FALSE; - LoopCount++; - if (Odd) - { - /* Check for the plane shift */ - if (*k & PlaneShift) - { - /* Write the pixel mask */ - *l |= pMask; - } - - /* Increase buffer position */ - k++; - } - else - { - /* Check for plane shift */ - if ((*k >> 4) & PlaneShift) - { - /* Write the pixel mask */ - *l |= pMask; - } - } - - /* Shift the pixel mask */ - pMask >>= 1; - if (!pMask) - { - /* Move to the next current left position and clear it */ - l++; - *l = 0; - - /* Set the pixel mask to 0x80 */ - pMask = 0x80; - } - } while (--x); - } - - /* Set the plane value */ - __outpw(0x3C4, (1 << (Plane + 8) | 2)); - - /* Select the bitmask register and write the mask */ - __outpw(0x3CE, (USHORT)LeftShifted); - - /* Read the current Pixel value */ - Value = READ_REGISTER_UCHAR(PixelPosition); - - /* Add our mask */ - Value = (Value & NotlMask) | *CurrentLeft; - - /* Set current left for the loop, and write new pixel value */ - LeftPos = LeftPlusOne; - WRITE_REGISTER_UCHAR(PixelPosition, Value); - - /* Set loop pixel position and check if we should loop */ - m = PixelPosition + 1; - if (SomeYesNoFlag2) - { - /* Set the bitmask to 0xFF for all 4 planes */ - __outpw(0x3CE, 0xFF08); - - /* Check if we have any distance left */ - if (DistanceMinusLeftBpp > 0) - { - /* Start looping it */ - x = DistanceMinusLeftBpp; - do - { - /* Write the value */ - WRITE_REGISTER_UCHAR(m, LeftArray[LeftPos]); - - /* Go to the next position */ - m++; - LeftPos++; - } while (--x); - } - } - - /* Check if the first flag is on */ - if (SomeYesNoFlag) - { - /* Set the mask value */ - __outpw(0x3CE, (rMask << 8) | 8); - - /* Read the current Pixel value */ - Value = READ_REGISTER_UCHAR(m); - - /* Add our mask */ - Value = (Value & ~(UCHAR)rMask) | LeftArray[LeftPos]; - - /* Set current left for the loop, and write new pixel value */ - WRITE_REGISTER_UCHAR(m, Value); - } - } while (++Plane < 4); - - /* Update pixel position, buffer and height */ - PixelPosition += 80; - i += Delta; - } while (--j); + /* Extract color */ + color = Buffer[offset + sx]; + + /* Calc destination x */ + dx = Left + (sx << 1); + + /* Set two pixels */ + SetPixel(dx, dy, color >> 4); + SetPixel(dx + 1, dy, color & 0x0F); + + sx++; + } while (dx < Right); + offset += Delta; + dy++; + } while (dy < Bottom); } VOID

15 years, 2 months

2
1
0 0

Translations of usrmgr cpl

by Eric Kohl

Hi! It is really funny to see that translators don't seem to understand the simple meaning of: /* * Attention Translators: * DO NOT TRANSLATE THESE RESOURCES YET! */ It means: DO NOT TRANSLATE THESE RESOURCES YET!!!!!!! Got it??? Yes, but why? Because usrmgr is not finished yet from a programmers point of view. Most of the underlying infrastructure ist entirely missing. Right now, usrmgr is completely useless and its look and feel might change without prior notice. So please don't waste your precious time by adding more translations! Please translate other missing texts instead, but leave usrmgr alone. At least as long as the little note at the top is still in place. Thank you very much for your attention! Regards, Eric

15 years, 2 months

2
1
0 0

"- Setup can not handle more than one primary partition per disk."

by Javier Agustìn Fernàndez Arroyo

hello, isnt this string at usetup obsolete? AFAIK usetup does allow more partitions from a long time now....

15 years, 2 months

2
1
0 0

Kernel Question

by ahmet alper parker

Hi all, I am new to this mail group and have a question that probably needs your kind of technical knowledge to answer. I want to use reactos, however, up to its completion, can I use some libraries on windows to replace them? In example, wine libraries can be superseded by original windows libraries if you own them. I want to make the inverse of this simply for security reasons to use a kernel fully opensource and which have a documented api. So can I use ntkrnlos.exe and hal.dll or similar in original windows installations to replace propriety kernel and libraries for security reasons? If yes, which of them should I use, and are they complete to replace them? Also a second question may arise as "the priority of reactos development can be focused on firstly these parts of the project or not?"... Best Regards... Ahmet Alper Parker

15 years, 2 months

5
12
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 47295: [WIN32K / USER32] Convert the window text string from UNICODE_STRING to LARGE_STRING and fix NtUserCreateWindowEx parameters. We currently still pass UNICODE only LARGE_STRINGs, as the rest of the code in w

by James Tabor

Hi! That is for bAnsi:1 to set if ansi. Good job over all! James On Sat, May 22, 2010 at 7:07 AM, Timo Kreuzer <timo.kreuzer(a)web.de> wrote: > Aleksey Bragin wrote: >> Shouldn't the LARGE_UNICODE_STRING be used there instead? >> > On Windows the window name is ANSI for an ANSI caller and UNICODE for a > UNICODE caller. > The class name is always in UNICODE though. > > See also http://www.reactos.org/wiki/Techwiki:Win32k/LARGE_UNICODE_STRING > PS: Still on sick leave.

15 years, 2 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 47309: [KMTEST] - Add support for recovering from crashed tests - Add check to prevent us from running the test every boot - Delete some useless code - Record test result information in the registry - Under the Kmtest\Parameters key, you will find CurrentStage which is the stage that testing is on (almost always 8 if it boots). You will also find <Test Name>SuccessCount which is the number of successful tests, <Test Name>FailureCount which is the number of failed tests, <

by Colin Finck

cgutman(a)svn.reactos.org wrote: > + DbgPrint("%S: %d test executed (0 marked as todo, %d failures), > %d skipped.\n", TestName, total, failures, skipped); Nice! Though testman won't parse this if you don't change "test" to "tests" ;-) Best regards, Colin

15 years, 2 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 47295: [WIN32K / USER32] Convert the window text string from UNICODE_STRING to LARGE_STRING and fix NtUserCreateWindowEx parameters. We currently still pass UNICODE only LARGE_STRINGs, as the rest of the code in win32k expects this. Fixes display of large text windows, like the winzip license. See issue #2900 for more details.

by Aleksey Bragin

Shouldn't the LARGE_UNICODE_STRING be used there instead? WBR, Aleksey. On May 22, 2010, at 5:05 AM, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Sat May 22 03:05:31 2010 > New Revision: 47295 > > URL: http://svn.reactos.org/svn/reactos?rev=47295&view=rev > Log: > [WIN32K / USER32] > Convert the window text string from UNICODE_STRING to LARGE_STRING > and fix NtUserCreateWindowEx parameters. We currently still pass > UNICODE only LARGE_STRINGs, as the rest of the code in win32k > expects this. > Fixes display of large text windows, like the winzip license. > See issue #2900 for more details. > > Modified: > trunk/reactos/dll/win32/user32/windows/window.c > trunk/reactos/include/reactos/win32k/ntuser.h > trunk/reactos/subsystems/win32/win32k/include/window.h > trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c > trunk/reactos/subsystems/win32/win32k/ntuser/message.c > trunk/reactos/subsystems/win32/win32k/ntuser/painting.c > trunk/reactos/subsystems/win32/win32k/ntuser/window.c

15 years, 2 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 47286: [DHCP] - Delete the old dhcp service - Part 1 of x

by Aleksey Bragin

I'm afraid you just deleted all dhcp development history. Please revert these 3 commits and redo them properly using svn copy + svn delete. WBR, Aleksey Bragin. On May 21, 2010, at 9:44 AM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Fri May 21 07:44:35 2010 > New Revision: 47286 > > URL: http://svn.reactos.org/svn/reactos?rev=47286&view=rev > Log: > [DHCP] > - Delete the old dhcp service > - Part 1 of x > > Removed: > trunk/reactos/base/services/dhcp/adapter.c > trunk/reactos/base/services/dhcp/alloc.c > trunk/reactos/base/services/dhcp/api.c > trunk/reactos/base/services/dhcp/compat.c > trunk/reactos/base/services/dhcp/design.txt > trunk/reactos/base/services/dhcp/dhclient.c > trunk/reactos/base/services/dhcp/dhcp.rbuild > trunk/reactos/base/services/dhcp/dhcp.rc > trunk/reactos/base/services/dhcp/dhcpmain.c > trunk/reactos/base/services/dhcp/dispatch.c > trunk/reactos/base/services/dhcp/hash.c > trunk/reactos/base/services/dhcp/include/cdefs.h > trunk/reactos/base/services/dhcp/include/debug.h > trunk/reactos/base/services/dhcp/include/dhcp.h > trunk/reactos/base/services/dhcp/include/dhcpd.h > trunk/reactos/base/services/dhcp/include/dhctoken.h > trunk/reactos/base/services/dhcp/include/hash.h > trunk/reactos/base/services/dhcp/include/inet.h > trunk/reactos/base/services/dhcp/include/osdep.h > trunk/reactos/base/services/dhcp/include/predec.h > trunk/reactos/base/services/dhcp/include/privsep.h > trunk/reactos/base/services/dhcp/include/rosdhcp.h > trunk/reactos/base/services/dhcp/include/site.h > trunk/reactos/base/services/dhcp/include/stdint.h > trunk/reactos/base/services/dhcp/include/sysconf.h > trunk/reactos/base/services/dhcp/include/tree.h > trunk/reactos/base/services/dhcp/include/version.h > trunk/reactos/base/services/dhcp/memory.c > trunk/reactos/base/services/dhcp/options.c > trunk/reactos/base/services/dhcp/pipe.c > trunk/reactos/base/services/dhcp/privsep.c > trunk/reactos/base/services/dhcp/socket.c > trunk/reactos/base/services/dhcp/tables.c > trunk/reactos/base/services/dhcp/timer.c > trunk/reactos/base/services/dhcp/tree.c > trunk/reactos/base/services/dhcp/util.c

15 years, 2 months

4
3
0 0

test

by Timo Kreuzer

test if the list works ;-)

15 years, 2 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [mjmartin] 47226: [win32k] - Change the first parameter type from HWND to PWINDOW_OBJECT for IntKillTimer as it makes more sense. Activate IntSetTimer, already done by James. - Add flag TMRF_DELETEPENDING. Destroy timers whe

by Javier Agustìn Fernàndez Arroyo

at last! All hail mjmartin! :-) On Mon, May 17, 2010 at 9:41 AM, Ged Murphy <gedmurphy(a)gmail.com> wrote: > Congrats, good stuff Michael :) > > -----Original Message----- > From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] > On Behalf Of mjmartin(a)svn.reactos.org > Sent: 15 May 2010 20:41 > To: ros-diffs(a)reactos.org > Subject: [ros-diffs] [mjmartin] 47226: [win32k] - Change the first > parameter type from HWND to PWINDOW_OBJECT for IntKillTimer as it makes more > sense. Activate IntSetTimer, already done by James. - Add flag > TMRF_DELETEPENDING. Destroy timers when this flag is set > > Author: mjmartin > Date: Sat May 15 21:40:33 2010 > New Revision: 47226 > > URL: http://svn.reactos.org/svn/reactos?rev=47226&view=rev > Log: > [win32k] > - Change the first parameter type from HWND to PWINDOW_OBJECT for > IntKillTimer as it makes more sense. > Activate IntSetTimer, already done by James. > - Add flag TMRF_DELETEPENDING. Destroy timers when this flag is set in > ProcessTimers to allow any timers that have expired to have the > WM_SYSTIMER/WM_TIMER messages posted to message queue before being > destroyed. > - Fix error in FindTimer, it was always returning a Timer and it needed to > return NULL if the specified timer did not exist. > - Fix error in PostTimerMessages, need to handle cases where the Window > object is NULL which occurs when requesting messages for any window > belonging to the thread. > - In co_IntPeekMessage, simply call PostTimerMessages to have > WM_SYSTIMER/WM_TIMER messages posted for expired timers. Remove call to old > timer message handling. > - TODO: Code using the old timer implementation needs removed. > - Fixes bugs #2393, #3634, #2835. Commit dedicated to JT and Mr. Roboto. > > Modified: > trunk/reactos/subsystems/win32/win32k/include/timer.h > trunk/reactos/subsystems/win32/win32k/main/dllmain.c > trunk/reactos/subsystems/win32/win32k/ntuser/caret.c > trunk/reactos/subsystems/win32/win32k/ntuser/message.c > trunk/reactos/subsystems/win32/win32k/ntuser/timer.c > > Modified: trunk/reactos/subsystems/win32/win32k/include/timer.h > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… > > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/include/timer.h [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/include/timer.h [iso-8859-1] Sat > May 15 21:40:33 2010 > @@ -23,12 +23,14 @@ > #define TMRF_ONESHOT 0x0010 > #define TMRF_WAITING 0x0020 > #define TMRF_TIFROMWND 0x0040 > +#define TMRF_DELETEPENDING 0x8000 > > extern PKTIMER MasterTimer; > > NTSTATUS FASTCALL InitTimerImpl(VOID); > -BOOL FASTCALL IntKillTimer(HWND Wnd, UINT_PTR IDEvent, BOOL SystemTimer); > -UINT_PTR FASTCALL IntSetTimer(HWND Wnd, UINT_PTR IDEvent, UINT Elapse, > TIMERPROC TimerFunc, BOOL SystemTimer); > +BOOL FASTCALL DestroyTimersForThread(PTHREADINFO pti); > +BOOL FASTCALL IntKillTimer(PWINDOW_OBJECT Window, UINT_PTR IDEvent, BOOL > SystemTimer); > +UINT_PTR FASTCALL IntSetTimer(PWINDOW_OBJECT Window, UINT_PTR IDEvent, > UINT Elapse, TIMERPROC TimerFunc, INT Type); > PTIMER FASTCALL FindSystemTimer(PMSG); > BOOL FASTCALL > ValidateTimerCallback(PTHREADINFO,PWINDOW_OBJECT,WPARAM,LPARAM); > VOID CALLBACK SystemTimerProc(HWND,UINT,UINT_PTR,DWORD); > > Modified: trunk/reactos/subsystems/win32/win32k/main/dllmain.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ma… > > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/main/dllmain.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/main/dllmain.c [iso-8859-1] Sat > May 15 21:40:33 2010 > @@ -290,6 +290,8 @@ > Win32Thread->TIF_flags |= TIF_INCLEANUP; > DceFreeThreadDCE(Win32Thread); > HOOK_DestroyThreadHooks(Thread); > + /* Cleanup timers */ > + DestroyTimersForThread(Win32Thread); > UnregisterThreadHotKeys(Thread); > /* what if this co_ func crash in umode? what will clean us up then? > */ > co_DestroyThreadWindows(Thread); > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/caret.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/caret.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/caret.c [iso-8859-1] Sat > May 15 21:40:33 2010 > @@ -189,7 +189,7 @@ > ThreadQueue->CaretInfo->Pos.x = X; > ThreadQueue->CaretInfo->Pos.y = Y; > co_IntSendMessage(ThreadQueue->CaretInfo->hWnd, WM_SYSTIMER, > IDCARETTIMER, 0); > - IntSetTimer(ThreadQueue->CaretInfo->hWnd, IDCARETTIMER, > IntGetCaretBlinkTime(), NULL, TRUE); > + IntSetTimer(UserGetWindowObject(ThreadQueue->CaretInfo->hWnd), > IDCARETTIMER, IntGetCaretBlinkTime(), NULL, TMRF_SYSTEM); > } > return TRUE; > } > @@ -302,7 +302,7 @@ > { > co_IntSendMessage(ThreadQueue->CaretInfo->hWnd, WM_SYSTIMER, > IDCARETTIMER, 0); > } > - IntSetTimer(ThreadQueue->CaretInfo->hWnd, IDCARETTIMER, > IntGetCaretBlinkTime(), NULL, TRUE); > + IntSetTimer(UserGetWindowObject(ThreadQueue->CaretInfo->hWnd), > IDCARETTIMER, IntGetCaretBlinkTime(), NULL, TMRF_SYSTEM); > } > > return TRUE; > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/message.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/message.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/message.c [iso-8859-1] Sat > May 15 21:40:33 2010 > @@ -880,23 +880,8 @@ > goto MsgExit; > } > > - if (ThreadQueue->WakeMask & QS_TIMER) > - if (PostTimerMessages(Window)) // If there are timers ready, > - goto CheckMessages; // go back and process them. > - > - // LOL! Polling Timer Queue? How much time is spent doing this? > - /* Check for WM_(SYS)TIMER messages */ > - Present = MsqGetTimerMessage( ThreadQueue, > - Window, > - MsgFilterMin, > - MsgFilterMax, > - &Msg->Msg, > - RemoveMessages); > - if (Present) > - { > - Msg->FreeLParam = FALSE; > - goto MessageFound; > - } > + if (PostTimerMessages(Window)) > + goto CheckMessages; > > if(Present) > { > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/timer.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/timer.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/timer.c [iso-8859-1] Sat > May 15 21:40:33 2010 > @@ -57,7 +57,7 @@ > { > Ret = UserCreateObject(gHandleTable, NULL, &Handle, otTimer, > sizeof(TIMER)); > if (Ret) InsertTailList(&FirstpTmr->ptmrList, &Ret->ptmrList); > - } > + } > return Ret; > } > > @@ -68,8 +68,8 @@ > { > if (pTmr) > { > - RemoveEntryList(&pTmr->ptmrList); > - UserDeleteObject( UserHMGetHandle(pTmr), otTimer); > + /* Set the flag, it will be removed when ready */ > + pTmr->flags |= TMRF_DELETEPENDING; > return TRUE; > } > return FALSE; > @@ -83,7 +83,7 @@ > BOOL Distroy) > { > PLIST_ENTRY pLE; > - PTIMER pTmr = FirstpTmr; > + PTIMER pTmr = FirstpTmr, RetTmr = NULL; > KeEnterCriticalRegion(); > do > { > @@ -96,8 +96,8 @@ > if (Distroy) > { > RemoveTimer(pTmr); > - pTmr = (PTIMER)1; // We are here to remove the timer. > } > + RetTmr = pTmr; > break; > } > > @@ -106,7 +106,7 @@ > } while (pTmr != FirstpTmr); > KeLeaveCriticalRegion(); > > - return pTmr; > + return RetTmr; > } > > PTIMER > @@ -162,15 +162,15 @@ > return TRUE; > } > > -// Rename it to IntSetTimer after move. > UINT_PTR FASTCALL > -InternalSetTimer( PWINDOW_OBJECT Window, > +IntSetTimer( PWINDOW_OBJECT Window, > UINT_PTR IDEvent, > UINT Elapse, > TIMERPROC TimerFunc, > INT Type) > { > PTIMER pTmr; > + UINT Ret= IDEvent; > LARGE_INTEGER DueTime; > DueTime.QuadPart = (LONGLONG)(-10000000); > > @@ -195,6 +195,24 @@ > { > DPRINT("Adjusting uElapse\n"); > Elapse = 10; > + } > + > + if ((Window == NULL) && (!(Type & TMRF_SYSTEM))) > + { > + IntLockWindowlessTimerBitmap(); > + IDEvent = RtlFindClearBitsAndSet(&WindowLessTimersBitMap, 1, > HintIndex); > + > + if (IDEvent == (UINT_PTR) -1) > + { > + IntUnlockWindowlessTimerBitmap(); > + DPRINT1("Unable to find a free window-less timer id\n"); > + SetLastWin32Error(ERROR_NO_SYSTEM_RESOURCES); > + return 0; > + } > + > + HintIndex = ++IDEvent; > + IntUnlockWindowlessTimerBitmap(); > + Ret = IDEvent; > } > > pTmr = FindTimer(Window, IDEvent, Type, FALSE); > @@ -215,18 +233,23 @@ > pTmr->pWnd = Window; > pTmr->cmsCountdown = Elapse; > pTmr->cmsRate = Elapse; > - pTmr->flags = Type|TMRF_INIT; // Set timer to Init mode. > pTmr->pfn = TimerFunc; > pTmr->nID = IDEvent; > - > - InsertTailList(&FirstpTmr->ptmrList, &pTmr->ptmrList); > + pTmr->flags = Type|TMRF_INIT; // Set timer to Init mode. > + } > + > + pTmr->cmsCountdown = Elapse; > + pTmr->cmsRate = Elapse; > + if (pTmr->flags & TMRF_DELETEPENDING) > + { > + pTmr->flags &= ~TMRF_DELETEPENDING; > } > > // Start the timer thread! > - KeSetTimer(MasterTimer, DueTime, NULL); > - > - if (!pTmr->nID) return 1; > - return pTmr->nID; > + if (pTmr == FirstpTmr) > + KeSetTimer(MasterTimer, DueTime, NULL); > + > + return Ret; > } > > // > @@ -248,7 +271,7 @@ > { > // Need to start gdi syncro timers then start timer with Hang App proc > // that calles Idle process so the screen savers will know to run...... > - InternalSetTimer(NULL, 0, 1000, SystemTimerProc, TMRF_RIT); > + IntSetTimer(NULL, 0, 1000, SystemTimerProc, TMRF_RIT); > } > > UINT_PTR > @@ -256,14 +279,14 @@ > SystemTimerSet( PWINDOW_OBJECT Window, > UINT_PTR nIDEvent, > UINT uElapse, > - TIMERPROC lpTimerFunc) > + TIMERPROC lpTimerFunc) > { > if (Window && Window->pti->pEThread->ThreadsProcess != > PsGetCurrentProcess()) > { > SetLastWin32Error(ERROR_ACCESS_DENIED); > return 0; > } > - return InternalSetTimer( Window, nIDEvent, uElapse, lpTimerFunc, > TMRF_SYSTEM); > + return IntSetTimer( Window, nIDEvent, uElapse, lpTimerFunc, > TMRF_SYSTEM); > } > > BOOL > @@ -279,28 +302,23 @@ > > if (!pTmr) return FALSE; > > - if (Window && ((ULONG_PTR)Window != 1)) > - { > - if (!Window->Wnd) return FALSE; > - } > - > pti = PsGetCurrentThreadWin32Thread(); > ThreadQueue = pti->MessageQueue; > > KeEnterCriticalRegion(); > + > do > { > if ( (pTmr->flags & TMRF_READY) && > (pTmr->pti == pti) && > - (pTmr->pWnd == Window)) > + ((pTmr->pWnd == Window) || (Window == NULL) ) ) > { > - ASSERT((ULONG_PTR)Window != 1); > - Msg.hwnd = Window->hSelf; > + Msg.hwnd = (pTmr->pWnd) ? pTmr->pWnd->hSelf : 0; > Msg.message = (pTmr->flags & TMRF_SYSTEM) ? WM_SYSTIMER : > WM_TIMER; > Msg.wParam = (WPARAM) pTmr->nID; > Msg.lParam = (LPARAM) pTmr->pfn; > - MsqPostMessage(ThreadQueue, &Msg, FALSE, QS_POSTMESSAGE); > - > + > + MsqPostMessage(ThreadQueue, &Msg, FALSE, QS_TIMER); > pTmr->flags &= ~TMRF_READY; > ThreadQueue->WakeMask = ~QS_TIMER; > Hit = TRUE; > @@ -309,6 +327,7 @@ > pLE = pTmr->ptmrList.Flink; > pTmr = CONTAINING_RECORD(pLE, TIMER, ptmrList); > } while (pTmr != FirstpTmr); > + > KeLeaveCriticalRegion(); > > return Hit; > @@ -330,7 +349,7 @@ > KeQueryTickCount(&TickCount); > Time = MsqCalculateMessageTime(&TickCount); > > - DueTime.QuadPart = (LONGLONG)(-10000000); > + DueTime.QuadPart = (LONGLONG)(-1000000); > > do > { > @@ -341,8 +360,10 @@ > continue; > } > > - if (pTmr->flags & TMRF_INIT) > + if (pTmr->flags & TMRF_INIT) > + { > pTmr->flags &= ~TMRF_INIT; // Skip this run. > + } > else > { > if (pTmr->cmsCountdown < 0) > @@ -363,16 +384,35 @@ > // Set thread message queue for this timer. > if (pTmr->pti->MessageQueue) > { // Wakeup thread > - pTmr->pti->MessageQueue->WakeMask |= QS_TIMER; > - KeSetEvent(pTmr->pti->MessageQueue->NewMessages, > IO_NO_INCREMENT, FALSE); > + if (pTmr->pti->MessageQueue->WakeMask & QS_POSTMESSAGE) > + KeSetEvent(pTmr->pti->MessageQueue->NewMessages, > IO_NO_INCREMENT, FALSE); > } > } > } > - pTmr->cmsCountdown = pTmr->cmsRate; > + if (pTmr->flags & TMRF_DELETEPENDING) > + { > + DPRINT("Removing Timer %x from List\n", pTmr); > + > + /* FIXME: Fix this!!!! */ > +/* > + if (!pTmr->pWnd) > + { > + DPRINT1("Clearing Bits for WindowLess Timer\n"); > + IntLockWindowlessTimerBitmap(); > + RtlSetBits(&WindowLessTimersBitMap, pTmr->nID, 1); > + IntUnlockWindowlessTimerBitmap(); > + } > +*/ > + RemoveEntryList(&pTmr->ptmrList); > + UserDeleteObject( UserHMGetHandle(pTmr), otTimer); > + } > + else > + pTmr->cmsCountdown = pTmr->cmsRate; > } > else > pTmr->cmsCountdown -= Time - TimeLast; > } > + > pLE = pTmr->ptmrList.Flink; > pTmr = CONTAINING_RECORD(pLE, TIMER, ptmrList); > } while (pTmr != FirstpTmr); > @@ -391,7 +431,7 @@ > // > // > UINT_PTR FASTCALL > -IntSetTimer(HWND Wnd, UINT_PTR IDEvent, UINT Elapse, TIMERPROC TimerFunc, > BOOL SystemTimer) > +InternalSetTimer(HWND Wnd, UINT_PTR IDEvent, UINT Elapse, TIMERPROC > TimerFunc, BOOL SystemTimer) > { > PWINDOW_OBJECT Window; > UINT_PTR Ret = 0; > @@ -477,17 +517,66 @@ > return 0; > } > > - > +if (Ret == 0) ASSERT(FALSE); > return Ret; > } > > - > BOOL FASTCALL > -IntKillTimer(HWND Wnd, UINT_PTR IDEvent, BOOL SystemTimer) > +DestroyTimersForThread(PTHREADINFO pti) > +{ > + PLIST_ENTRY pLE; > + PTIMER pTmr = FirstpTmr; > + BOOL TimersRemoved = FALSE; > + > + if (FirstpTmr == NULL) > + return FALSE; > + > + KeEnterCriticalRegion(); > + > + do > + { > + if ((pTmr) && (pTmr->pti == pti)) > + { > + pTmr->flags &= ~TMRF_READY; > + pTmr->flags |= TMRF_DELETEPENDING; > + TimersRemoved = TRUE; > + } > + pLE = pTmr->ptmrList.Flink; > + pTmr = CONTAINING_RECORD(pLE, TIMER, ptmrList); > + } while (pTmr != FirstpTmr); > + > + KeLeaveCriticalRegion(); > + > + return TimersRemoved; > +} > + > + > +BOOL FASTCALL > +IntKillTimer(PWINDOW_OBJECT Window, UINT_PTR IDEvent, BOOL SystemTimer) > +{ > + PTIMER pTmr = NULL; > + DPRINT("IntKillTimer Window %x id %p systemtimer %s\n", > + Window, IDEvent, SystemTimer ? "TRUE" : "FALSE"); > + > + if (IDEvent == 0) > + return FALSE; > + > + pTmr = FindTimer(Window, IDEvent, SystemTimer ? TMRF_SYSTEM : 0, TRUE); > + return pTmr ? TRUE : FALSE; > +} > + > + > +// > +// > +// Old Kill Timer > +// > +// > +BOOL FASTCALL > +InternalKillTimer(HWND Wnd, UINT_PTR IDEvent, BOOL SystemTimer) > { > PTHREADINFO pti; > PWINDOW_OBJECT Window = NULL; > - > + > DPRINT("IntKillTimer wnd %x id %p systemtimer %s\n", > Wnd, IDEvent, SystemTimer ? "TRUE" : "FALSE"); > > @@ -495,7 +584,7 @@ > if (Wnd) > { > Window = UserGetWindowObject(Wnd); > - > + > if (! MsqKillTimer(pti->MessageQueue, Wnd, > IDEvent, SystemTimer ? WM_SYSTIMER : > WM_TIMER)) > { > @@ -574,7 +663,7 @@ > DPRINT("Enter NtUserSetTimer\n"); > UserEnterExclusive(); > > - RETURN(IntSetTimer(hWnd, nIDEvent, uElapse, lpTimerFunc, FALSE)); > + RETURN(IntSetTimer(UserGetWindowObject(hWnd), nIDEvent, uElapse, > lpTimerFunc, 0)); > > CLEANUP: > DPRINT("Leave NtUserSetTimer, ret=%i\n", _ret_); > @@ -591,12 +680,15 @@ > UINT_PTR uIDEvent > ) > { > + PWINDOW_OBJECT Window; > DECLARE_RETURN(BOOL); > > DPRINT("Enter NtUserKillTimer\n"); > UserEnterExclusive(); > > - RETURN(IntKillTimer(hWnd, uIDEvent, FALSE)); > + Window = UserGetWindowObject(hWnd); > + > + RETURN(IntKillTimer(Window, uIDEvent, FALSE)); > > CLEANUP: > DPRINT("Leave NtUserKillTimer, ret=%i\n", _ret_); > @@ -620,7 +712,7 @@ > UserEnterExclusive(); > > // This is wrong, lpTimerFunc is NULL! > - RETURN(IntSetTimer(hWnd, nIDEvent, uElapse, lpTimerFunc, TRUE)); > + RETURN(IntSetTimer(UserGetWindowObject(hWnd), nIDEvent, uElapse, > lpTimerFunc, TMRF_SYSTEM)); > > CLEANUP: > DPRINT("Leave NtUserSetSystemTimer, ret=%i\n", _ret_); > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

15 years, 2 months

2
1
0 0

Concerning regedit r47251: inform the user that search is complete

by Gregor Schneider

Hi Michael, there is no need to hardcode the messagebox output language to english. In the resource files a string exists for what you're doing: IDS_FINISHEDFIND (probably already loaded into a string in the code somewhere). Thanks, Gregor

15 years, 2 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [mjmartin] 47226: [win32k] - Change the first parameter type from HWND to PWINDOW_OBJECT for IntKillTimer as it makes more sense. Activate IntSetTimer, already done by James. - Add flag TMRF_DELETEPENDING. Destroy timers when this flag is

by Ged Murphy

Congrats, good stuff Michael :) -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mjmartin(a)svn.reactos.org Sent: 15 May 2010 20:41 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [mjmartin] 47226: [win32k] - Change the first parameter type from HWND to PWINDOW_OBJECT for IntKillTimer as it makes more sense. Activate IntSetTimer, already done by James. - Add flag TMRF_DELETEPENDING. Destroy timers when this flag is set Author: mjmartin Date: Sat May 15 21:40:33 2010 New Revision: 47226 URL: http://svn.reactos.org/svn/reactos?rev=47226&view=rev Log: [win32k] - Change the first parameter type from HWND to PWINDOW_OBJECT for IntKillTimer as it makes more sense. Activate IntSetTimer, already done by James. - Add flag TMRF_DELETEPENDING. Destroy timers when this flag is set in ProcessTimers to allow any timers that have expired to have the WM_SYSTIMER/WM_TIMER messages posted to message queue before being destroyed. - Fix error in FindTimer, it was always returning a Timer and it needed to return NULL if the specified timer did not exist. - Fix error in PostTimerMessages, need to handle cases where the Window object is NULL which occurs when requesting messages for any window belonging to the thread. - In co_IntPeekMessage, simply call PostTimerMessages to have WM_SYSTIMER/WM_TIMER messages posted for expired timers. Remove call to old timer message handling. - TODO: Code using the old timer implementation needs removed. - Fixes bugs #2393, #3634, #2835. Commit dedicated to JT and Mr. Roboto. Modified: trunk/reactos/subsystems/win32/win32k/include/timer.h trunk/reactos/subsystems/win32/win32k/main/dllmain.c trunk/reactos/subsystems/win32/win32k/ntuser/caret.c trunk/reactos/subsystems/win32/win32k/ntuser/message.c trunk/reactos/subsystems/win32/win32k/ntuser/timer.c Modified: trunk/reactos/subsystems/win32/win32k/include/timer.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/include/timer.h [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/include/timer.h [iso-8859-1] Sat May 15 21:40:33 2010 @@ -23,12 +23,14 @@ #define TMRF_ONESHOT 0x0010 #define TMRF_WAITING 0x0020 #define TMRF_TIFROMWND 0x0040 +#define TMRF_DELETEPENDING 0x8000 extern PKTIMER MasterTimer; NTSTATUS FASTCALL InitTimerImpl(VOID); -BOOL FASTCALL IntKillTimer(HWND Wnd, UINT_PTR IDEvent, BOOL SystemTimer); -UINT_PTR FASTCALL IntSetTimer(HWND Wnd, UINT_PTR IDEvent, UINT Elapse, TIMERPROC TimerFunc, BOOL SystemTimer); +BOOL FASTCALL DestroyTimersForThread(PTHREADINFO pti); +BOOL FASTCALL IntKillTimer(PWINDOW_OBJECT Window, UINT_PTR IDEvent, BOOL SystemTimer); +UINT_PTR FASTCALL IntSetTimer(PWINDOW_OBJECT Window, UINT_PTR IDEvent, UINT Elapse, TIMERPROC TimerFunc, INT Type); PTIMER FASTCALL FindSystemTimer(PMSG); BOOL FASTCALL ValidateTimerCallback(PTHREADINFO,PWINDOW_OBJECT,WPARAM,LPARAM); VOID CALLBACK SystemTimerProc(HWND,UINT,UINT_PTR,DWORD); Modified: trunk/reactos/subsystems/win32/win32k/main/dllmain.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ma… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/main/dllmain.c [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/main/dllmain.c [iso-8859-1] Sat May 15 21:40:33 2010 @@ -290,6 +290,8 @@ Win32Thread->TIF_flags |= TIF_INCLEANUP; DceFreeThreadDCE(Win32Thread); HOOK_DestroyThreadHooks(Thread); + /* Cleanup timers */ + DestroyTimersForThread(Win32Thread); UnregisterThreadHotKeys(Thread); /* what if this co_ func crash in umode? what will clean us up then? */ co_DestroyThreadWindows(Thread); Modified: trunk/reactos/subsystems/win32/win32k/ntuser/caret.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/ntuser/caret.c [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/ntuser/caret.c [iso-8859-1] Sat May 15 21:40:33 2010 @@ -189,7 +189,7 @@ ThreadQueue->CaretInfo->Pos.x = X; ThreadQueue->CaretInfo->Pos.y = Y; co_IntSendMessage(ThreadQueue->CaretInfo->hWnd, WM_SYSTIMER, IDCARETTIMER, 0); - IntSetTimer(ThreadQueue->CaretInfo->hWnd, IDCARETTIMER, IntGetCaretBlinkTime(), NULL, TRUE); + IntSetTimer(UserGetWindowObject(ThreadQueue->CaretInfo->hWnd), IDCARETTIMER, IntGetCaretBlinkTime(), NULL, TMRF_SYSTEM); } return TRUE; } @@ -302,7 +302,7 @@ { co_IntSendMessage(ThreadQueue->CaretInfo->hWnd, WM_SYSTIMER, IDCARETTIMER, 0); } - IntSetTimer(ThreadQueue->CaretInfo->hWnd, IDCARETTIMER, IntGetCaretBlinkTime(), NULL, TRUE); + IntSetTimer(UserGetWindowObject(ThreadQueue->CaretInfo->hWnd), IDCARETTIMER, IntGetCaretBlinkTime(), NULL, TMRF_SYSTEM); } return TRUE; Modified: trunk/reactos/subsystems/win32/win32k/ntuser/message.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/ntuser/message.c [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/ntuser/message.c [iso-8859-1] Sat May 15 21:40:33 2010 @@ -880,23 +880,8 @@ goto MsgExit; } - if (ThreadQueue->WakeMask & QS_TIMER) - if (PostTimerMessages(Window)) // If there are timers ready, - goto CheckMessages; // go back and process them. - - // LOL! Polling Timer Queue? How much time is spent doing this? - /* Check for WM_(SYS)TIMER messages */ - Present = MsqGetTimerMessage( ThreadQueue, - Window, - MsgFilterMin, - MsgFilterMax, - &Msg->Msg, - RemoveMessages); - if (Present) - { - Msg->FreeLParam = FALSE; - goto MessageFound; - } + if (PostTimerMessages(Window)) + goto CheckMessages; if(Present) { Modified: trunk/reactos/subsystems/win32/win32k/ntuser/timer.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/ntuser/timer.c [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/ntuser/timer.c [iso-8859-1] Sat May 15 21:40:33 2010 @@ -57,7 +57,7 @@ { Ret = UserCreateObject(gHandleTable, NULL, &Handle, otTimer, sizeof(TIMER)); if (Ret) InsertTailList(&FirstpTmr->ptmrList, &Ret->ptmrList); - } + } return Ret; } @@ -68,8 +68,8 @@ { if (pTmr) { - RemoveEntryList(&pTmr->ptmrList); - UserDeleteObject( UserHMGetHandle(pTmr), otTimer); + /* Set the flag, it will be removed when ready */ + pTmr->flags |= TMRF_DELETEPENDING; return TRUE; } return FALSE; @@ -83,7 +83,7 @@ BOOL Distroy) { PLIST_ENTRY pLE; - PTIMER pTmr = FirstpTmr; + PTIMER pTmr = FirstpTmr, RetTmr = NULL; KeEnterCriticalRegion(); do { @@ -96,8 +96,8 @@ if (Distroy) { RemoveTimer(pTmr); - pTmr = (PTIMER)1; // We are here to remove the timer. } + RetTmr = pTmr; break; } @@ -106,7 +106,7 @@ } while (pTmr != FirstpTmr); KeLeaveCriticalRegion(); - return pTmr; + return RetTmr; } PTIMER @@ -162,15 +162,15 @@ return TRUE; } -// Rename it to IntSetTimer after move. UINT_PTR FASTCALL -InternalSetTimer( PWINDOW_OBJECT Window, +IntSetTimer( PWINDOW_OBJECT Window, UINT_PTR IDEvent, UINT Elapse, TIMERPROC TimerFunc, INT Type) { PTIMER pTmr; + UINT Ret= IDEvent; LARGE_INTEGER DueTime; DueTime.QuadPart = (LONGLONG)(-10000000); @@ -195,6 +195,24 @@ { DPRINT("Adjusting uElapse\n"); Elapse = 10; + } + + if ((Window == NULL) && (!(Type & TMRF_SYSTEM))) + { + IntLockWindowlessTimerBitmap(); + IDEvent = RtlFindClearBitsAndSet(&WindowLessTimersBitMap, 1, HintIndex); + + if (IDEvent == (UINT_PTR) -1) + { + IntUnlockWindowlessTimerBitmap(); + DPRINT1("Unable to find a free window-less timer id\n"); + SetLastWin32Error(ERROR_NO_SYSTEM_RESOURCES); + return 0; + } + + HintIndex = ++IDEvent; + IntUnlockWindowlessTimerBitmap(); + Ret = IDEvent; } pTmr = FindTimer(Window, IDEvent, Type, FALSE); @@ -215,18 +233,23 @@ pTmr->pWnd = Window; pTmr->cmsCountdown = Elapse; pTmr->cmsRate = Elapse; - pTmr->flags = Type|TMRF_INIT; // Set timer to Init mode. pTmr->pfn = TimerFunc; pTmr->nID = IDEvent; - - InsertTailList(&FirstpTmr->ptmrList, &pTmr->ptmrList); + pTmr->flags = Type|TMRF_INIT; // Set timer to Init mode. + } + + pTmr->cmsCountdown = Elapse; + pTmr->cmsRate = Elapse; + if (pTmr->flags & TMRF_DELETEPENDING) + { + pTmr->flags &= ~TMRF_DELETEPENDING; } // Start the timer thread! - KeSetTimer(MasterTimer, DueTime, NULL); - - if (!pTmr->nID) return 1; - return pTmr->nID; + if (pTmr == FirstpTmr) + KeSetTimer(MasterTimer, DueTime, NULL); + + return Ret; } // @@ -248,7 +271,7 @@ { // Need to start gdi syncro timers then start timer with Hang App proc // that calles Idle process so the screen savers will know to run...... - InternalSetTimer(NULL, 0, 1000, SystemTimerProc, TMRF_RIT); + IntSetTimer(NULL, 0, 1000, SystemTimerProc, TMRF_RIT); } UINT_PTR @@ -256,14 +279,14 @@ SystemTimerSet( PWINDOW_OBJECT Window, UINT_PTR nIDEvent, UINT uElapse, - TIMERPROC lpTimerFunc) + TIMERPROC lpTimerFunc) { if (Window && Window->pti->pEThread->ThreadsProcess != PsGetCurrentProcess()) { SetLastWin32Error(ERROR_ACCESS_DENIED); return 0; } - return InternalSetTimer( Window, nIDEvent, uElapse, lpTimerFunc, TMRF_SYSTEM); + return IntSetTimer( Window, nIDEvent, uElapse, lpTimerFunc, TMRF_SYSTEM); } BOOL @@ -279,28 +302,23 @@ if (!pTmr) return FALSE; - if (Window && ((ULONG_PTR)Window != 1)) - { - if (!Window->Wnd) return FALSE; - } - pti = PsGetCurrentThreadWin32Thread(); ThreadQueue = pti->MessageQueue; KeEnterCriticalRegion(); + do { if ( (pTmr->flags & TMRF_READY) && (pTmr->pti == pti) && - (pTmr->pWnd == Window)) + ((pTmr->pWnd == Window) || (Window == NULL) ) ) { - ASSERT((ULONG_PTR)Window != 1); - Msg.hwnd = Window->hSelf; + Msg.hwnd = (pTmr->pWnd) ? pTmr->pWnd->hSelf : 0; Msg.message = (pTmr->flags & TMRF_SYSTEM) ? WM_SYSTIMER : WM_TIMER; Msg.wParam = (WPARAM) pTmr->nID; Msg.lParam = (LPARAM) pTmr->pfn; - MsqPostMessage(ThreadQueue, &Msg, FALSE, QS_POSTMESSAGE); - + + MsqPostMessage(ThreadQueue, &Msg, FALSE, QS_TIMER); pTmr->flags &= ~TMRF_READY; ThreadQueue->WakeMask = ~QS_TIMER; Hit = TRUE; @@ -309,6 +327,7 @@ pLE = pTmr->ptmrList.Flink; pTmr = CONTAINING_RECORD(pLE, TIMER, ptmrList); } while (pTmr != FirstpTmr); + KeLeaveCriticalRegion(); return Hit; @@ -330,7 +349,7 @@ KeQueryTickCount(&TickCount); Time = MsqCalculateMessageTime(&TickCount); - DueTime.QuadPart = (LONGLONG)(-10000000); + DueTime.QuadPart = (LONGLONG)(-1000000); do { @@ -341,8 +360,10 @@ continue; } - if (pTmr->flags & TMRF_INIT) + if (pTmr->flags & TMRF_INIT) + { pTmr->flags &= ~TMRF_INIT; // Skip this run. + } else { if (pTmr->cmsCountdown < 0) @@ -363,16 +384,35 @@ // Set thread message queue for this timer. if (pTmr->pti->MessageQueue) { // Wakeup thread - pTmr->pti->MessageQueue->WakeMask |= QS_TIMER; - KeSetEvent(pTmr->pti->MessageQueue->NewMessages, IO_NO_INCREMENT, FALSE); + if (pTmr->pti->MessageQueue->WakeMask & QS_POSTMESSAGE) + KeSetEvent(pTmr->pti->MessageQueue->NewMessages, IO_NO_INCREMENT, FALSE); } } } - pTmr->cmsCountdown = pTmr->cmsRate; + if (pTmr->flags & TMRF_DELETEPENDING) + { + DPRINT("Removing Timer %x from List\n", pTmr); + + /* FIXME: Fix this!!!! */ +/* + if (!pTmr->pWnd) + { + DPRINT1("Clearing Bits for WindowLess Timer\n"); + IntLockWindowlessTimerBitmap(); + RtlSetBits(&WindowLessTimersBitMap, pTmr->nID, 1); + IntUnlockWindowlessTimerBitmap(); + } +*/ + RemoveEntryList(&pTmr->ptmrList); + UserDeleteObject( UserHMGetHandle(pTmr), otTimer); + } + else + pTmr->cmsCountdown = pTmr->cmsRate; } else pTmr->cmsCountdown -= Time - TimeLast; } + pLE = pTmr->ptmrList.Flink; pTmr = CONTAINING_RECORD(pLE, TIMER, ptmrList); } while (pTmr != FirstpTmr); @@ -391,7 +431,7 @@ // // UINT_PTR FASTCALL -IntSetTimer(HWND Wnd, UINT_PTR IDEvent, UINT Elapse, TIMERPROC TimerFunc, BOOL SystemTimer) +InternalSetTimer(HWND Wnd, UINT_PTR IDEvent, UINT Elapse, TIMERPROC TimerFunc, BOOL SystemTimer) { PWINDOW_OBJECT Window; UINT_PTR Ret = 0; @@ -477,17 +517,66 @@ return 0; } - +if (Ret == 0) ASSERT(FALSE); return Ret; } - BOOL FASTCALL -IntKillTimer(HWND Wnd, UINT_PTR IDEvent, BOOL SystemTimer) +DestroyTimersForThread(PTHREADINFO pti) +{ + PLIST_ENTRY pLE; + PTIMER pTmr = FirstpTmr; + BOOL TimersRemoved = FALSE; + + if (FirstpTmr == NULL) + return FALSE; + + KeEnterCriticalRegion(); + + do + { + if ((pTmr) && (pTmr->pti == pti)) + { + pTmr->flags &= ~TMRF_READY; + pTmr->flags |= TMRF_DELETEPENDING; + TimersRemoved = TRUE; + } + pLE = pTmr->ptmrList.Flink; + pTmr = CONTAINING_RECORD(pLE, TIMER, ptmrList); + } while (pTmr != FirstpTmr); + + KeLeaveCriticalRegion(); + + return TimersRemoved; +} + + +BOOL FASTCALL +IntKillTimer(PWINDOW_OBJECT Window, UINT_PTR IDEvent, BOOL SystemTimer) +{ + PTIMER pTmr = NULL; + DPRINT("IntKillTimer Window %x id %p systemtimer %s\n", + Window, IDEvent, SystemTimer ? "TRUE" : "FALSE"); + + if (IDEvent == 0) + return FALSE; + + pTmr = FindTimer(Window, IDEvent, SystemTimer ? TMRF_SYSTEM : 0, TRUE); + return pTmr ? TRUE : FALSE; +} + + +// +// +// Old Kill Timer +// +// +BOOL FASTCALL +InternalKillTimer(HWND Wnd, UINT_PTR IDEvent, BOOL SystemTimer) { PTHREADINFO pti; PWINDOW_OBJECT Window = NULL; - + DPRINT("IntKillTimer wnd %x id %p systemtimer %s\n", Wnd, IDEvent, SystemTimer ? "TRUE" : "FALSE"); @@ -495,7 +584,7 @@ if (Wnd) { Window = UserGetWindowObject(Wnd); - + if (! MsqKillTimer(pti->MessageQueue, Wnd, IDEvent, SystemTimer ? WM_SYSTIMER : WM_TIMER)) { @@ -574,7 +663,7 @@ DPRINT("Enter NtUserSetTimer\n"); UserEnterExclusive(); - RETURN(IntSetTimer(hWnd, nIDEvent, uElapse, lpTimerFunc, FALSE)); + RETURN(IntSetTimer(UserGetWindowObject(hWnd), nIDEvent, uElapse, lpTimerFunc, 0)); CLEANUP: DPRINT("Leave NtUserSetTimer, ret=%i\n", _ret_); @@ -591,12 +680,15 @@ UINT_PTR uIDEvent ) { + PWINDOW_OBJECT Window; DECLARE_RETURN(BOOL); DPRINT("Enter NtUserKillTimer\n"); UserEnterExclusive(); - RETURN(IntKillTimer(hWnd, uIDEvent, FALSE)); + Window = UserGetWindowObject(hWnd); + + RETURN(IntKillTimer(Window, uIDEvent, FALSE)); CLEANUP: DPRINT("Leave NtUserKillTimer, ret=%i\n", _ret_); @@ -620,7 +712,7 @@ UserEnterExclusive(); // This is wrong, lpTimerFunc is NULL! - RETURN(IntSetTimer(hWnd, nIDEvent, uElapse, lpTimerFunc, TRUE)); + RETURN(IntSetTimer(UserGetWindowObject(hWnd), nIDEvent, uElapse, lpTimerFunc, TMRF_SYSTEM)); CLEANUP: DPRINT("Leave NtUserSetSystemTimer, ret=%i\n", _ret_);

15 years, 2 months

1
0
0 0

Re: [ros-dev] Terminal Server Clone

by Love Nystrom

"Jan Blomqvist Kinander" <jan.blomqvist(a)reactos.org> wrote: > Opening many sessions in windows is really bad idea ... for kernel stuff and another csrss, smss problems ... terminal server blue screen, black screen, printers, etc ... so i have an idea for a workaround ... > > Is open a session using createwinstation api ... in that session, create multiples desktops, using createdesktop api, in each desktop will be secure shell replacement, ejecuted using x user credentials (runas) ... the printing is gonna be universal virtual printers that receive the buffer from the win32, and send the emf or pdf to the client ... > Hi Jan & Gonzalo, I'm no expert in this particular area, but don't You think it would be more logical to give each remote a winstation, and not just a desktop on a shared winstation ? Best Regards // Love

15 years, 2 months

2
1
0 0

Open Source Terminal Server

by Jan Blomqvist Kinander

Hi Developers, I have been aproached by a certain Gonzalo from Colombia, he claims to be a developer who wants to make a Terminal Server Clone, I enclose the mail he sent me, please have a look at it and answer him. Yours Sincerely, Jaix Bly >>> Hey Jaix, i'm Gonzalo from Colombia (South America) tecnologia(a)slmsistemas.net I'm a coder, i develop more than 500 utils and apps for terminal server and citrix .... i have a product called Galeon that is a "clon" of terminal server with shell replacement, full duplex sound, universal printer driver, etc ... I want to develop a Open Source Terminal Server based in something like VNC and OpenVPN Opening many sessions in windows is really bad idea ... for kernel stuff and another csrss, smss problems ... terminal server blue screen, black screen, printers, etc ... so i have an idea for a workaround ... Is open a session using createwinstation api ... in that session, create multiples desktops, using createdesktop api, in each desktop will be secure shell replacement, ejecuted using x user credentials (runas) ... the printing is gonna be universal virtual printers that receive the buffer from the win32, and send the emf or pdf to the client ... Using Virtual Channels is a pain in the ass ... because they all travel using only one tcp socket ... (really bad idea) so, problems with video, audio, performance, etc ...i think we can use openvpn to connect to only one port (443 to ssl vpn) and after the vpn is connected, we can open many socket (each service) between the client and the server desktop ... so we can send printing, sound, video, etc ... I have many things already developed ... createwinstation, createdesktop, impersonate users, universal printer, openvpn implementation .. etc ... but i need help in other areas, like the video grabber in the desktop (maybe a modified vnc) i can make a printscreen of each desktop, and send the jpg ... and is working, but is a really bad idea ... This product can merge with ReactOS .. and be the ReactOS terminal server ... https://sourceforge.net/projects/oswts/ What do you think? Do you receive this mail? Thanks, Gonzalo. -- Cordialmente: Ing. Gonzalo Araujo C MCSE, MCSA, MCSD, ITIL, CISSP, C|EH, LPI Desarrollo SLM Sistemas Ltda desarrollo(a)slmsistemas.com tecnologia(a)slmsistemas.net http://www.slmsistemas.com Colombia - Guatemala - Chile - Venezuela <<<

15 years, 2 months

3
2
0 0

Partial build (newbie question)

by Mad Alchemist

Hello! I already have almost latest trunk build of ReactOS installed. Now I want to try modifying some sources, but recompiling whole system takes about 8 hours on my very slow PC. How can I recompile only modified part of the system? I am using RosBE for Linux version 1.5.

15 years, 2 months

2
1
0 0

Regression fixing

by Aleksey Bragin

Hello, as you all know we have quite a lot of regressions recently, and recently they only add up to one another causing annoyances of testers and developers. There is a strong need to change this situation as soon as possible, otherwise the project's future is undetermined. I want to propose a step-by-step approach. Our brave testing team has created a good overview of the most important regressions and bugs we have so far: http://www.reactos.org/wiki/Buglist . Now, very important(!): For the first step I would like ALL developers to drop their current ReactOS-related work, including all work in branches or wherever else and focus ONLY on fixing regressions from that list. The goal is to fix all confirmed regressions that have been introduced, starting from the most recent and going down to the most ancient. All possible ways to remove a regression could be used: starting from a proper fix and finishing with a total revert or commenting out even good code. Process coordination: feel free to commit proper fixes right away, however as for reverts, I, and/or comittee of our core devs, would like to have a final say on whether something should be reverted. I repeat, all other non-regression related commits to the official ReactOS SVN repository are forbidden, even to branches. The only exception may be developers whose access is restricted to branches only. Thank you for understanding, Aleksey Bragin.

15 years, 2 months

6
14
0 0

DecompressBitmap et alumni

by Love Nystrom

Gregor Schneider <grschneider(a)gmail.com> wrote: > Concerning using an internal format: let's assume we got three 8bpp > surfaces (source, destination, pattern), which are quite big pending > for a raster operation. You would convert these three to another > format like 32bpp, process them and convert back? No, of course not, Gregor, You're absolutely right about the 8bpp S/D/P situation. It would be a terrible idea to convert such a simple format to another for a tertiary rop. I think I was thinking about an internal graphic structure for the display context .. ;-) Accumulate all rops to an 32bit DIB internally, unless the physical device is low bpp. Come to think of it, almost anything but RLE is suitable internally, depending on the output color requirements. The graphics primitives for lines, ellipses, and so on can be small enough to separate a few specialized implementations for different bit depths. I guess that's what You do ? (I didn't look yet). Branching for different bit formats in the primitives would be a bad idea though.. Wouldn't You agree ? Best Regards // Love PS. I have a slice-line routine that's faster than an oiled lightning, and it's really small enough that it'd be worth replicating the code for different bit depths. Let me know if you're interested.

15 years, 2 months

1
0
0 0

DecompressBitmap / Decompress4bpp / Decompress8bpp

by Love Nystrom

Hi guys, Sorry for barging in on a discussion about code that's not on my desk, but looking at your code there is something I want to point out. Graphics code need to be *fast*, that's a primary consideration, so I'm taken aback when I look at your inner bit expansion loop. This is horrible from a standpoint of performance. > length = (*bits++) >> shift; > if (length) > { > c = *bits++; > while (length--) > { > if (x >= width) break; > temp = UncompressedBits + (((height - y) * Delta) + x); > x++; > *temp = c; > } > } You're recomputing the start of the bit-run for every pixel you emit, when you should move that calculation out of the inner loop to get high performance. Graphics code is not the arena where you can be lazy and hope that the optimizer will make your inefficient code faster. At the very least You ought to write it something like this: > length = (*bits++) >> shift; > if (length) > { > c = *bits++; > if (x + length > width) { > // RLE encoding error - Bit-run exceeds width > length = width - x; > } > temp = UncompressedBits + ((height - y) * Delta); > x += length; // precompute finishing x > while (length--) > { > *temp++ = c; > } > } As a sideline note I'd like to mention that it's standard practice in graphics libraries to use one unified bitmap format internally to make internal processing like alpha-blend or text rendering or whatever straight forward. The 32bit DIB format is quite suitable, even if it uses the most memory - Graphics never was cheap on memory. Just my penny to the pot Best Regards // Love

15 years, 2 months

2
1
0 0

Need to speak out

by Ros Arm

Hello, This is the second time that work that someone on the ARM Team has worked on has been mostly reverted without any communication with us, and incorrect changes have been added to parts of our work. The Eng function worked on even clearly stated comments such as "Compressed surfaces don't have scanlines!", yet this new patch restores the old incorrect functionality. lDelta cannot be anything but != 0 for compressed data such as RLE or JPG/PNG! And creating the DIB should not decompress the bits. Please read http://www.tech-archive.net/Archive/Development/microsoft.public.developmen… for example. I do not understand how you can believe that "RLE" has a scan-line. I am not a graphics expert by no means, but even I understand this fact: by definition scan-lines in an RLE are dynamic, and a scan-line offset table contains information about that. You do not have to take my word for it, as a simple driver test case will also show that Windows does not decompress RLE data or set lDelta to any other value than 0 with an RLE bitmap. You can find more information on RLE at http://www.fileformat.info/mirror/egff/ch09_03.htm. If you are wondering why there have not been any commits coming lately, recent actions such as these as the cause. -r Author: khornicek Date: Sat May 8 20:09:45 2010 New Revision: 47134 URL: http://svn.reactos.org/svn/reactos?rev=47134&view=rev Log: [WIN32K] - Bring back support for RLE compressed bitmaps. - Merge the decompress functions for 4bb and 8bpp bitmaps to one generic function. - Simplify SURFMEM_bCreateDib a bit by not allowing PNG/JPEG compression at all. See issue #5276 for more details. Modified: trunk/reactos/subsystems/win32/win32k/eng/surface.c Modified: trunk/reactos/subsystems/win32/win32k/eng/surface.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/en… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/eng/surface.c [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/eng/surface.c [iso-8859-1] Sat May 8 20:09:45 2010 @@ -204,48 +204,59 @@ return NewBitmap; } -VOID Decompress4bpp(SIZEL Size, BYTE *CompressedBits, BYTE *UncompressedBits, LONG Delta) -{ - int x = 0; - int y = Size.cy - 1; - int c; - int length; - int width = ((Size.cx+1)/2); - int height = Size.cy - 1; +BOOL DecompressBitmap(SIZEL Size, BYTE *CompressedBits, BYTE *UncompressedBits, LONG Delta, ULONG Format) +{ + INT x = 0; + INT y = Size.cy - 1; + INT c; + INT length; + INT width; + INT height = Size.cy - 1; BYTE *begin = CompressedBits; BYTE *bits = CompressedBits; BYTE *temp; - while (y >= 0) - { - length = *bits++ / 2; - if (length) - { - c = *bits++; - while (length--) - { - if (x >= width) break; - temp = UncompressedBits + (((height - y) * Delta) + x); - x++; - *temp = c; - } - } - else - { - length = *bits++; - switch (length) - { + INT shift = 0; + + if (Format == BMF_4RLE) + shift = 1; + else if(Format != BMF_8RLE) + return FALSE; + + width = ((Size.cx + shift) >> shift); + + _SEH2_TRY + { + while (y >= 0) + { + length = (*bits++) >> shift; + if (length) + { + c = *bits++; + while (length--) + { + if (x >= width) break; + temp = UncompressedBits + (((height - y) * Delta) + x); + x++; + *temp = c; + } + } + else + { + length = *bits++; + switch (length) + { case RLE_EOL: x = 0; y--; break; case RLE_END: - return; + _SEH2_YIELD(return TRUE); case RLE_DELTA: - x += (*bits++)/2; - y -= (*bits++)/2; + x += (*bits++) >> shift; + y -= (*bits++) >> shift; break; default: - length /= 2; + length = length >> shift; while (length--) { c = *bits++; @@ -260,69 +271,18 @@ { bits++; } - } - } - } -} - -VOID Decompress8bpp(SIZEL Size, BYTE *CompressedBits, BYTE *UncompressedBits, LONG Delta) -{ - int x = 0; - int y = Size.cy - 1; - int c; - int length; - int width = Size.cx; - int height = Size.cy - 1; - BYTE *begin = CompressedBits; - BYTE *bits = CompressedBits; - BYTE *temp; - while (y >= 0) - { - length = *bits++; - if (length) - { - c = *bits++; - while (length--) - { - if (x >= width) break; - temp = UncompressedBits + (((height - y) * Delta) + x); - x++; - *temp = c; - } - } - else - { - length = *bits++; - switch (length) - { - case RLE_EOL: - x = 0; - y--; - break; - case RLE_END: - return; - case RLE_DELTA: - x += *bits++; - y -= *bits++; - break; - default: - while (length--) - { - c = *bits++; - if (x < width) - { - temp = UncompressedBits + (((height - y) * Delta) + x); - x++; - *temp = c; - } - } - if ((bits - begin) & 1) - { - bits++; - } - } - } - } + } + } + } + } + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) + { + DPRINT1("Decoding error\n"); + _SEH2_YIELD(return FALSE); + } + _SEH2_END; + + return TRUE; } HBITMAP FASTCALL @@ -362,7 +322,7 @@ pso->cjBits = pso->lDelta * Size.cy; UncompressedFormat = BMF_4BPP; UncompressedBits = EngAllocMem(FL_ZERO_MEMORY, pso->cjBits, TAG_DIB); - Decompress4bpp(Size, (BYTE *)Bits, (BYTE *)UncompressedBits, pso->lDelta); + DecompressBitmap(Size, (BYTE *)Bits, (BYTE *)UncompressedBits, pso->lDelta, Format); } else if (Format == BMF_8RLE) { @@ -370,7 +330,7 @@ pso->cjBits = pso->lDelta * Size.cy; UncompressedFormat = BMF_8BPP; UncompressedBits = EngAllocMem(FL_ZERO_MEMORY, pso->cjBits, TAG_DIB); - Decompress8bpp(Size, (BYTE *)Bits, (BYTE *)UncompressedBits, pso->lDelta); + DecompressBitmap(Size, (BYTE *)Bits, (BYTE *)UncompressedBits, pso->lDelta, Format); } else { @@ -467,6 +427,7 @@ PSURFACE psurf; SIZEL LocalSize; BOOLEAN AllocatedLocally = FALSE; + PVOID DecompressedBits = NULL; /* * First, check the format so we can get the aligned scanline width. @@ -500,17 +461,29 @@ break; case BMF_8RLE: + ScanLine = (BitmapInfo->Width + 3) & ~3; + Compressed = TRUE; + break; case BMF_4RLE: + ScanLine = ((BitmapInfo->Width + 7) & ~7) >> 1; + Compressed = TRUE; + break; + case BMF_JPEG: case BMF_PNG: - Compressed = TRUE; - break; + ASSERT(FALSE); // ENGDDI shouldn't be creating PNGs for drivers ;-) + DPRINT1("No support for JPEG and PNG formats\n"); + return NULL; default: DPRINT1("Invalid bitmap format\n"); return NULL; } + /* Save local bitmap size */ + LocalSize.cy = BitmapInfo->Height; + LocalSize.cx = BitmapInfo->Width; + /* Does the device manage its own surface? */ if (!Bits) { @@ -519,7 +492,8 @@ { /* Note: we should not be seeing this scenario from ENGDDI */ ASSERT(FALSE); - Size = BitmapInfo->Size; + DPRINT1("RLE compressed bitmap requested with no valid bitmap bits\n"); + return NULL; } else { @@ -551,6 +525,22 @@ { /* Should not have asked for user memory */ ASSERT((BitmapInfo->Flags & BMF_USERMEM) == 0); + + if (Compressed) + { + DecompressedBits = EngAllocMem(FL_ZERO_MEMORY, BitmapInfo->Height * ScanLine, TAG_DIB); + + if(!DecompressedBits) + return NULL; + + if(!DecompressBitmap(LocalSize, (BYTE *)Bits, (BYTE *)DecompressedBits, ScanLine, BitmapInfo->Format)) + { + EngFreeMem(DecompressedBits); + return NULL; + } + + BitmapInfo->Format = (BitmapInfo->Format == BMF_4RLE) ? BMF_4BPP : BMF_8BPP; + } } /* Allocate the actual surface object structure */ @@ -564,6 +554,8 @@ else EngFreeMem(Bits); } + if (DecompressedBits) + EngFreeMem(DecompressedBits); return NULL; } @@ -584,11 +576,9 @@ pso->fjBitmap = BitmapInfo->Flags & (BMF_TOPDOWN | BMF_UMPDMEM | BMF_USERMEM); /* Save size and type */ - LocalSize.cy = BitmapInfo->Height; - LocalSize.cx = BitmapInfo->Width; pso->sizlBitmap = LocalSize; pso->iType = STYPE_BITMAP; - + /* Device-managed surface, no flags or dimension */ pso->dhsurf = 0; pso->dhpdev = NULL; @@ -599,48 +589,28 @@ psurf->hSecure = NULL; psurf->hDIBSection = NULL; psurf->flHooks = 0; - + /* Set bits */ - pso->pvBits = Bits; - - /* Check for bitmap type */ - if (!Compressed) - { - /* Number of bits is based on the height times the scanline */ - pso->cjBits = BitmapInfo->Height * ScanLine; - if (BitmapInfo->Flags & BMF_TOPDOWN) - { - /* For topdown, the base address starts with the bits */ - pso->pvScan0 = pso->pvBits; - pso->lDelta = ScanLine; - } - else - { - /* Otherwise we start with the end and go up */ - pso->pvScan0 = (PVOID)((ULONG_PTR)pso->pvBits + pso->cjBits - ScanLine); - pso->lDelta = -ScanLine; - } + if(Compressed) + pso->pvBits = DecompressedBits; + else + pso->pvBits = Bits; + + /* Number of bits is based on the height times the scanline */ + pso->cjBits = BitmapInfo->Height * ScanLine; + if (BitmapInfo->Flags & BMF_TOPDOWN) + { + /* For topdown, the base address starts with the bits */ + pso->pvScan0 = pso->pvBits; + pso->lDelta = ScanLine; } else { - /* Compressed surfaces don't have scanlines! */ - pso->lDelta = 0; - pso->cjBits = BitmapInfo->Size; - - /* Check for JPG or PNG */ - if ((BitmapInfo->Format != BMF_JPEG) && (BitmapInfo->Format != BMF_PNG)) - { - /* Wherever the bit data is */ - pso->pvScan0 = pso->pvBits; - } - else - { - /* Fancy formats don't use a base address */ - pso->pvScan0 = NULL; - ASSERT(FALSE); // ENGDDI shouldn't be creating PNGs for drivers ;-) - } - } - + /* Otherwise we start with the end and go up */ + pso->pvScan0 = (PVOID)((ULONG_PTR)pso->pvBits + pso->cjBits - ScanLine); + pso->lDelta = -ScanLine; + } + /* Finally set the handle and uniq */ pso->hsurf = (HSURF)psurf->BaseObject.hHmgr; pso->iUniq = 0;

15 years, 2 months

3
2
0 0

Server moves and upgrades

by Colin Finck

Hello everybody, We're currently in the process of moving a main server (Buildmaster, ISO-Storage, etc.) to another location and doing upgrades on the other servers. As always, we try to keep the downtime low, but expect short outages in the next few days. You'll be notified when the move is over or if there are any major problems. Best regards, Colin

15 years, 2 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 47071: [NEWINFLIB] - Change Unicode string functions from wcs* to str*W because glibc (Linux build) provides the wcs* functions but they use a wchar_t size of 32 bits instead of the required 16 bits. - Add a str*W to wcs* wrapper (infrosrtl.c) in order to use the wcs* function for the WIN32 build. - Add required str*W functions to the host library. ATTENTION: This might break the build bot although it has been tested on Windows and Linux!!!

by Colin Finck

ekohl(a)svn.reactos.org wrote: > PWSTR utf16_wcschr(PWSTR str, WCHAR c) > +{ > + SIZE_T i; > + > + for(i = 0; str[i] && str[i] != c; i++); > + > + if(str[i]) > + return &str[i]; > + else > + return NULL; > +} > + > +PWSTR strchrW(PWSTR str, WCHAR c) Why do you duplicate the same code for these wide-char string functions here, just under a different name? The utf16_* family of functions in this file was particularly designed to address the issue of different wchar_t lengths on different hosts. It's meant to be used together with the include/host/wcsfuncs.h header. If you need an example, cmlib is one library using these functions (see e.g. "cmlib.h" for the proper header inclusion, "cminit.c" for a use, etc.) Best regards, Colin

15 years, 3 months

2
2
0 0

crt wine sync

by Samuel serapion

Hey guys, Recently<http://source.winehq.org/git/wine.git/?a=history;f=dlls/msvcrt;hb=1ac163316…>wine has made some improvements to its msvcrt and I've taken the time to port them to reactos. changes include: - implement per thread crt locales and many locale functions. - implement/improve support for vc6, vc7, vc8 exceptions. - implement/improve language support functions. - implement/improve many library functions. - implement many secure functions. - use spec file for msvcrt.dll - fix amd64 linking issues. - add msvcirt.dll, msvcr7.dll ,msvc71.dll, msvc80.dll, msvcr90.dll from wine (no longer need to install versions of ms runtime for visual c language apps) changes are divided into different parts but building has not been tested with individual parts. part 1, 2 and 3 include changes to centralize the definition of several key macros (see reactos/wine/exception.h, reactos/wine/config.h, crt/include/internal/wine/cppexcept.h) also on part 2 in scanf.c wcs.c and possibly other files i didn't know what libcntpr expected so i was quite severe hacking out functions and only letting in the minimum necesary to build ntoskrnl and everything else that uses it. part3 includes changes to baseaddress.rbuild that should be revised, i didn't know how to calculate a good base address for the msvcr dlls so i just used the same one and let ntdll reallocate if necesary... part5 applies to rostests. and before you say it... msvcrt_winetest file now crashes with this trace: dll/win32/kernel32/file/create.c:136 (CreateFileW@28) <-- arch didn't check if lpFileName was valid lib/sdk/crt/stdio/file.c:1485 (_wsopen) modules/rostests/winetests/msvcrt/file.c:1179 (test_fopen_fclose_fcloseall)

15 years, 3 months

1
0
0 0

James T - Aleksey B misunderstanding

by Love Nystrom

ros-dev-request(a)reactos.org wrote: >>> Look at this as a signal warning before the ship hits the reef....... >>> The ship has turn into the reef! >>> >> No need to give false signals here, they often lead to loss of investment >> (example from stock trading area). >> > Trying to make money from ReactOS is a bad idea and thinking about > money from ReactOS, makes this idea delusional. > Sorry for barging into Your discussion guys, but I think Aleksey meant that allegorically, not literally ?? Best Regards Love

15 years, 3 months

2
1
0 0

[ros-diffs] [mjmartin] 47059: [win32k] - Fix a problem where application that used WH_CBT hook procedures were receiving destroy window notification on windows that were never created.

by James Tabor

Michael! Good work!!!! Do you think this might be one of the reasons we are reentering co_UserDestroyWindow? The DCE is cleared and (not cached) at first then we go back a second time and hit the assert...? http://www.reactos.org/bugzilla/show_bug.cgi?id=5320

15 years, 3 months

2
1
0 0

USetup meets NewInfLib

by Roel Messiant

Hey, This one's mostly for Eric Kohl. Newinflib seems to be causing some issues for usetup, accessing memory it shouldn't. Attached are some patches that solve this. The newinflib one fixes some pointer arithmetic, which ended up lying about a buffer size. This was already fixed in the host code, so I just applied the same fix to the ros code. The usetup patch is a hackfix. The issue here is that usetup fetches a line from a section, but the line is blank. Usetup treats it as a data line, and reading the data from it results in NULL .. which usetup tries to dereference. I just hackfixed that one because the code hasn't changed, so it must've worked fine with the previous inflib. So the question end up as: is newinflib wrong here by not trying to skip the blank line, or should usetup keep in mind such lines can exist.. or some third option? WBR, Roel Messiant PS: I know patches belong in bugzilla, but the perceived urgency on my side won the decision on where to post them.

15 years, 3 months

2
1
0 0

I need help fixing rbuild and testing builds on *nix machines!

by Eric Kohl

Hi! In order to fix bug #2482 I needed to make inflib Unicode-aware. My local ReactOS setup is curently able to build Boot-CD and Live-CD using Unicode hive*.inf files. Rbuild is the only tool that still uses the original inflib. Could someone who knows more about C++ and STL than I do have a look at rbuild and make it work with the new inflib? I can provide a patch that includes newinflib (Unicode-aware inflib) and my changes to usetup and mkhive. I also need someone who can test the whole patch on a *nix machine. Any volunters? Regards, Eric

15 years, 3 months

3
4
0 0

Live-CD broken!

by Eric Kohl

Hi! Could someone who is building ReactOS on a Linuy system have a look at why mkhive fails when Live-CD is built? Unfortunately I don't have a Linux system for testing. Thanks in advance! Eric

15 years, 3 months

1
0
0 0

Re: [ros-dev] Regression since rev. 46042 from sir_richard

by mrnobo1024

This bug is a lot older than that, I can't remember thread list ever not being crash-prone. From 0.3.11 livecd: ←[7h♣Entered debugger on embedded INT3 at 0x0008:0x808c6fb6. kdb:> proc list PID State Filename *0x00000004 In Memory System 0x00000044 In Memory smss.exe 0x0000007c In Memory csrss.exe 0x000000a0 In Memory winlogon.exe 0x000000bc In Memory services.exe 0x000000c4 In Memory lsass.exe 0x000000f0 In Memory eventlog.exe 0x0000010c In Memory spoolsv.exe 0x00000120 In Memory dhcp.exe 0x0000013c In Memory rpcss.exe 0x00000180 In Memory umpnpmgr.exe 0x00000290 In Memory explorer.exe kdb:> proc attach 0xa0 Attached to process 0x000000a0, thread 0x000000a4. kdb:> thread list TID State Prior. Affinity EBP EIP *0x000000a4 Waiting 8 0x00000001 0x0063fecc 0x7c90697a Assertion 'TempPte.u.Long != 0' failed at ARM┬│::PAGFAULT line 161 Entered debugger on embedded INT3 at 0x0008:0x808c6fb6. *** Fatal System Error: 0x0000001e (0x80000003,0x808C6FB6,0x80957048,0x00000000) Entered debugger on embedded INT3 at 0x0008:0x808c6fbc.

15 years, 3 months

2
1
0 0

Regression since rev. 46042 from sir_richard

by Olaf Siejka

Revision 46042: [KERNEL32/CSRSS]: Register new Win32 threads with CSRSS. Add a bunch of lookup, creation, allocation, hashing and CSR thread management routines from the unused CSRSRV in trunk. [CSRSS]: Bang in the new thread support in a bunch of places, including creating static server threads. It's very hacked and handle duplication doesn't work 100% reliably, but it gets the job done. [CSRSS]: Add CsrGetProcessLuid, CsrImpersonateClient, CsrRevertToSelf, CsrShutdownProcesses, CsrFindProcessForShutdown required for user-mode shutdown. Right now we are able to reliably enumerate user apps (in the user LUID) and then service/system apps (in the LOCAL SYSTEM LUID). triggers regression described here: http://www.reactos.org/bugzilla/show_bug.cgi?id=5318 (KDBG: Thread list command ASSERTs after attaching to process with PID A0 or higher)

15 years, 3 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [sir_richard] 46977: [NTOS]: Enable MmPageEntireDriver by implementing MiSetPagingOfDriver. [NTOS]: Call MiEnablePagingOfDriver from MmLoadSystemImage and implement it. All the work is done other than actually enabling paging, which requi

by Gabriel ilardi

Hi, After this commit ac97 doesn't install anymore, device wizard remains in a loop and the debug log shows: (drivers/wdm/audio/filters/kmixer/kmixer.c:99) KMixer.sys loaded (drivers/wdm/audio/filters/kmixer/kmixer.c:48) KMix_InstallDevice called (drivers/wdm/audio/filters/kmixer/kmixer.c:83) KMix_InstallDevice result 0 (ntoskrnl/io/pnpmgr/pnpmgr.c:202) Warning: Starting a device node without DNF_ADDED Thanks. Gabriel. > Date: Wed, 21 Apr 2010 14:06:01 +0000 > To: ros-diffs(a)reactos.org > From: sir_richard(a)svn.reactos.org > Subject: [ros-diffs] [sir_richard] 46977: [NTOS]: Enable MmPageEntireDriver by implementing MiSetPagingOfDriver. [NTOS]: Call MiEnablePagingOfDriver from MmLoadSystemImage and implement it. All the work is done other than actually enabling paging, which requires system working set support. [NTOS]: Implement MiWriteProtectSystemImage and MiComputeDriverProtection. All the work is done other than actually setting the bits on the pages, since I wanted to avoid too many changes. [NTOS]: MmCheckSystemImage returns STATUS_INVALID_IMAGE_PROTECT, not STATUS_INVALID_IMAGE_FORMAT, so the branch in MmLoadSystemImage needs to check for the correct status code. [NTOS]: Support FLG_SHOW_LDR_SNAPS for the kernel loader. > _________________________________________________________________ Messenger e Hotmail in tasca. Provali sul tuo cellulare! http://new.windowslivemobile.msn.com/it-it/Default.aspx

15 years, 3 months

1
0
0 0

[ros-diffs] [tkreuzer] 46998: Disable gdi batch for SelectObject with fonts. Fixes font regression.

by James Tabor

Not surprised! I guess ReactOS new polices are for hiding the real issues and not fixing them and revert all the correct code. Since the kernel rewrites and the new order of coding, these oddities have now surfaced. The TEB, is inaccessible from kernel mode as in bug 5265 and 5314, and the strange processes access issues in bug 5310. This revert silliness will result in moving the project back to post windows 95 architecture (arwinss). ReactOS is about moving forward and taking chances with innovations from learned information then moving away to make it work even better. Personally, I hope someone will take up where this left off and move on. Good luck! Reference: http://www.reactos.org/bugzilla/show_bug.cgi?id=5265 http://www.reactos.org/bugzilla/show_bug.cgi?id=5310 http://www.reactos.org/bugzilla/show_bug.cgi?id=5314

15 years, 3 months

3
3
0 0

Re: [ros-dev] ShellExecuteEx

by Love Nystrom

Gregor Schneider <grschneider(a)gmail.com> wrote: > That made me think: what happens to this field if the ShellExecuteEx > call succeeds and the flag SEE_MASK_NOCLOSEPROCESS is not set? Since > this check was thought to forward the actual result of the execution i > switched to a simpler and (in my eyes) more reliable code. Plus the > original code did not use the flag noted in the specification. > The link you provided on the other hand makes it look like > ShellExecuteEx always sets this field indendent of any flags passed to > the function. > > To find out the truth one would have to write test cases. It might > well be that the implementation we use is partially incorrect. > Especially when looking at testman (it works again :-O ) @ > shell32_winetest shlexec which still has some failures. Hi Greg, Perhaps You already know, but let's spell it out anyway: hInstApp inherits it's traits from WinExec and LoadModule. WinExec used to be declared HINSTANCE WinExec( LPCSTR CmdLine, UINT CmdShow ), and LoadModule also returned a HINSTANCE. At that time they did return the instance handle, i.e the load address, and it was safe to use these low values as error codes, because they were impossible load addresses (they still are). Even though WinExec/LoadModule's signatures have changed, and we've been given CreateProcess to exert better control, somewhere in the bowels of Microsoft's code I'm convinced it still percolates down to basically the same code to load/launch a module, so the traits remain. And since the shell APIs are mostly just alternate wrappings for standard Win32 APIs, it percolates to there as well. I don't think we need to bother with test cases for this, we could apply some common sense instead. A quick test shows that both WinExec and LoadModule actually just return 33 when they succeed, so we could(/should?) let hInstApp always reflect load status the same way that WinExec/LoadModule does, regardless of the flags. That's the most polite to users of ShellExecuteEx. Then they can error branch on either one. In case of doubt, always wear both belt and suspenders ;) if (ShellExecuteExW( &sei ) == FALSE) return E_FAIL; if ((INT) sei.hInstApp <= 32) return E_UNEXPECTED; Best Regards // Love victor martinez <vicmarcal(a)hotmail.com <mailto:vicmarcal@hotmail.com>> wrote: > > - if (sei.hInstApp <= (HINSTANCE)32) > + if ((INT)sei.hInstApp <= 32) > > As you see i am just learning, so thanks in advance. > To enlighten You: If you look at the assembly listing, You'll see that those two variants generate exactly the same code. Best Regards // Love

15 years, 3 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 46998: Disable gdi batch for SelectObject with fonts. Fixes font regression.

by Gabriel ilardi

Hi Jim, Please don't take this personal, the code has been #iffed out not reverted. I agree with you that we should keep good code, problem is that lately someone introduces a regression with new or modified code (even correct), and the regression stays there forever, we should try to avoid such a case. In this specific case we know the gdibatch code introduced that regression, so my suggestion is: do the commit anyway with a specific roadmap to fix the regression or disable it temporary until the regression is fixed. Perception is really important, what's gonna think about ros someone that tried it before, now after a new release tries it again and sees that what was working before doesn't work anymore or works worse than it did, your references are a good example of this scenario, but see also: 4461 Regression: Notepad Lite doesn't install 4677 Regression: Can't restore minimized windows 4948 Regression: Can't close locale dialog 5276 Regression: shell about dialog doesn't display header bitmap And there are more... I'm not gonna blame win32k only here as regressions are not its exclusivity, it's funny that before uniata we were suggesting people to rename uniata to atapi to test in boxes with sata controllers, now we do the oposite (atapi -> uniata )to let people test in pata. I've mentioned in ros-dev also that ros takes more than 2 minutes in my virtual machine to install when it tooks some seconds before (two hd attached to the primary channel), I'm not able to test ros so frequently now because of this. I've also mentioned that AC97 stopped working, has regressed for several reasons several revisions away, now I'm not being prompted anymore for its driver as 46998... We can't keep working like this, testers should work in a coordinated way with developers, both of them are important, there aren't many skilled testers to be honest just take a look at bugzilla... Sometimes I test and see regressions and don't know what to do anymore, stop testing, tell ros-dev, bug the dev, give up... Gabriel. > Date: Thu, 22 Apr 2010 20:47:52 -0500 > From: jimtabor.rosdev(a)gmail.com > To: ros-dev(a)reactos.org > Subject: [ros-dev] [ros-diffs] [tkreuzer] 46998: Disable gdi batch for SelectObject with fonts. Fixes font regression. > > Not surprised! > > I guess ReactOS new polices are for hiding the real issues and not > fixing them and revert all the correct code. Since the kernel rewrites > and the new order of coding, these oddities have now surfaced. The > TEB, is inaccessible from kernel mode as in bug 5265 and 5314, and the > strange processes access issues in bug 5310. This revert silliness > will result in moving the project back to post windows 95 architecture > (arwinss). ReactOS is about moving forward and taking chances with > innovations from learned information then moving away to make it work > even better. Personally, I hope someone will take up where this left > off and move on. > > Good luck! > > Reference: > > http://www.reactos.org/bugzilla/show_bug.cgi?id=5265 > http://www.reactos.org/bugzilla/show_bug.cgi?id=5310 > http://www.reactos.org/bugzilla/show_bug.cgi?id=5314 > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev _________________________________________________________________ Messenger e Hotmail in tasca. Provali sul tuo cellulare! http://new.windowslivemobile.msn.com/it-it/Default.aspx

15 years, 3 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 46983: [NTOSKRNL] - Replace the broken CM_RESOURCE_LIST_SIZE with a better function that actually works with resource lists that have device-specific data in them (fixes missing device specific data when resources

by Andrew Faulds

Isn't that just a audio driver regression not an Install wizard one? "Starting a device node without DNF_ADDED" On 22 April 2010 14:09, Gabriel ilardi <gabrielilardi(a)hotmail.it> wrote: > Hi, > Device installation wizard has regressed again, now if you try to install > the AC97 driver, it remains in a loop, and ros slows down at the point of > being unusabe, > the debug log shows: > > (ntoskrnl/io/pnpmgr/pnpmgr.c:190) Warning: Starting a device node without > DNF_ADDED or DNF_ENUMERATED (Root\LEGACY_kmixer\0000) > > Thanks, > > Gabriel. > > > Date: Wed, 21 Apr 2010 22:33:12 +0000 > > To: ros-diffs(a)reactos.org > > From: cgutman(a)svn.reactos.org > > Subject: [ros-diffs] [cgutman] 46983: [NTOSKRNL] - Replace the broken > CM_RESOURCE_LIST_SIZE with a better function that actually works with > resource lists that have device-specific data in them (fixes missing device > specific data when resources are retrieved with IoGetDeviceProperty) - > Separate the resource code out of pnpmgr.c and into pnpres.c - Simplify > resource assigning to simply calling one function, IopAssignDeviceResources, > which takes care of the registry configuration, translation, etc. - Set the > DNF_NEED_ENUMERATION_ONLY flag only AFTER the device is actually started not > before - Set DNF_START_FAILED if IRP_MN_START_DEVICE fails - Fix a bug in > IoReportDetectedDevice that wrote the AllocConfig value to wrong place > > > > Author: cgutman > > Date: Thu Apr 22 00:33:11 2010 > > New Revision: 46983 > > > > URL: http://svn.reactos.org/svn/reactos?rev=46983&view=rev > > Log: > > [NTOSKRNL] > > - Replace the broken CM_RESOURCE_LIST_SIZE with a better function that > actually works with resource lists that have device-specific data in them > (fixes missing device specific data when resources are retrieved with > IoGetDeviceProperty) > > - Separate the resource code out of pnpmgr.c and into pnpres.c > > - Simplify resource assigning to simply calling one function, > IopAssignDeviceResources, which takes care of the registry configuration, > translation, etc. > > - Set the DNF_NEED_ENUMERATION_ONLY flag only AFTER the device is > actually started not before > > - Set DNF_START_FAILED if IRP_MN_START_DEVICE fails > > - Fix a bug in IoReportDetectedDevice that wrote the AllocConfig value to > wrong place > > > > Added: > > trunk/reactos/ntoskrnl/io/pnpmgr/pnpres.c (with props) > > Modified: > > trunk/reactos/ntoskrnl/include/internal/io.h > > trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c > > trunk/reactos/ntoskrnl/io/pnpmgr/pnpreport.c > > trunk/reactos/ntoskrnl/ntoskrnl-generic.rbuild > > ------------------------------ > Condividi le tue emozioni e proteggi la tua privacy. Chiacchiera su > Messenger <http://www.windowslive.it/importaAmici.aspx> > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- Andrew Faulds (andrewros) http://ajf.me/

15 years, 3 months

1
0
0 0

Improvement: Foxit Reader 2.1

by victor martinez

After asking in ReactOS-dev what is the antonym of "Regression" (thanks DosX for telling me :) ), I am glad to show you an "IMPROVEMENT". It´s easy to complain about Regressions but we should try to show our little improvements. Congrats to our Devs because their efforts :) == Foxit Reader 2.1 is much more usable. 0.3.11 screenshot vs Trunk screenshot.== Screenshot: http://img696.imageshack.us/img696/8839/foxit2.jpg _________________________________________________________________ Tus datos personales, más seguros con Internet Explorer 8. http://www.microsoft.com/spain/windows/internet-explorer/default.aspx

15 years, 3 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 46983: [NTOSKRNL] - Replace the broken CM_RESOURCE_LIST_SIZE with a better function that actually works with resource lists that have device-specific data in them (fixes missing device specific data when resources are retrieved

by Gabriel ilardi

Hi, Device installation wizard has regressed again, now if you try to install the AC97 driver, it remains in a loop, and ros slows down at the point of being unusabe, the debug log shows: (ntoskrnl/io/pnpmgr/pnpmgr.c:190) Warning: Starting a device node without DNF_ADDED or DNF_ENUMERATED (Root\LEGACY_kmixer\0000) Thanks, Gabriel. > Date: Wed, 21 Apr 2010 22:33:12 +0000 > To: ros-diffs(a)reactos.org > From: cgutman(a)svn.reactos.org > Subject: [ros-diffs] [cgutman] 46983: [NTOSKRNL] - Replace the broken CM_RESOURCE_LIST_SIZE with a better function that actually works with resource lists that have device-specific data in them (fixes missing device specific data when resources are retrieved with IoGetDeviceProperty) - Separate the resource code out of pnpmgr.c and into pnpres.c - Simplify resource assigning to simply calling one function, IopAssignDeviceResources, which takes care of the registry configuration, translation, etc. - Set the DNF_NEED_ENUMERATION_ONLY flag only AFTER the device is actually started not before - Set DNF_START_FAILED if IRP_MN_START_DEVICE fails - Fix a bug in IoReportDetectedDevice that wrote the AllocConfig value to wrong place > > Author: cgutman > Date: Thu Apr 22 00:33:11 2010 > New Revision: 46983 > > URL: http://svn.reactos.org/svn/reactos?rev=46983&view=rev > Log: > [NTOSKRNL] > - Replace the broken CM_RESOURCE_LIST_SIZE with a better function that actually works with resource lists that have device-specific data in them (fixes missing device specific data when resources are retrieved with IoGetDeviceProperty) > - Separate the resource code out of pnpmgr.c and into pnpres.c > - Simplify resource assigning to simply calling one function, IopAssignDeviceResources, which takes care of the registry configuration, translation, etc. > - Set the DNF_NEED_ENUMERATION_ONLY flag only AFTER the device is actually started not before > - Set DNF_START_FAILED if IRP_MN_START_DEVICE fails > - Fix a bug in IoReportDetectedDevice that wrote the AllocConfig value to wrong place > > Added: > trunk/reactos/ntoskrnl/io/pnpmgr/pnpres.c (with props) > Modified: > trunk/reactos/ntoskrnl/include/internal/io.h > trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c > trunk/reactos/ntoskrnl/io/pnpmgr/pnpreport.c > trunk/reactos/ntoskrnl/ntoskrnl-generic.rbuild _________________________________________________________________ Messenger e Hotmail in tasca. Provali sul tuo cellulare! http://new.windowslivemobile.msn.com/it-it/Default.aspx

15 years, 3 months

1
0
0 0

test/fix building fastfat_new

by Alexey Komarov

Hi. Can somebody test/fix building fastfat_new? It seems, that it's problem with headers. Log: [CC] drivers\filesystems\fastfat_new\fastio.c [CC] drivers\filesystems\fastfat_new\fcb.c cc1.exe: warnings being treated as errors drivers\filesystems\fastfat_new\fcb.c: In function 'FatFindFcb': drivers\filesystems\fastfat_new\fcb.c:85: error: implicit declaration of functio n 'RtlLeftChild' drivers\filesystems\fastfat_new\fcb.c:85: error: assignment makes pointer from i nteger without a cast drivers\filesystems\fastfat_new\fcb.c:90: error: implicit declaration of functio n 'RtlRightChild' drivers\filesystems\fastfat_new\fcb.c:90: error: assignment makes pointer from i nteger without a cast drivers\filesystems\fastfat_new\fcb.c:95: error: implicit declaration of functio n 'RtlSplay' drivers\filesystems\fastfat_new\fcb.c:95: error: assignment makes pointer from i nteger without a cast drivers\filesystems\fastfat_new\fcb.c: In function 'FatInsertName': drivers\filesystems\fastfat_new\fcb.c:904: error: implicit declaration of functi on 'RtlInitializeSplayLinks' drivers\filesystems\fastfat_new\fcb.c:946: error: implicit declaration of functi on 'RtlInsertAsLeftChild' drivers\filesystems\fastfat_new\fcb.c:963: error: implicit declaration of functi on 'RtlInsertAsRightChild' drivers\filesystems\fastfat_new\fcb.c: In function 'FatRemoveNames': drivers\filesystems\fastfat_new\fcb.c:993: error: implicit declaration of functi on 'RtlDelete' drivers\filesystems\fastfat_new\fcb.c:993: error: assignment makes pointer from integer without a cast drivers\filesystems\fastfat_new\fcb.c:1002: error: assignment makes pointer from integer without a cast make.exe: *** [obj-i386\drivers\filesystems\fastfat_new\fcb_fastfatn.o] Error 1 WBR, Alexey Komarov.

15 years, 3 months

2
1
0 0

0.3.12 Changelog opened.

by victor martinez

Hi, i am happy of telling you that "0.3.12 Changelog" has been opened to recive all your commits in an ordered way. 0.3.11 was released on 16 December(2009), more than 4 months ago, this means a huge number of commits that we have to order before we can make attempts to create a 0.3.12 release. The link is(as usual): http://www.reactos.org/wiki/ChangeLog-0.3.12 I hope opening the Changelog before trying to release will help to solve the Changelog bottleneck and will give us more time to create it. Let´s move towards 0.3.12... Thanks for your minute :) _________________________________________________________________ Recibe un SMS de tu Hotmail vayas donde vayas. ¡Date de alta! http://home.mobile.live.com/MobileAttach.mvc/?mkt=es-es

15 years, 3 months

3
2
0 0

[ros-diff]rev 46907.gschneider[SHELL32] - Simplify checks for success of ShellExecuteEx

by victor martinez

Hi, i have been giving a look to this patch and i have some doubts(just learning :) ) The code is: @@ -1298,8 +1298,8 @@ static HRESULT WINAPI ICPanel_IContextMenu2_InvokeCommand( sei.hwnd = lpcmi->hwnd; sei.nShow = SW_SHOWNORMAL; sei.lpVerb = L"open"; - ShellExecuteExW(&sei); - if (sei.hInstApp <= (HINSTANCE)32) + + if (ShellExecuteExW(&sei) == FALSE) return E_FAIL; MSDN says that if ShellExecuteExW fails it sets hInstApp to a value lower than 32 and,also, returns FALSE. (MSDN: http://msdn.microsoft.com/en-us/library/bb762154(VS.85).aspx ) So both lines of codes(buggy and patched) are,at first sight,doing the same.Just using a different way. The Commit says: - Simplify checks for success of ShellExecuteEx, field hInst may be an unreliable indicator according to http://msdn.microsoft.com/en-us/library/bb759784%28v=VS.85%29.aspx Why is it unreliable? :) I am not saying it is reliable, just that i dont find the reason there...my skills are limited.. :( I have just found: "Although hInstApp is declared as an HINSTANCE for compatibility with 16-bit Windows applications, it is not a true HINSTANCE. It can be cast only to an int and compared to either 32 or the following SE_ERR_XXX error codes ". So my question is: Is the Bug in the cast to (HINSTANCE) instead to (INT)?I mean,do this solve the bug too?: - if (sei.hInstApp <= (HINSTANCE)32) + if ((INT)sei.hInstApp <= 32) As you see i am just learning, so thanks in advance. And yes, i prefer the new way that patch is using.Using the returned the value seems much more logic than using a "collateral damage". :) Btw, thanks Gregor for your hunting-fixing week ;) _________________________________________________________________ ¡Citas! ¡Ligues! ¿Salimos? ¿Cómo es tu pareja ideal? Búscala en el sitio nº1… ¡Regístrate ya! http://contactos.es.msn.com/?mtcmk=015352

15 years, 3 months

2
2
0 0

Commit by sir_richard :: r46904 reactos/ntoskrnl/mm/ARM3/miarm.h

by breakoutbox

Hello, "[NTOS]: 1MB is not 1000 * 1KB... " http://en.wikipedia.org/wiki/Megabyte 1 KB = 1000 byte (decimal) 1 KiB = 1024 byte (binary) 1 MB = 1000 KB 1 MiB = 1024 KiB Would be nice if ReactOS goes across the border and also uses the modern SI unit definitions ;-) If in code definitions or shown as text to the user .. Cheers, Peter

15 years, 3 months

7
11
0 0

[ros-diffs] [fireball] 46914: - Get rid of the last hardcoded screen size. - Remove unnecessary function declaration. See issue #5304 for more details.

by James Tabor

For one that bitches about trunk being broken all the time and punish everyone trying to get it fixed! Why not push this much effort to help fix the same issue in trunk.... Or is it done so truck stays broken?

15 years, 3 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [mpiulachs] 46862: My first commit in a very long time. I'm releasing the source code of my C# implementation of Rbuild by popular demand :) I would have preferred to release the code under a BSD licence but there is a small

by Sir Gallantmon (ニール・ゴンパ)

Does this work under Mono? AFAIK, Mono supports C# 3.5 and C# 4.0 language features.... so...? On Sat, Apr 17, 2010 at 7:56 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote: > Official URL for that component is http://dev.skybound.ca/download.aspx > Just for reference, it indeed crashes when running the HTML report backend, > I'm investigating this in the free time. > > WBR, > Aleksey. > > > On Apr 14, 2010, at 6:41 PM, Ged Murphy wrote: > > It partially works. >> Can't build the designer due to a Skybound.VisualStyles dependency. I >> assume we get that from here? >> http://windowsclient.net/downloads/folders/controlgallery/entry1590.aspx >> >> It then crashes when running the html report >> >> Just in case you were interested.... >> >> Ged. >> >> -----Original Message----- >> From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] >> On Behalf Of mpiulachs(a)svn.reactos.org >> Sent: 13 April 2010 23:00 >> To: ros-diffs(a)reactos.org >> Subject: [ros-diffs] [mpiulachs] 46862: My first commit in a very long >> time. I'm releasing the source code of my C# implementation of Rbuild by >> popular demand :) I would have preferred to release the code under a BSD >> licence but there is a small portion of ancient >> >> Author: mpiulachs >> Date: Tue Apr 13 23:59:21 2010 >> New Revision: 46862 >> >> URL: http://svn.reactos.org/svn/reactos?rev=46862&view=rev >> Log: >> My first commit in a very long time. I'm releasing the source code of my >> C# implementation of Rbuild by popular demand :) I would have preferred to >> release the code under a BSD licence but there is a small portion of ancient >> Nant GPL code that would have been to be rewritten first. >> >> There are two executables (SysGen.Designer) and (SysGen.Make) >> >> SysGen.Designer is a windows forms tool that allows to generate customized >> reactos images, it is similar in concept to Windows CE Platfom Builder. >> SysGen.Make is the actual Rbuild clone, It has three main parts, the .rbuild >> file parser + in-memory tree representation, the backends , and the auto >> generated files. The Mingw backend used to work 1'5 years ago and produced a >> 100% valid makefile.auto but have to be updated to be able to build a recent >> revision. Rewriting parts of it to take advantage of C# 3.5 extension >> methods would probably reduce the code by 50%. The other two parts are quite >> stable. >> >> This code was only a proof of concept and was never intended to be >> released so there is a ton of unpolished code and hacks required by the >> current C++ implementation that should be removed. >> >> How to test it: >> >> Select SysGen.Make as the Start-up Project in Visual Studio and edit >> Program.cs to point to the correct path to ReactOS-i386.rbuild Edit >> SysGenEngine.cs:639 to enable/disable specific backends, The HtmlBackend in >> \SysGen.BuildEngine\Backends\Html\HtmlBackend.cs is a very simple >> illustration of how powerful this framework is. >> >> Happy hacking! >> >> >> >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

15 years, 3 months

3
3
0 0

"make cb" broken

by Alexey Komarov

C:\ros\trunk\reactos>make cb [RBUILD] cb Reading build files...done Creating Code::Blocks workspace: ReactOS_auto.workspace make.exe: *** [cb] Error -1073741819 Total Build Time: 00:01:58 Can somebody fix it? (RosBE - 1.5, host - WinXP) WBR, Alexey Komarov.

15 years, 3 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [mpiulachs] 46862: My first commit in a very long time. I'm releasing the source code of my C# implementation of Rbuild by popular demand :) I would have preferred to release the code under a BSD licence but there is a small portion of anc

by Ged Murphy

It partially works. Can't build the designer due to a Skybound.VisualStyles dependency. I assume we get that from here? http://windowsclient.net/downloads/folders/controlgallery/entry1590.aspx It then crashes when running the html report Just in case you were interested.... Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mpiulachs(a)svn.reactos.org Sent: 13 April 2010 23:00 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [mpiulachs] 46862: My first commit in a very long time. I'm releasing the source code of my C# implementation of Rbuild by popular demand :) I would have preferred to release the code under a BSD licence but there is a small portion of ancient Author: mpiulachs Date: Tue Apr 13 23:59:21 2010 New Revision: 46862 URL: http://svn.reactos.org/svn/reactos?rev=46862&view=rev Log: My first commit in a very long time. I'm releasing the source code of my C# implementation of Rbuild by popular demand :) I would have preferred to release the code under a BSD licence but there is a small portion of ancient Nant GPL code that would have been to be rewritten first. There are two executables (SysGen.Designer) and (SysGen.Make) SysGen.Designer is a windows forms tool that allows to generate customized reactos images, it is similar in concept to Windows CE Platfom Builder. SysGen.Make is the actual Rbuild clone, It has three main parts, the .rbuild file parser + in-memory tree representation, the backends , and the auto generated files. The Mingw backend used to work 1'5 years ago and produced a 100% valid makefile.auto but have to be updated to be able to build a recent revision. Rewriting parts of it to take advantage of C# 3.5 extension methods would probably reduce the code by 50%. The other two parts are quite stable. This code was only a proof of concept and was never intended to be released so there is a ton of unpolished code and hacks required by the current C++ implementation that should be removed. How to test it: Select SysGen.Make as the Start-up Project in Visual Studio and edit Program.cs to point to the correct path to ReactOS-i386.rbuild Edit SysGenEngine.cs:639 to enable/disable specific backends, The HtmlBackend in \SysGen.BuildEngine\Backends\Html\HtmlBackend.cs is a very simple illustration of how powerful this framework is. Happy hacking!

15 years, 3 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly stubbed PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are completely unimplemented

by Ged Murphy

I don't mean to sound like a broken record, and I also understand that the project allows people to work on whatever they want to. But with the project in such a state at the moment, is a pcmcia bus driver really the best thing to be working on? I'm all for project freedom, but you would hope people to have the diligence to work on areas which might help to stop the project from failing. Maybe I just don't get it anymore and I'm behind the times, but what happened to the days when people used to work on important things? Your nagging ex-dev, Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of cgutman(a)svn.reactos.org Sent: 15 April 2010 02:59 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly stubbed PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are completely unimplemented Author: cgutman Date: Thu Apr 15 03:59:15 2010 New Revision: 46876 URL: http://svn.reactos.org/svn/reactos?rev=46876&view=rev Log: [PCMCIA] - Add a mostly stubbed PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are completely unimplemented Added: trunk/reactos/drivers/bus/pcmcia/ trunk/reactos/drivers/bus/pcmcia/fdo.c (with props) trunk/reactos/drivers/bus/pcmcia/pcmcia.c (with props) trunk/reactos/drivers/bus/pcmcia/pcmcia.h (with props) trunk/reactos/drivers/bus/pcmcia/pcmcia.rbuild (with props) trunk/reactos/drivers/bus/pcmcia/pcmcia.rc (with props) trunk/reactos/drivers/bus/pcmcia/pdo.c (with props) Modified: trunk/reactos/drivers/bus/directory.rbuild

15 years, 3 months

11
26
0 0

Re: [ros-dev] [ros-diffs] [aicom] 46798: [NTOSKRNL] - Create registry values for legacy drivers

by Gabriel ilardi

Hi, This revision introduces some regressions: - device manager list is empty - network connections is empty too, - it also breaks vbox guest additions installation on vbox version 3.0.12. See bug 5294 for more details: http://www.reactos.org/bugzilla/show_bug.cgi?id=5294 Thanks. Gabriel. [NTOSKRNL] - Create registry values for legacy drivers - Handle raw devices properly - Don't set DNF_STARTED before actually calling IopStartDevice - Don't set DNF_STARTED for legacy drivers inside IopCreateDeviceNode - Fixes missing entries in Device Manager for raw devices _________________________________________________________________ Naviga al sicuro. Scarica gratis Internet Explorer 8 per MSN http://www.microsoft.com/italy/windows/internet-explorer/msn.aspx

15 years, 3 months

1
0
0 0

Regressions and bugs

by Gabriel ilardi

Hi team, I don't know why, but it seems that bugzilla and ros-bugs is being ignored, except for some exceptions where I've seen regressions fixed lately. IMHO it's extremely important the perception people have about us when they test ros, if ros improved overall but that's not noticeable to the end user the final perception will be bad, now if we want a cooler release than 0.3.11 and older revisions, people should feel the improvement. I'm gonna make a short sum up of what I think it should be fixed or tried to at least to accomplish that (this list contains not only regressions but bugs that would improve the ros perception for the average user): I hope we can all work as a team to try and fix these issues, I can only offer my help testing as that's the thing I know best atm. GUI perception: 642 hotkeys not supported: Wouldn't it be cool to hit Win+R to run, Start menu appearing when hitting win, etc.? copy paste files with the keyboard... I'd also add here, we need to be able to switch applications with alt-tab, I remember johannes did something related to this long ago. 969 Minimized windows are shown on the desktop, no need to mention that this reminds me of win 3.11, good old times, but that was long ago... 1603 can't exit rename state 2320 clock doesn't show properly (partially shown), this exists since I remember too. 2322 Hide inactive icons doesn't work, please remove this... option :) 2328 Shell doesn't restart upon its failure 2428 non stop scrolling hangs entire gui, aka "if you do dir /s in real hardware go have a good breakfast" 2788 unwanted multiple selection while doing a right click on the desktop, ugly when you have multiple icons on your desktop and launch them because of this 3101 our remote dekstop can't be used, you can't change settings 3171 focus doesn't change back to parent window 3212 different keyboard responses, also keyboard doesn't work correctly with dinput see bug 4405 4379 hovering the mouse over the start menu spoils the text 4847 File copying dialog is missing 4915 Control panel: Keyboard doesn't work after opening and closing an applet 4960 ReactOS restarts at the beginning of 2nd stage if you hit ESC Explorer has all kind of visual glitches you can imagine and even more. keyboard layout issues: it's language dependent when it shouldn't be, changing keyboard layout doesn't work, kb layout tools dont' work, wrong keyboard layout in cmd see 3317, 2132, 2133, 2178, 2952, see also profiles problems below Visual/Graphic bugs: There are tons of these, I'll name a few, luckily we have Arwinss. 3624 worksoft navigator can't be minimized. 3680 Blinking text while installing vc2008 redist package 4051 Command Prompt icon showed through a window General: Users need to save a file to the desktop and see it has been created, see bug 1249 and also 2821. Winamp main window is unclicable, this has existed since I rememer, bug 1239. taskmgr shows still processes that have been killed, see bug 1567. 2393 you need to move the mouse to make firefox work (thanks arwinss for this too). Profiles: They are messed, %TEMP% has some issues see bugs 2482, 2972, also 4008 and 4102, all users desktop icons don't appear in user's desktop 4289, also bug 4444. 2622 console doesn't support scrolling at all. 2978 we can't search it regedit, it doesn't work and hangs the app. 3225 3dtext screensaver shows garbled text 3429 can't select any color in comdlg32 color dialog, since I remember too... 3559 Double-click on application icon does not close application. 3781 Tab Key does not work for "SysIPAddress32" controls 3883 screensaver doesn't start automatically 3966 can't hit enter on a selected item to open it 4049 changing screen resolutions requires restart, thanks Timo aka yaratows master! :) 4066 Notepad, uses two different fonts / highlighted text invisible 4106 Wrong text spacing in popup menus / icons after show a font in control applet / Remote Desktop 4185 [PATCH] Netstat produces b*llshit, should we apply the patch ? 4377 Notepad: Find command doesn't work right. 4380 Real Hardware: mouse wheel doesn't work 4383 Can't delete many items from Desktop at once using the mouse 4501 When closing one window, Firefox gets restored if it was minimized 4560 explorer mouse rectangle doesn't work anymore (I'm not sure it ever worked, it does work in arwinss) 4676 Unable to restore down a maximised window 4779 K-Meleon popup menus dont work 4835 Regression: Memory usage continuously decreases in task manager even though memory usage doesn't change (HACKFIXED) 5005 Foxit reader, program starts automatically instead of the installation wizard 5030 Changing color depth resets the wallpaper to none 5059 mIRC 6.35 server list with unusable scrollbar 5066 PATCH : Incorrect sending of mouse messages, can someone take a look ? 5099 [metabug]ReactOS new loader doesnt work with more than 3584 MB of RAM, let's not forget this one 5100 and 5101 too Regressions: 3716 Livecd networking does not work in qemu 3727 Regression: roscalc problems with keyboard input etc. 4461 Regression: Notepad Lite 4568 Regression: Startup Folder stopped working (see profiles and environment vars too) 4677 Regression: Can't restore minimized windows 4811 Recent AbiWord toolbar regression: comctl32 sync r42706 4926 Regression: Tworld and DosBox don't work 4948 [Regression] Can't close locale settings dialog on 2nd stage of setup 4951 [Regression] 'whois' hangs 5035 Regression: Abiword - Fonts listbox isn't shown properly 5276 Regression: shell about dialog doesn't display header bitmap 5294 Regression: Device manager list is empty x-chat used to work, it looked bad, now it doesn't even start, there's no specific regression bug filed for this, see bug 1176 Features needed: USB keyboard and mouse are a must nowadays, ps/2 won't last much longer..., bug 1041, also ps/2 doesn't work if you unplug it and replug it later bug 1395. Installation/USetup needs to be able to handle bootmgrs, and other partitions when they are present, at least give you the possibility to wipe everything up. also 2564 ros doesn't mount logical units on extended partitions, see also 2733, 4368, 4614, 5270 VGA/VBE bug 2073 ros does not work on vga display. See also 2286, 4354, 4447, 4192 Several uniata issues in real hw 4591, 4995 We need drag & drop a wokring clipboard Last but not least there's a regression not filed yet to my knowledge: (subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or Parent is dead! (subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or Parent is dead! (subsystems/win32/win32k/ntuser/windc.c:738) Not POWNED or CLASSDC hwndCurrent -> 20168 Assertion 'FALSE' failed at subsystems/win32/win32k/ntuser/windc.c line 739 PuTTYEntered debugger on embedded INT3 at 0x0008:0x808e5e5e. kdb:> bt Eip: <ntoskrnl.exe:e5e5f (lib/rtl/i386/debug_asm.S:33 (DbgBreakPoint@0))> Frames: <win32k.sys:7b79e (subsystems/win32/win32k/ntuser/windc.c:739 (@DceFreeWindowDCE@4))> <win32k.sys:7f69c (subsystems/win32/win32k/ntuser/window.c:488 (co_UserFreeWindow))> <win32k.sys:7fab7 (subsystems/win32/win32k/ntuser/window.c:2747 (@co_UserDestroyWindow@4))> <win32k.sys:7faed (subsystems/win32/win32k/ntuser/window.c:2771 (NtUserDestroyWindow@4))> <ntoskrnl.exe:6fb7 (ntoskrnl/ke/i386/traphdlr.c:1564 (@KiSystemServiceHandler@8))> <ntoskrnl.exe:e041d (ntoskrnl/ke/i386/trap.s:127 (KiInterruptTemplateDispatch))> <ntdll.dll:7ac5> <user32.dll:47ed1> <user32.dll:48063> <ntdll.dll:7a1d> <explorer.exe:16ded> <explorer.exe:436c6> <user32.dll:47ed1> <user32.dll:4851d> <user32.dll:48768> <user32.dll:2cf50> <user32.dll:2dd16> <user32.dll:2eaad> <user32.dll:2eb70> <user32.dll:3b92d> <explorer.exe:16e2a>--- Press q to abort, any other key to continue --- <explorer.exe:436c6> <user32.dll:47ed1> <user32.dll:4851d> <user32.dll:48768> <user32.dll:4bfa2> <user32.dll:4c06b> <user32.dll:2d5ed> <user32.dll:2eaad> <user32.dll:2eb70> <user32.dll:3b92d> <explorer.exe:16e2a> <explorer.exe:436c6> <user32.dll:47ed1> <user32.dll:4851d> <user32.dll:48a5b> <explorer.exe:4296c> <explorer.exe:4dd23> <explorer.exe:51c4b> <explorer.exe:60ad9> <explorer.exe:60906> <explorer.exe:60968> <kernel32.dll:2ef7b> --- Press q to abort, any other key to continue --- <00000000> kdb:> I'll be back, promise ;). _________________________________________________________________ Più di 20 giochi su Messenger. Scoprili tutti! http://www.messenger.it/raccoltaGiochi.aspx

15 years, 3 months

6
5
0 0

[ros-diffs] [mpiulachs] 46862: My first commit in a very long time. I'm releasing the source code of my C# implementation of Rbuild by popular demand :) I would have preferred to release the code under a BSD licence but there is a small portion of an

by Gabriel ilardi

Hi Marc, Cool, thanks! It's nice to see you back, hope to see more commits too ;) Gabriel. _________________________________________________________________ Più di 20 giochi su Messenger. Scoprili tutti! http://www.messenger.it/raccoltaGiochi.aspx

15 years, 3 months

1
0
0 0

Re: [ros-dev] Roadmap I'm sticking to

by victor martinez

Hi, Well..I have been here just for a year and a half, and it is pretty obvious that we are not following any "direction" to achieve something in common.We are making progress in our own,sometimes without telling to the others and sometimes introducing regressions 1week before a release thanks to a critical rewrite. Or We are disappearing without telling to anyone. We==Testers&&Developers&&Translators&&Designers&&TheCommunity. I will use this email to state,mainly, that i want to be part of a team with an objective, so i offer all my testing help (including those parts i hate to test) to achieve a common goal.I offer my Testing time as Real Testing time and not as a Hobbie. Maybe we should try to discuss how to reach that goal,and decide(all of us) which is the best way to have something working. I dont know if the correct approach is called Arwinss,Yarotows,WTF!(Want To Finish!) or whatever.The real approach is the final User. And the final User "demands" a workable OS asap.We are making this as a hobbie, but also trying to give a product to the mass(I hope). We are not acting as a Community,neither me. The time to find a way has arrived imo.It´s quite discouraging finding this mess. Discouraging for testers and Discouraging for Devs. In the latest half year we have lost some Testers because lack of motivation.And it is called "Road to Nowhere". Devs arrives to ReactOS Project and they seem to leave quite easy,why?. I hope this time we can all sit and try to find a real solution,deciding which is the Goal (a Hobbie,an OS?),which is the way(comfortable?difficult?no way?hiring internal devs?hiring external devs?knocking sponsors doors?),and which things are needed to complete it(money?motivation?a Bugzilla Testing Week?a RSOC(ReactOS Summer Of Code)?). Summing up, finding a WHOLE solution to this project called ReactOS. I think it is not just matter of a Roadmap. No having a Roadmap(or Milestones) is just the result, not the root of the problems. Thanks for the 3 minutes. _________________________________________________________________ Recibe un SMS de tu Hotmail vayas donde vayas. ¡Date de alta! http://home.mobile.live.com/MobileAttach.mvc/?mkt=es-es

15 years, 3 months

11
15
0 0

Roadmap I'm sticking to

by Aleksey Bragin

Hello, yesterday we had a usual rant in #reactos-dev regarding organization, teaming and development issues, and I explained how I see it. I think explaining and discussing here would be beneficial. I won't spend your time explaining how I came to this roadmap, I will go right to it. This roadmap is mainly usage-oriented and doesn't cover the kernel (it has its own one). * Finish wine-based subsystem ("arwinss"), fixing all internal (absent in Wine and/or trunk) bugs. Milestone 1: user32 and gdi32 known to work and support at least all the apps listed in the Wine app compat database. * Test as many as possible apps known to work in Wine and determine those which fail. * Fix failing components (kernel32, ntdll, kernel, CSR, non-synced DLLs, etc). Milestone 2: ReactOS supporting quite wide amount of applications, including major apps like MS Office suites, Open Office, CAD systems, Adobe products. Decision point: Because other Win32 components are proven to work, NT- alike user32, gdi32 and win32k development may be boosted, testing simplified. * Implement filesystem drivers, using fastfat_new as a universal skeleton for FS drivers. Use ntfs3g library and that skeleton to develop an NTFS IFS driver. Milestone 3: ReactOS with NTFS support (quite important for end users, thus separated into a standalone milestone). * Total rewrite of networking, using NT's one as a model. Milestone 4: ReactOS with a rock-stable networking. Ability to host database servers, web and FTP servers. * Release 1.0 and profit ;) So that's what I'm sticking to so far. I don't expect everyone to agree, but if more people are involved, achieving these milestones will happen faster. Also, they don't really have to go in a sequence, all of that may be done simulteneously (e.g. filesystem drivers must be developed against Windows 2003; kernel32 and ntdll could be fixed first using winetests without waiting for arwinss to be complete; networking could be again tested in existing ReactOS and Windows). Comments, improvements are welcome. WBR, Aleksey Bragin.

15 years, 3 months

6
6
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 46703: [NTOSKRNL] - Check access rights according to the DACL. Granted rights are removed from the remaining rights variable. - Return success only if there are no more remaining rights. Return failure otherwise. - R

by Olaf Siejka

I confirm Gabriel's findings. 2010/4/7 Gabriel ilardi <gabrielilardi(a)hotmail.it> > Hi Eric, > > It seems this commit introduces a regression, I've filed bug 5283 ( > http://www.reactos.org/bugzilla/show_bug.cgi?id=5283) there are no prompts > to install a driver for unknown hardware (i.e. AC97), I've tested 46702 and > this doesn't happen. > I've also reverted 46703 and 46714 in ntoskrnl and replaced head's ntoskrnl > with it, after that I get the prompt to install the driver again. > Thanks. > > Gabriel. > > ------------------------------ > Condividi le tue emozioni e proteggi la tua privacy. Chiacchiera su > Messenger <http://www.windowslive.it/importaAmici.aspx> > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

15 years, 3 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 46703: [NTOSKRNL] - Check access rights according to the DACL. Granted rights are removed from the remaining rights variable. - Return success only if there are no more remaining rights. Return failure otherwise. - Remove outdated

by Gabriel ilardi

Hi Eric, It seems this commit introduces a regression, I've filed bug 5283 (http://www.reactos.org/bugzilla/show_bug.cgi?id=5283) there are no prompts to install a driver for unknown hardware (i.e. AC97), I've tested 46702 and this doesn't happen. I've also reverted 46703 and 46714 in ntoskrnl and replaced head's ntoskrnl with it, after that I get the prompt to install the driver again. Thanks. Gabriel. _________________________________________________________________ Messenger e Hotmail in tasca. Provali sul tuo cellulare! http://new.windowslivemobile.msn.com/it-it/Default.aspx

15 years, 3 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [jimtabor] 46758: [Win32k|Gdi32] - Enable font batch and fixed setting brush origion. Use the new delete object functions in win32k.

by Timo Kreuzer

> + > +#define GDIOBJ_GetKernelObj(Handle) \ > + ((PGDI_TABLE_ENTRY)&GdiHandleTable->Entries[GDI_HANDLE_GET_INDEX(Handle)])->KernelData > This function shouldn't even exist. > pdcattr->hlfntNew = NtGdiGetStockObject(SYSTEM_FONT); > TextIntRealizeFont(pdcattr->hlfntNew,NULL); > + NewDC->hlfntCur = pdcattr->hlfntNew; > + NewDC->dclevel.plfnt = GDIOBJ_GetKernelObj(pdcattr->hlfntNew); > Looks like a good way to introduce bugs. There's a reason we have locking functions. The fact that in this case it's a stockfont that won't get deleted, doesn't mean we can do this always. If you want performance, keep a global pointer to the font and use GDIOBJ_IncrementShareCount

15 years, 3 months

2
1
0 0

Spanish translation for the new log off confirmation dialog (bug 1494, revision r46722)

by Javier Agustìn Fernàndez Arroyo

@DosX, hi, i updated bug #1494 with the spanish translation updated... translation URL is http://www.reactos.org/bugzilla/attachment.cgi?id=4882 hope its correct :)

15 years, 3 months

2
1
0 0

[ros-diffs] [jgardou] 46698: [WIN32K] Unlock surface when deleting DC

by James Tabor

Since no one is listening (reading) to me about this issue and the response I receive is "WTF are you talking about"! Let me explain one more time..... In reference to commit 46679, I attempted to provide the project an example on how information contexts (IC) are created and removed. Works as a toggle between switching flags and moving the pdc->dclevel.pSurface pointer to and from pdc->pSurfInfo. The name of pSurfInfo should give a good clue. I was surprised when no one on IRC knew anything about this and it explains why the yarotows branch is not taking this into consideration. Remember my rant? Building code from broke code creates more broken code! Thus, increasing the amount of wasted time rewriting it. --- branches/reactos-yarotows/subsystems/win32/win32k/objects/dclife.c [iso-8859-1] (original) +++ branches/reactos-yarotows/subsystems/win32/win32k/objects/dclife.c [iso-8859-1] Sat Apr 3 18:42:04 2010 @@ -377,6 +377,9 @@ PATH_Delete(pdc->dclevel.hPath); + if(pdc->dclevel.pSurface) + SURFACE_ShareUnlockSurface(pdc->dclevel.pSurface); + PDEVOBJ_vRelease(pdc->ppdev) ; return TRUE; __________ Need to check for DC_TYPE_INFO and sometimes for DC_FLAG_TEMPINFODC. Quick check for pSurfInfo if NULL might be helpful too. I'm keeping track of yarotows and I see some needed merging into trunk (head, main branch) soon. 46630 is a good start. Thanks, James Referance: [ros-diffs] [jimtabor] 46679: [Win32k] - Implement MakeInfoDC and support functions. Dedicated to Timo. http://www.reactos.org/archives/public/ros-diffs/2010-April/036412.html

15 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [jgardou] 46505: svn will drive me nuts, part 1/x

by Ged Murphy

This is not a valid commit message... -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of jgardou(a)svn.reactos.org Sent: 27 March 2010 23:28 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [jgardou] 46505: svn will drive me nuts, part 1/x Author: jgardou Date: Sun Mar 28 00:28:24 2010 New Revision: 46505 URL: http://svn.reactos.org/svn/reactos?rev=46505&view=rev Log: svn will drive me nuts, part 1/x Added: branches/reactos-yarotows/drivers/bus/acpi/eval.c (with props) branches/reactos-yarotows/drivers/bus/acpi/interface.c (with props) branches/reactos-yarotows/drivers/storage/scsiport/scsiport.pspec (with props) branches/reactos-yarotows/drivers/storage/scsiport/stubs.c (with props) branches/reactos-yarotows/hal/halx86/up/pic.c (with props) branches/reactos-yarotows/hal/halx86/up/processor.c (with props) branches/reactos-yarotows/include/dxsdk/bdatif.idl branches/reactos-yarotows/include/ndk/peb_teb.h (with props) Modified: branches/reactos-yarotows/ (props changed) branches/reactos-yarotows/drivers/bus/acpi/cmbatt/cmbpnp.c branches/reactos-yarotows/drivers/bus/acpi/compbatt/compbatt.c branches/reactos-yarotows/drivers/bus/acpi/compbatt/compbatt.h branches/reactos-yarotows/drivers/bus/acpi/compbatt/comppnp.c branches/reactos-yarotows/media/inf/machine.inf branches/reactos-yarotows/ntoskrnl/io/pnpmgr/pnpmgr.c [This mail would be too long, it was shortened to contain the URLs only.] Modified: branches/reactos-yarotows/drivers/bus/acpi/cmbatt/cmbpnp.c URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/drivers/bus/ac… Modified: branches/reactos-yarotows/drivers/bus/acpi/compbatt/compbatt.c URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/drivers/bus/ac… Modified: branches/reactos-yarotows/drivers/bus/acpi/compbatt/compbatt.h URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/drivers/bus/ac… Modified: branches/reactos-yarotows/drivers/bus/acpi/compbatt/comppnp.c URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/drivers/bus/ac… Added: branches/reactos-yarotows/drivers/bus/acpi/eval.c URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/drivers/bus/ac… Added: branches/reactos-yarotows/drivers/bus/acpi/interface.c URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/drivers/bus/ac… Added: branches/reactos-yarotows/drivers/storage/scsiport/scsiport.pspec URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/drivers/storag… Added: branches/reactos-yarotows/drivers/storage/scsiport/stubs.c URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/drivers/storag… Added: branches/reactos-yarotows/hal/halx86/up/pic.c URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/hal/halx86/up/… Added: branches/reactos-yarotows/hal/halx86/up/processor.c URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/hal/halx86/up/… Added: branches/reactos-yarotows/include/dxsdk/bdatif.idl URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/include/dxsdk/… Added: branches/reactos-yarotows/include/ndk/peb_teb.h URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/include/ndk/pe… Modified: branches/reactos-yarotows/media/inf/machine.inf URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/media/inf/mach… Modified: branches/reactos-yarotows/ntoskrnl/io/pnpmgr/pnpmgr.c URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/ntoskrnl/io/pn…

15 years, 4 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 46677: Remove svn:mergeinfo property from several files

by Colin Finck

tkreuzer(a)svn.reactos.org wrote: > Remove svn:mergeinfo property from several files We should rather try to eliminate the root of these constant merge artifacts, which seem to be the remaining svn:keywords properties. As these ones instruct Subversion to update the revision number in the affected files, they probably also include the revision numbers of merges maintained by svn:mergeinfo. I've already removed some svn:keywords properties in the same files (for example in r41694), but I believe that this doesn't help much unless the properties are also removed in all branches we use for merging. Cheers, Colin

15 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [sir_richard] 46613: [HALACPI]: Implement beginning of HAL ACPI support (HalpSetupAcpiPhase0). Tested on VMWare, where it found the FACP, SRAT, RSDT and MCFG and the ACPI Timer at 1008H. BOOT and DBGP are not found (optional features). [HA

by Ged Murphy

sir_richard(a)svn.reactos.org wrote: > [HALACPI]: Support depends on boot loader creating the ACPI BIOS Multi Node structure in > MultiFunctionAdapter in the hardware tree. It seems that FreeLdr does this (wow!) correctly! Oh ye of little faith :)

15 years, 4 months

1
0
0 0

fastcall bug

by Steven Edwards

Hi, Have you guys seen this? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41013 Is it really a problem? The discussion came up on wine-devel. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

15 years, 4 months

7
6
0 0

testcd is broken

by Timo Kreuzer

Hi, The testcd is broken. And no, it's not due to the header merge. This time it broke in r46574 (hal changes) Now please don't blame sir richard, instead someone please free some disk space on the testbot. Regards, Timo

15 years, 4 months

1
0
0 0

TestCD build broken

by Olaf Siejka

Since rev. 46466, rostests build is broken. No iso are generated. Just in case anyone cares. http://build.reactos.org:8010/builders/x86_(Debug)/builds/4846/steps/compil…

15 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [jimtabor] 46349: - Hack fix for gdibatch, please retest Acrobat reader 7.

by Aleksey Bragin

Forget what I said about acpi hack being nasty the other day. After looking at this one.... Aleksey. -------------------------------------------------- From: <jimtabor(a)svn.reactos.org> Sent: Tuesday, March 23, 2010 4:34 AM To: <ros-diffs(a)reactos.org> Subject: [ros-diffs] [jimtabor] 46349: - Hack fix for gdibatch,please retest Acrobat reader 7. > Author: jimtabor > Date: Tue Mar 23 02:34:30 2010 > New Revision: 46349 > > URL: http://svn.reactos.org/svn/reactos?rev=46349&view=rev > Log: > - Hack fix for gdibatch, please retest Acrobat reader 7. > > Modified: > trunk/reactos/subsystems/win32/win32k/objects/gdibatch.c > > Modified: trunk/reactos/subsystems/win32/win32k/objects/gdibatch.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ob… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/objects/gdibatch.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/objects/gdibatch.c [iso-8859-1] > Tue Mar 23 02:34:30 2010 > @@ -72,7 +72,7 @@ > { > pdcattr = dc->pdcattr; > } > - // The thread is approaching the end of sunset. > + // FYI! The thread is approaching the end of sunset. > switch(pHdr->Cmd) > { > case GdiBCPatBlt: // Highest pri first! > @@ -139,6 +139,7 @@ > APIENTRY > NtGdiFlushUserBatch(VOID) > { > + BOOL Hit; > PTEB pTeb = NtCurrentTeb(); > ULONG GdiBatchCount = pTeb->GdiBatchCount; > > @@ -160,8 +161,26 @@ > } > > // No need to init anything, just go! > - for (; GdiBatchCount > 0; GdiBatchCount--) > - { > + for (Hit = FALSE; GdiBatchCount > 0; GdiBatchCount--) > + { /* > + Looks like a hack, > + feels like a hack, > + you're right it's a hack, > + due to the lack, > + of kernel thread locking when it is in sunset! > + */ > + _SEH2_TRY > + { > + ((PGDIBATCHHDR)pHdr)->Cmd = ((PGDIBATCHHDR)pHdr)->Cmd; > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Hit = TRUE; > + } > + _SEH2_END; > + > + if (Hit) break; > + > // Process Gdi Batch! > pHdr += GdiFlushUserBatch(pDC, (PGDIBATCHHDR) pHdr); > } > >

15 years, 4 months

1
0
0 0

Re: [ros-dev] OT - Which Editor/IDE people use for ReactOS

by WaxDragon

*points and laughs at the old man. VIM all the way, baby! On Mar 17, 2010 6:55 PM, "James Tabor" <jimtabor.rosdev(a)gmail.com> wrote: Hi! I guess it depends on how old some of us are. I use UNIX/Joe since I've used WordStar in the past. Sometimes G/Kedit too.Visual C++ on windows. Not OT at all, James On Tue, Mar 16, 2010 at 12:44 PM, Deepak Gupta <mailmeatdkg(a)gmail.com> wrote: > I have been browsin... _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www....

15 years, 4 months

5
4
0 0

OT - Which Editor/IDE people use for ReactOS

by Deepak Gupta

I have been browsing through reactos sources (mainly boot and ntoskrnl). I was wondering which Editor/IDE people use for reactos sources. I am currently using gVim along with ctags to browse through the sources. Any suggestions which could be more helpful. Regards Deepak Gupta

15 years, 4 months

6
7
0 0

[ros-diffs] [cwittich] 46251: [USER32] reduce diff to wine

by James Tabor

Wow! Svn must be getting better these days! It merged perfectly to my changes I have here being tested. Expect some menu improvements and code additions coming soon. Thanks, James

15 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 46237: - Add a hack to disable ACPI if VMware is detected - This hack circumvents the main blocker that prevents enabling ACPI in trunk

by Aleksey Bragin

Very nasty. -------------------------------------------------- From: <cgutman(a)svn.reactos.org> Sent: Wednesday, March 17, 2010 8:02 AM To: <ros-diffs(a)reactos.org> Subject: [ros-diffs] [cgutman] 46237: - Add a hack to disable ACPI if VMware is detected - This hack circumvents the main blocker that prevents enabling ACPI in trunk > Author: cgutman > Date: Wed Mar 17 06:02:06 2010 > New Revision: 46237 > > URL: http://svn.reactos.org/svn/reactos?rev=46237&view=rev > Log: > - Add a hack to disable ACPI if VMware is detected > - This hack circumvents the main blocker that prevents enabling ACPI in > trunk > > Modified: > trunk/reactos/drivers/bus/acpi/acpica/tables/tbutils.c > > Modified: trunk/reactos/drivers/bus/acpi/acpica/tables/tbutils.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/bus/acpi/acpica/ta… > ============================================================================== > --- trunk/reactos/drivers/bus/acpi/acpica/tables/tbutils.c [iso-8859-1] > (original) > +++ trunk/reactos/drivers/bus/acpi/acpica/tables/tbutils.c [iso-8859-1] > Wed Mar 17 06:02:06 2010 > @@ -592,6 +592,7 @@ > UINT32 Length; > UINT8 *TableEntry; > ACPI_STATUS Status; > + ACPI_TABLE_HEADER LocalHeader; > > > ACPI_FUNCTION_TRACE (TbParseRootTable); > @@ -645,6 +646,14 @@ > } > > AcpiTbPrintTableHeader (Address, Table); > + > + AcpiTbCleanupTableHeader (&LocalHeader, Table); > + if (strstr(LocalHeader.AslCompilerId, "VMW")) > + { > + ACPI_ERROR ((AE_INFO, "VMware detected; ACPI has been > disabled\n")); > + AcpiOsUnmapMemory (Table, sizeof (ACPI_TABLE_HEADER)); > + return_ACPI_STATUS (AE_ERROR); > + } > > /* Get the length of the full table, verify length and map entire > table */ > > >

15 years, 4 months

5
4
0 0

Re: [ros-dev] [ros-diffs] [sir_richard] 46103: [WIN32K]: Stop memory corruption when InstalledDisplayDrivers has more than one driver in the list. Note that driver loading is inherently broken right now, as the list of drivers is not parsed properly (this breaks eVb's VGA/VBE driver).

by Timo Kreuzer

Hi, I have a pending rewrite of the driver loading code in branches/reactos-yarotows. It should hopefully fix the issues and load eVb's driver. It's mostly done, I experienced some random lock ups, though and had to take a break from that code. Regards, Timo sir_richard(a)svn.reactos.org schrieb: > Author: sir_richard > Date: Thu Mar 11 18:46:15 2010 > New Revision: 46103 > > URL: http://svn.reactos.org/svn/reactos?rev=46103&view=rev > Log: > [WIN32K]: Stop memory corruption when InstalledDisplayDrivers has more than one driver in the list. Note that driver loading is inherently broken right now, as the list of drivers is not parsed properly (this breaks eVb's VGA/VBE driver). > > Modified: > trunk/reactos/subsystems/win32/win32k/objects/device.c > > Modified: trunk/reactos/subsystems/win32/win32k/objects/device.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ob… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/objects/device.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/objects/device.c [iso-8859-1] Thu Mar 11 18:46:15 2010 > @@ -59,12 +59,37 @@ > return TRUE; > } > > + > +NTSTATUS > +NTAPI > +EnumDisplayQueryRoutine(IN PWSTR ValueName, > + IN ULONG ValueType, > + IN PVOID ValueData, > + IN ULONG ValueLength, > + IN PVOID Context, > + IN PVOID EntryContext) > +{ > + if ((Context == NULL) && ((ValueType == REG_SZ) || (ValueType == REG_MULTI_SZ))) > + { > + *(PULONG)EntryContext = ValueLength; > + } > + else > + { > + DPRINT1("Value data: %S %d\n", ValueData, ValueLength); > + RtlCopyMemory(Context, ValueData, ValueLength); > + } > + > + return STATUS_SUCCESS; > +} > + > static BOOL FASTCALL > FindDriverFileNames(PUNICODE_STRING DriverFileNames, ULONG DisplayNumber) > { > RTL_QUERY_REGISTRY_TABLE QueryTable[2]; > UNICODE_STRING RegistryPath; > NTSTATUS Status; > + PWCHAR DriverNames = NULL; > + ULONG Length = 0; > > if (! GetRegistryPath(&RegistryPath, DisplayNumber)) > { > @@ -73,23 +98,40 @@ > } > > RtlZeroMemory(QueryTable, sizeof(QueryTable)); > - QueryTable[0].Flags = RTL_QUERY_REGISTRY_REQUIRED | RTL_QUERY_REGISTRY_DIRECT; > + QueryTable[0].Flags = RTL_QUERY_REGISTRY_REQUIRED | RTL_QUERY_REGISTRY_NOEXPAND; > QueryTable[0].Name = L"InstalledDisplayDrivers"; > - QueryTable[0].EntryContext = DriverFileNames; > + QueryTable[0].EntryContext = &Length; > + QueryTable[0].QueryRoutine = EnumDisplayQueryRoutine; > > Status = RtlQueryRegistryValues(RTL_REGISTRY_ABSOLUTE, > RegistryPath.Buffer, > QueryTable, > NULL, > NULL); > + // DPRINT1("Status: %lx\n", Status); > + if (Length) > + { > + DriverNames = ExAllocatePool(PagedPool, Length); > + // DPRINT1("Length allocated: %d\n", Length); > + Status = RtlQueryRegistryValues(RTL_REGISTRY_ABSOLUTE, > + RegistryPath.Buffer, > + QueryTable, > + DriverNames, > + NULL); > + if (!NT_SUCCESS(Status)) DriverNames = NULL; > + } > + > ExFreePoolWithTag(RegistryPath.Buffer, TAG_RTLREGISTRY); > if (! NT_SUCCESS(Status)) > { > DPRINT1("No InstalledDisplayDrivers value in service entry found\n"); > return FALSE; > } > - > - DPRINT("DriverFileNames %S\n", DriverFileNames->Buffer); > + > + RtlInitUnicodeString(DriverFileNames, DriverNames); > + DriverFileNames->Length = Length; > + DriverFileNames->MaximumLength = Length; > + //DPRINT1("DriverFileNames %wZ\n", DriverFileNames); > > return TRUE; > } > @@ -301,7 +343,7 @@ > continue; > } > > - DPRINT("Display driver %S loaded\n", CurrentName); > + DPRINT1("Display driver %S loaded\n", CurrentName); > > ExFreePoolWithTag(DriverFileNames.Buffer, TAG_RTLREGISTRY); > > > > >

15 years, 4 months

1
0
0 0

[ros-diffs] [tkreuzer] 46089: [KMTYPES] Add a compilation hack for gcc

by Dmitry Gorbachev

Hi! typedef struct _TRANSACTION_NOTIFICATION_RECOVERY_ARGUMENT { GUID EnlistmentId; #if !defined(__cplusplus) UOW UOW; #else ::UOW UOW; #endif } TRANSACTION_NOTIFICATION_RECOVERY_ARGUMENT, *PTRANSACTION_NOTIFICATION_RECOVERY_ARGUMENT; can be used instead of a hack.

15 years, 4 months

1
0
0 0

[ros-diffs] [cwittich] 46076: [PSDK] add extern GUID_NULL

by James Tabor

Hi! The ./psdk/cguid.h:26:extern const IID GUID_NULL; has it already! Maybe include it in the test rbuild file? James

15 years, 4 months

1
0
0 0

Google summer code

by Mgr. Janusz Chmiel

Dear core developers of Reactos, I would like to inform YOu about my findings related to screen readers support while using Wine emulator, because as i understood, Wine and Reactos are sharing crucial information to make those tools as much Windows compatible as it is possible. 1. NVDA is not able to run in The Wine, which can be downloaded from PCLINUXOSS repositories, NVDA is only plaing a welcome gong and then i Am receiving series of error messages, one related to winmm.dll and also other related to MSAA support. oleacc.dll very probably. When i tried one Czech very little screen reader based on using API hooks and API calls, program is written by using Microsoft Visual Basic 6.0 professional edition and crucial helper dlls are written in Microsoft visual C++ but not Express 2005 edition, older release of this programming language has been used. What are mi findings? Algorithms used for generating synthesizet speech are working ammazingly in Wine. but other algorithms for fetching names of buttons, objects and for getting textual information are not working. But i Am afraid, that implementing reliable MSAA support is so much complex for core developers of Wine or Reactos, that it will never been possible to reach this goal. Many of us are very intelligent and professional developers, who are even able to use Assembler while compiling and developing Reactos core components, but i think, that without access to Windows MSAA source code developing reliable MSAA support will be only big dream, which would never been come true. Reactos is in general very stable and reliable operating system and i believe, that in future, also many device drivers will work with Reactos. If also MSAA support would be added in future, this would be very positive for many handicapped users, because MSAA is being used not only by screen readers, but also while using other assistive technology, which are based on MSAA calls. BUt i think, that Microsoft will not want to reveal The MSAA source code, the modified source code of oleacc.dll, user32.dll and others. Accessing source code is fortunately possible, but i read about this, that some fee must be paied to Microsoft to get access to their source code repository, and i think, that there will be very restricted conditions.

15 years, 4 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [evb] 45874: - New Framebuffer (Linear) Display Driver to support new unified VGA/VBE miniport. Based on NT4 DDK Sample, with modifications by me (marked with // eVb) to support new functionality needed for 2003-era driver. - Also use

by Steven Edwards

On Fri, Mar 5, 2010 at 12:29 PM, <evb(a)svn.reactos.org> wrote: > - New Framebuffer (Linear) Display Driver to support new unified VGA/VBE miniport. Based on NT4 DDK Sample, with modifications by me (marked with // eVb) to support new functionality needed for 2003-era driver. > - Also used Virtual Box Display Driver as sample, which is based on "GPL" Windows 2003 DDK sample driver. Could not use 2003 DDK sample directly because of licensing issues, and feel unsafe about VirtualBox "GPL" driver that says "PATENTED AND ONLY FOR USE IN MICROSOFT PRODUCTS". > - Note that old driver was based off DDK sample too, but with variables renamed (some comments identical!) and code reformatted, then marked as "GPL". This is not very good way to share/use code... one day someone can teach you lesson. I am not sure what this comment is supposed to mean. Are you saying that the wishes of the Author should not be respected? The PATENTED statement is an extra qualifier. We are talking about two issues, patents (which are vague and Copyright which is clear). Clearly the author being Microsoft does not want it's code used as a derived work for a non-windows OS. As the copyright owner and licensor that is their right. Or do you propose that developers ignore the copyright law and do it anyway? If you want to import the Windows 2003 DDK driver and create a derived work in violation of the terms, do the rest of us a favor and upload a scanned copy of your drivers license, passport or whatever as a resource for this driver so Microsoft will know exactly who to sue. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

15 years, 4 months

2
2
0 0

Re: [ros-dev] [ros-diffs] [sir_richard] 46042: [KERNEL32/CSRSS]: Register new Win32 threads with CSRSS. Add a bunch of lookup, creation, allocation, hashing and CSR thread management routines from the unused CSRSRV in trunk. [CSRSS]: Bang in the new thread support

by Gabriel ilardi

Hi, There's a regression that I narrowed to this range: 46028 (no regression) - 46043 (regression). Tested in VirtualBox, in 3rd stage you get: (base/services/umpnpmgr/umpnpmgr.c:2132) CreateProcessAsUserW failed with error 1375 (ERROR_TOKEN_ALREADY_IN_USE), and no new hardware wizard prompt. Regards, Gabriel. Here's the full debug log for 3rd stage: (ntoskrnl/kd/kdio.c:297) ----------------------------------------------------- (ntoskrnl/kd/kdio.c:298) ReactOS 0.4-SVN (Build 20100309-r46043) (ntoskrnl/kd/kdio.c:299) Command Line: /DEBUG /DEBUGPORT=COM1 /BAUDRATE=115200 /SOS (ntoskrnl/kd/kdio.c:303) ARC Paths: multi(0)disk(0)rdisk(0)partition(1) \ multi(0)disk(0)rdisk(0)partition(1) \ReactOS\ (ntoskrnl/ke/i386/cpu.c:746) Prefetch Cache: 64 bytes L2 Cache: 524288 bytes L2 Cache Line: 64 bytes L2 Cache Associativity: 16 WARNING: HalStopProfileInterrupt at hal/halx86/generic/profil.c:24 is UNIMPLEMENTED! (ntoskrnl/mm/mminit.c:289) 0x80000000 - 0x80C00000 Boot Loaded Image (ntoskrnl/mm/mminit.c:293) 0x80C00000 - 0x87000000 Paged Pool (ntoskrnl/mm/mminit.c:297) 0xB0000000 - 0xB0300000 PFN Database (ntoskrnl/mm/mminit.c:301) 0xB0300000 - 0xB0AC8000 ARM³ Non Paged Pool (ntoskrnl/mm/mminit.c:305) 0xBC000000 - 0xBD000000 System View Space (ntoskrnl/mm/mminit.c:309) 0xBD000000 - 0xC0000000 Session Space (ntoskrnl/mm/mminit.c:312) 0xC0000000 - 0xC0300000 Page Tables (ntoskrnl/mm/mminit.c:315) 0xC0300000 - 0xC0400000 Page Directories (ntoskrnl/mm/mminit.c:318) 0xC0400000 - 0xC0800000 Hyperspace (ntoskrnl/mm/mminit.c:322) 0xE1000000 - 0xED400000 ARM³ Paged Pool (ntoskrnl/mm/mminit.c:325) 0xF4C00000 - 0xFA305000 System PTE Space (ntoskrnl/mm/mminit.c:328) 0xFA305000 - 0xFFBE0000 Non Paged Pool Expansion PTE Space (ntoskrnl/ke/i386/kiinit.c:53) Large Page support detected but not yet taken advantage of (ntoskrnl/ke/i386/patpge.c:45) Global page support detected but not yet taken advantage of (ntoskrnl/ke/i386/patpge.c:58) PAT support detected but not yet taken advantage of (ntoskrnl/ke/i386/mtrr.c:24) MTRR support detected but not yet taken advantage of PC Compatible Eisa/Isa HAL has been initialized WARNING: IoReportResourceUsage at ntoskrnl/io/iomgr/iorsrce.c:700 is UNIMPLEMENTED! WARNING: IoReportResourceUsage at ntoskrnl/io/iomgr/iorsrce.c:700 is UNIMPLEMENTED! (ntoskrnl/io/iomgr/driver.c:1392) '\Driver\BUSLOGIC' initialization failed, status (0xc00000c0) (drivers/network/ndis/ndis/miniport.c:2413)(NdisMRegisterMiniport) Initializing an NDIS 5.0 miniport (drivers/network/ndis/ndis/config.c:485)(NdisReadConfiguration) ZwQueryValueKey #1 failed for NetworkAddress, status 0xc0000034 (drivers/network/ndis/ndis/config.c:700)(NdisReadNetworkAddress) NdisReadConfiguration failed (c0000001) (drivers/network/ndis/ndis/efilter.c:96)(EthFilterDprIndicateReceive) Filter is NULL (drivers/network/ndis/ndis/efilter.c:96)(EthFilterDprIndicateReceive) Filter is NULL (drivers/network/ndis/ndis/efilter.c:96)(EthFilterDprIndicateReceive) Filter is NULL (drivers/network/ndis/ndis/efilter.c:129)(EthFilterDprIndicateReceiveComplete) Filter is NULL (ntoskrnl/io/iomgr/deviface.c:1005) IoGetDeviceObjectPointer() failed with status 0xc0000010 wood_uhci: Entering DriverEntry(), RegistryPath= \Registry\Machine\System\CurrentControlSet\Services\usbdriver (ntoskrnl/io/iomgr/driver.c:1392) '\Driver\usbdriver' initialization failed, status (0xc0000001) Unhandled event type: 6 (ntoskrnl/io/iomgr/file.c:420) Using IopParseDevice() hack. Requested invalid attributes: 1 (ntoskrnl/io/iomgr/file.c:420) Using IopParseDevice() hack. Requested invalid attributes: 1 Boot took 14375646481 cycles! Interrupts: 1079 System Calls: 4850 Context Switches: 291 (subsystems/win32/win32k/ntuser/sysparams.c:1499) UserSystemParametersInfo called without active windowstation. err:(dll/win32/user32/misc/dllmain.c:367) GetConnected (subsystems/win32/win32k/ntuser/desktop.c:604) RtlQueryRegistryValues failed for PaintDesktopVersion (c0000034) (subsystems/win32/win32k/ntuser/sysparams.c:1499) UserSystemParametersInfo called without active windowstation. (subsystems/win32/win32k/objects/gdiobj.c:1108) Attempted to lock object 0x0 of wrong type (Handle: 0x0, requested: 0x50000) (subsystems/win32/win32k/objects/gdiobj.c:1108) Attempted to lock object 0x0 of wrong type (Handle: 0x0, requested: 0x50000) (subsystems/win32/win32k/objects/gdiobj.c:1108) Attempted to lock object 0x0 of wrong type (Handle: 0x0, requested: 0x50000) (subsystems/win32/win32k/objects/gdiobj.c:1108) Attempted to lock object 0x0 of wrong type (Handle: 0x0, requested: 0x50000) err:(dll/win32/user32/windows/window.c:281) CreateWindowExA RegisterSystemControls Boot took 21134116768 cycles! Interrupts: 1632 System Calls: 8466 Context Switches: 1260 (subsystems/win32/win32k/ntuser/desktop.c:604) RtlQueryRegistryValues failed for PaintDesktopVersion (c0000034) err:(dll/win32/advapi32/service/sctrl.c:668) ScmrSetServiceStatus() failed (Error 1722) err:(dll/win32/advapi32/service/sctrl.c:668) ScmrSetServiceStatus() failed (Error 1722) Boot took 24388307864 cycles! Interrupts: 1753 System Calls: 11824 Context Switches: 1859 err:(dll/win32/advapi32/service/sctrl.c:668) ScmrSetServiceStatus() failed (Error 1722) err:(dll/win32/advapi32/service/sctrl.c:668) ScmrSetServiceStatus() failed (Error 1722) (lib/rtl/actctx.c:874) Unsupported yet language attribute (*) (lib/rtl/actctx.c:2007) looking for name=Microsoft.Windows.Common-Controls version=6.0.0.0 arch=X86 Using shell hooks for notification of shell events. (subsystems/win32/win32k/ntuser/hook.c:1202) Not implemented: HookId 3 Global TRUE fixme:(dll/win32/kernel32/file/backup.c:35) BackupRead is UNIMPLEMENTED! fixme:(dll/win32/kernel32/file/backup.c:35) BackupRead is UNIMPLEMENTED! (lib/rtl/actctx.c:874) Unsupported yet language attribute (*) (lib/rtl/actctx.c:2007) looking for name=Microsoft.Windows.Common-Controls version=6.0.0.0 arch=X86 CreateDirectory("C:\Documents and Settings\Administrator.REACTOS\Application Data\Microsoft") CreateDirectory("C:\Documents and Settings\Administrator.REACTOS\Application Data\Microsoft\Internet Explorer") (ntoskrnl/se/semgr.c:294) SidInToken Calls: 10000 CreateDirectory("C:\Documents and Settings\Administrator.REACTOS\Application Data\Microsoft\Internet Explorer\Quick Launch") (base/services/umpnpmgr/umpnpmgr.c:2132) CreateProcessAsUserW failed with error 1375 (base/services/umpnpmgr/umpnpmgr.c:2132) CreateProcessAsUserW failed with error 1375 (base/services/umpnpmgr/umpnpmgr.c:2132) CreateProcessAsUserW failed with error 1375 (base/services/umpnpmgr/umpnpmgr.c:2132) CreateProcessAsUserW failed with error 1375 _________________________________________________________________ Più spazio per le tue esigenze. Hotmail va oltre i 5GB http://www.windowslive.it/hotmail/SpazioDisponibile.aspx

15 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [jimtabor] 46006: - [User32_winetest] - Win : Remove test_capture from service. This is related to TrackMouseEvent issues which use SetCapture.

by Aleksey Bragin

I was blamed for doing this the other day. So do we skip tests or don't? If yes, they must be marked as skipped, not silently ignored. WBR, Aleksey Bragin. On Mar 8, 2010, at 11:52 PM, jimtabor(a)svn.reactos.org wrote: > Author: jimtabor > Date: Mon Mar 8 21:52:04 2010 > New Revision: 46006 > > URL: http://svn.reactos.org/svn/reactos?rev=46006&view=rev > Log: > - [User32_winetest] > - Win : Remove test_capture from service. This is related to > TrackMouseEvent issues which use SetCapture. > > Modified: > trunk/rostests/winetests/user32/win.c > > Modified: trunk/rostests/winetests/user32/win.c > URL: http://svn.reactos.org/svn/reactos/trunk/rostests/winetests/ > user32/win.c?rev=46006&r1=46005&r2=46006&view=diff > ====================================================================== > ======== > --- trunk/rostests/winetests/user32/win.c [iso-8859-1] (original) > +++ trunk/rostests/winetests/user32/win.c [iso-8859-1] Mon Mar 8 > 21:52:04 2010 > @@ -5979,7 +5979,7 @@ > test_capture_1(); > test_capture_2(); > test_capture_3(hwndMain, hwndMain2); > - test_capture_4(); > +// test_capture_4(); > > test_CreateWindow(); > test_parent_owner(); > >

15 years, 4 months

1
0
0 0

ros-diffs] [sir_richard] 46027: [WIN32K]: Stub-plement NtUserSetInformationThread for UserInitiateShutdown and UserEndShutdown. I think we're supposed to notify Winlogon at some point, and check for races. Part of new shutdown code.

by James Tabor

Hi, Look for ntuser/defwnd.c and read the beginning of the file that deals with shutdown messages, it passes all the wine tests. If you need something, just ask, I will implement it. Thanks, James

15 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 46011: [CMBATT] - Add initial cmbatt driver which mostly stubs - All it does right now is register a battery device with the battc driver [BATTC] - Add a nearly complete battc driver (the only stuff missing is WMI) - Tested with

by Ged Murphy

cgutman(a)svn.reactos.org wrote: > +BCLASSAPI > +NTSTATUS > +DDKAPI > +BatteryClassSystemControl(PVOID ClassData, > + PWMILIB_CONTEXT WmiLibContext, > + PDEVICE_OBJECT DeviceObject, > + PIRP Irp, > + PSYSCTL_IRP_DISPOSITION Disposition) > +{ > + NTSTATUS Status; > + > + UNIMPLEMENTED > + > + /* FIXME: Uncomment when WmiCompleteRequest is implemented */ > +#if 0 > + Status = STATUS_WMI_GUID_NOT_FOUND; > + WmiCompleteRequest(DeviceObject, > + Irp, > + Status, > + 0, > + IO_NO_INCREMENT); > +#else > + Irp->IoStatus.Status = Status = STATUS_WMI_GUID_NOT_FOUND; > + Irp->IoStatus.Information = 0; > + > + IoCompleteRequest(Irp, IO_NO_INCREMENT); > +#endif > + > + return Status; > +} > + This isn't how WMI works at all

15 years, 4 months

1
0
0 0

Trunk lockage

by Aleksey Bragin

Hi, trunk is locked until (at least) debug buildslave is back online. Also, it's a good occasion to actually FIX all those hanging tests (fix, hackfix, anyotherwaytofix) which lead to buildslaves timewaste (compare: 4 minutes to build and 1 hour to test). This is unbearable. Test results should be available within minutes, and allow easy tracking of failures. WBR, Aleksey Bragin.

15 years, 4 months

9
9
0 0

Buildbot currently broken

by Sylvain Petreolle

Hello, The buildbot slaves are currently offline due to a boot problem and won't be brought back up until monday. Please don't commit to trunk and branches until that. Kind regards, Sylvain Petreolle

15 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [evb] 45873: - Add new unified VGA/VBE miniport driver. Based on NT4 DDK Cirrus Miniport Driver Sample with my modifications (marked with // eVb) to change Cirrus parts to VGA parts if needed. Also add VBE suppor which is not in Cirru

by Steven Edwards

Does the EULA allow you to redistribute sample code without stipulations? I seem to recall certain versions of the DDK requiring that derivative works be used only with a Windows OS. Can you please send me a copy of the EULA for the DDK? Thanks Steven On Fri, Mar 5, 2010 at 12:22 PM, <evb(a)svn.reactos.org> wrote: > Author: evb > Date: Fri Mar 5 18:22:18 2010 > New Revision: 45873 > > URL: http://svn.reactos.org/svn/reactos?rev=45873&view=rev > Log: > - Add new unified VGA/VBE miniport driver. Based on NT4 DDK Cirrus Miniport Driver Sample with my modifications (marked with // eVb) to change Cirrus parts to VGA parts if needed. Also add VBE suppor which is not in Cirrus driver, but exists in Windows VGA miniport. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

15 years, 5 months

4
7
0 0

Re: [ros-dev] [ros-diffs] [hpoussin] 45809: [hal] Add a mini-HAL static library Mostly the same thing as the real one, except interrupts and DMA

by Timo Kreuzer

While the idea of sharing code between hal and freeldr is good, I think the current approach is not the best. so far it caused recompilation for a lot of hal code and added a lot of support code and only very few shared code. I would suggest to implement an x86 Hw / Bios library, containing the shared code and using it from hal and freeldr. This is IMO cleaner then implementing ExAllocatePool etc in freeldr. And can't we use RTL's heap instead of bget in freeldr? Just my 2 cents, Timo hpoussin(a)svn.reactos.org schrieb: > Author: hpoussin > Date: Wed Mar 3 22:56:52 2010 > New Revision: 45809 > > URL: http://svn.reactos.org/svn/reactos?rev=45809&view=rev > Log: > [hal] Add a mini-HAL static library > Mostly the same thing as the real one, except interrupts and DMA > > Modified: > trunk/reactos/hal/halx86/generic/bios.c > trunk/reactos/hal/halx86/generic/bus/halbus.c > trunk/reactos/hal/halx86/generic/bus/pcibus.c > trunk/reactos/hal/halx86/generic/bus/pcidata.c > trunk/reactos/hal/halx86/generic/display.c > trunk/reactos/hal/halx86/generic/dma.c > trunk/reactos/hal/halx86/generic/halinit.c > trunk/reactos/hal/halx86/generic/misc.c > trunk/reactos/hal/halx86/generic/pic.c > trunk/reactos/hal/halx86/generic/reboot.c > trunk/reactos/hal/halx86/generic/systimer.S > trunk/reactos/hal/halx86/generic/timer.c > trunk/reactos/hal/halx86/generic/usage.c > trunk/reactos/hal/halx86/hal_generic.rbuild > trunk/reactos/hal/halx86/include/hal.h > > Modified: trunk/reactos/hal/halx86/generic/bios.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/bios.c?… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/bios.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/bios.c [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -196,6 +196,7 @@ > > /* V86 TRAP HANDLERS **********************************************************/ > > +#ifndef _MINIHAL_ > VOID > FASTCALL > DECLSPEC_NORETURN > @@ -234,6 +235,7 @@ > longjmp(HalpSavedContext, 1); > UNREACHABLE; > } > +#endif > > /* V8086 ENTER ****************************************************************/ > > @@ -497,6 +499,7 @@ > HalpFlushTLB(); > } > > +#ifndef _MINIHAL_ > VOID > NTAPI > HalpSwitchToRealModeTrapHandlers(VOID) > @@ -517,6 +520,7 @@ > // > KeRegisterInterruptHandler(6, HalpTrap06); > } > +#endif > > VOID > NTAPI > @@ -626,6 +630,7 @@ > HalpFlushTLB(); > } > > +#ifndef _MINIHAL_ > BOOLEAN > NTAPI > HalpBiosDisplayReset(VOID) > @@ -695,5 +700,6 @@ > __writeeflags(Flags); > return TRUE; > } > +#endif > > /* EOF */ > > Modified: trunk/reactos/hal/halx86/generic/bus/halbus.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/bus/hal… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/bus/halbus.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/bus/halbus.c [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -27,8 +27,10 @@ > KdReleasePciDeviceforDebugging = HalpReleasePciDeviceForDebugging; > > /* Register memory functions */ > +#ifndef _MINIHAL_ > KdMapPhysicalMemory64 = HalpMapPhysicalMemory64; > KdUnmapVirtualAddress = HalpUnmapVirtualAddress; > +#endif > > /* Register ACPI stub */ > KdCheckPowerButton = HalpCheckPowerButton; > > Modified: trunk/reactos/hal/halx86/generic/bus/pcibus.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/bus/pci… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/bus/pcibus.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/bus/pcibus.c [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -702,6 +702,7 @@ > NTAPI > HalpQueryPciRegistryInfo(VOID) > { > +#ifndef _MINIHAL_ > WCHAR NameBuffer[8]; > OBJECT_ATTRIBUTES ObjectAttributes; > UNICODE_STRING KeyName, ConfigName, IdentName; > @@ -924,6 +925,9 @@ > > /* Return it */ > return PciRegistryInfo; > +#else > + return NULL; > +#endif > } > > VOID > > Modified: trunk/reactos/hal/halx86/generic/bus/pcidata.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/bus/pci… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/bus/pcidata.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/bus/pcidata.c [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -14,6 +14,7 @@ > > /* GLOBALS *******************************************************************/ > > +#ifndef _MINIHAL_ > CHAR ClassTable[3922] = > { > 0x43, 0x20, 0x30, 0x30, 0x20, 0x20, 0x55, 0x6E, 0x63, 0x6C, 0x61, 0x73, 0x73, 0x69, 0x66, 0x69, > @@ -40415,3 +40416,4 @@ > 0x20, 0x49, 0x6C, 0x6C, 0x65, 0x67, 0x61, 0x6C, 0x20, 0x56, 0x65, 0x6E, 0x64, 0x6F, 0x72, 0x20, > 0x49, 0x44, 0x00, > }; > +#endif > > Modified: trunk/reactos/hal/halx86/generic/display.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/display… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/display.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/display.c [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -31,8 +31,10 @@ > NTAPI > HalDisplayString(IN PCH String) > { > +#ifndef _MINIHAL_ > /* Call the Inbv driver */ > InbvDisplayString(String); > +#endif > } > > /* > > Modified: trunk/reactos/hal/halx86/generic/dma.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/dma.c?r… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/dma.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/dma.c [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -75,11 +75,15 @@ > #define NDEBUG > #include <debug.h> > > +#ifndef _MINIHAL_ > static KEVENT HalpDmaLock; > static LIST_ENTRY HalpDmaAdapterList; > static PADAPTER_OBJECT HalpEisaAdapter[8]; > +#endif > static BOOLEAN HalpEisaDma; > +#ifndef _MINIHAL_ > static PADAPTER_OBJECT HalpMasterAdapter; > +#endif > > static const ULONG_PTR HalpEisaPortPage[8] = { > FIELD_OFFSET(DMA_PAGE, Channel0), > @@ -92,6 +96,7 @@ > FIELD_OFFSET(DMA_PAGE, Channel7) > }; > > +#ifndef _MINIHAL_ > static DMA_OPERATIONS HalpDmaOperations = { > sizeof(DMA_OPERATIONS), > (PPUT_DMA_ADAPTER)HalPutDmaAdapter, > @@ -111,6 +116,7 @@ > NULL /*(PBUILD_SCATTER_GATHER_LIST)HalBuildScatterGatherList*/, > NULL /*(PBUILD_MDL_FROM_SCATTER_GATHER_LIST)HalBuildMdlFromScatterGatherList*/ > }; > +#endif > > #define MAX_MAP_REGISTERS 64 > > @@ -118,6 +124,7 @@ > > /* FUNCTIONS *****************************************************************/ > > +#ifndef _MINIHAL_ > VOID > HalpInitDma(VOID) > { > @@ -154,6 +161,7 @@ > */ > HalGetDmaAdapter = HalpGetDmaAdapter; > } > +#endif > > /** > * @name HalpGetAdapterMaximumPhysicalAddress > @@ -185,6 +193,7 @@ > return HighestAddress; > } > > +#ifndef _MINIHAL_ > /** > * @name HalpGrowMapBuffers > * > @@ -428,6 +437,7 @@ > > return AdapterObject; > } > +#endif > > /** > * @name HalpDmaInitializeEisaAdapter > @@ -564,6 +574,7 @@ > return TRUE; > } > > +#ifndef _MINIHAL_ > /** > * @name HalGetAdapter > * > @@ -896,6 +907,7 @@ > Length, > CacheEnabled ? MmCached : MmNonCached); > } > +#endif > > /** > * @name HalpDmaGetDmaAlignment > @@ -984,6 +996,7 @@ > return Count; > } > > +#ifndef _MINIHAL_ > /** > * @name HalpGrowMapBufferWorker > * > @@ -1893,6 +1906,7 @@ > */ > return PhysicalAddress; > } > +#endif > > /** > * @name HalFlushCommonBuffer > > Modified: trunk/reactos/hal/halx86/generic/halinit.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/halinit… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/halinit.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/halinit.c [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -91,8 +91,10 @@ > KeBugCheckEx(MISMATCHED_HAL, 1, Prcb->MajorVersion, 1, 0); > } > > +#ifndef _MINIHAL_ > /* Initialize the PICs */ > HalpInitializePICs(TRUE); > +#endif > > /* Force initial PIC state */ > KfRaiseIrql(KeGetCurrentIrql()); > @@ -107,9 +109,17 @@ > HalQuerySystemInformation = HaliQuerySystemInformation; > HalSetSystemInformation = HaliSetSystemInformation; > HalInitPnpDriver = NULL; // FIXME: TODO > +#ifndef _MINIHAL_ > HalGetDmaAdapter = HalpGetDmaAdapter; > +#else > + HalGetDmaAdapter = NULL; > +#endif > HalGetInterruptTranslator = NULL; // FIXME: TODO > +#ifndef _MINIHAL_ > HalResetDisplay = HalpBiosDisplayReset; > +#else > + HalResetDisplay = NULL; > +#endif > HalHaltSystem = HaliHaltSystem; > > /* Register IRQ 2 */ > @@ -125,8 +135,10 @@ > /* Setup busy waiting */ > HalpCalibrateStallExecution(); > > +#ifndef _MINIHAL_ > /* Initialize the clock */ > HalpInitializeClock(); > +#endif > > /* > * We could be rebooting with a pending profile interrupt, > @@ -142,6 +154,7 @@ > /* Initialize bus handlers */ > HalpInitBusHandler(); > > +#ifndef _MINIHAL_ > /* Enable IRQ 0 */ > HalpEnableInterruptHandler(IDT_DEVICE, > 0, > @@ -160,6 +173,7 @@ > > /* Initialize DMA. NT does this in Phase 0 */ > HalpInitDma(); > +#endif > > /* Do some HAL-specific initialization */ > HalpInitPhase1(); > > Modified: trunk/reactos/hal/halx86/generic/misc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/misc.c?… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/misc.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/misc.c [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -28,6 +28,7 @@ > return; > } > > +#ifndef _MINIHAL_ > PVOID > NTAPI > HalpMapPhysicalMemory64(IN PHYSICAL_ADDRESS PhysicalAddress, > @@ -51,6 +52,7 @@ > // > MmUnmapIoSpace(VirtualAddress, NumberPages << PAGE_SHIFT); > } > +#endif > > VOID > NTAPI > @@ -122,6 +124,7 @@ > NTAPI > HalHandleNMI(IN PVOID NmiInfo) > { > +#ifndef _MINIHAL_ > SYSTEM_CONTROL_PORT_B_REGISTER SystemControl; > > // > @@ -202,6 +205,7 @@ > // Halt the system > // > InbvDisplayString("\n*** The system has halted ***\n"); > +#endif > > // > // Enter the debugger if possible > > Modified: trunk/reactos/hal/halx86/generic/pic.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/pic.c?r… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/pic.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/pic.c [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -14,6 +14,7 @@ > > /* GLOBALS ********************************************************************/ > > +#ifndef _MINIHAL_ > /* > * This table basically keeps track of level vs edge triggered interrupts. > * Windows has 250+ entries, but it seems stupid to replicate that since the PIC > @@ -1335,3 +1336,28 @@ > } > } > > +#else > + > +KIRQL > +NTAPI > +KeGetCurrentIrql(VOID) > +{ > + return PASSIVE_LEVEL; > +} > + > +VOID > +FASTCALL > +KfLowerIrql( > + IN KIRQL OldIrql) > +{ > +} > + > +KIRQL > +FASTCALL > +KfRaiseIrql( > + IN KIRQL NewIrql) > +{ > + return NewIrql; > +} > + > +#endif > > Modified: trunk/reactos/hal/halx86/generic/reboot.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/reboot.… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/reboot.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/reboot.c [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -98,8 +98,10 @@ > case HalHaltRoutine: > case HalRebootRoutine: > > +#ifndef _MINIHAL_ > /* Acquire the display */ > InbvAcquireDisplayOwnership(); > +#endif > > /* Call the internal reboot function */ > HalpReboot(); > > Modified: trunk/reactos/hal/halx86/generic/systimer.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/systime… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/systimer.S [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/systimer.S [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -329,6 +329,7 @@ > ret > .endfunc > > +#ifndef _MINIHAL_ > .globl _KeStallExecutionProcessor@4 > .func KeStallExecutionProcessor@4 > _KeStallExecutionProcessor@4: > @@ -359,6 +360,7 @@ > /* Return */ > ret 4 > .endfunc > +#endif > > .global _KeQueryPerformanceCounter@4 > .func KeQueryPerformanceCounter@4 > > Modified: trunk/reactos/hal/halx86/generic/timer.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/timer.c… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/timer.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/timer.c [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -109,6 +109,7 @@ > HalpCurrentRollOver = RollOver; > } > > +#ifndef _MINIHAL_ > VOID > FASTCALL > HalpClockInterruptHandler(IN PKTRAP_FRAME TrapFrame) > @@ -160,6 +161,7 @@ > /* Spurious, just end the interrupt */ > KiEoiHelper(TrapFrame); > } > +#endif > > > /* PUBLIC FUNCTIONS ***********************************************************/ > > Modified: trunk/reactos/hal/halx86/generic/usage.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/usage.c… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/usage.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/usage.c [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -63,6 +63,7 @@ > HalpIDTUsage[SystemVector].BusReleativeVector = BusVector; > } > > +#ifndef _MINIHAL_ > VOID > NTAPI > HalpEnableInterruptHandler(IN UCHAR Flags, > @@ -87,6 +88,7 @@ > /* Enable the interrupt */ > HalEnableSystemInterrupt(SystemVector, Irql, Mode); > } > +#endif > > /* > * @unimplemented > > Modified: trunk/reactos/hal/halx86/hal_generic.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/hal_generic.rbu… > ============================================================================== > --- trunk/reactos/hal/halx86/hal_generic.rbuild [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/hal_generic.rbuild [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -35,4 +35,41 @@ > <pch>hal.h</pch> > </directory> > </module> > + <module name="mini_hal" type="objectlibrary"> > + <include>include</include> > + <include base="ntoskrnl">include</include> > + <define name="_NTHAL_" /> > + <define name="_NTSYSTEM_" /> > + <define name="_MINIHAL_" /> > + <directory name="generic"> > + <directory name="bus"> > + <file>bushndlr.c</file> > + <file>isabus.c</file> > + <file>halbus.c</file> > + <file>pcibus.c</file> > + <file>pcidata.c</file> > + <file>sysbus.c</file> > + </directory> > + <file>beep.c</file> > + <file>bios.c</file> > + <file>cmos.c</file> > + <file>dma.c</file> > + <file>display.c</file> > + <file>drive.c</file> > + <file>misc.c</file> > + <file>pic.c</file> > + <file>portio.c</file> > + <file>processor.c</file> > + <file>profil.c</file> > + <file>reboot.c</file> > + <file>spinlock.c</file> > + <file>sysinfo.c</file> > + <file>systimer.S</file> > + <file>timer.c</file> > + <file>usage.c</file> > + </directory> > + <directory name="up"> > + <file>halinit_up.c</file> > + </directory> > + </module> > </group> > > Modified: trunk/reactos/hal/halx86/include/hal.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/include/hal.h?r… > ============================================================================== > --- trunk/reactos/hal/halx86/include/hal.h [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/include/hal.h [iso-8859-1] Wed Mar 3 22:56:52 2010 > @@ -17,8 +17,12 @@ > #undef _NTHAL_ > #undef DECLSPEC_IMPORT > #define DECLSPEC_IMPORT > +#ifndef _MINIHAL_ > #undef NTSYSAPI > #define NTSYSAPI __declspec(dllimport) > +#else > +#undef _NTSYSTEM_ > +#endif > > /* IFS/DDK/NDK Headers */ > #include <ntifs.h> > > > >

15 years, 5 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 45775: - Initialize the ACPI table (the exact same we do it in KiRosFrldrLpbToNtLpb) - Fixes ACPI detection when booted in Windows-compatible mode

by Aleksey Bragin

I think this breaks real Windows bootloading support. WBR, Aleksey Bragin. On Mar 3, 2010, at 5:38 AM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Wed Mar 3 03:38:56 2010 > New Revision: 45775 > > URL: http://svn.reactos.org/svn/reactos?rev=45775&view=rev > Log: > - Initialize the ACPI table (the exact same we do it in > KiRosFrldrLpbToNtLpb) > - Fixes ACPI detection when booted in Windows-compatible mode > > Modified: > trunk/reactos/boot/freeldr/freeldr/windows/winldr.c > > Modified: trunk/reactos/boot/freeldr/freeldr/windows/winldr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/ > freeldr/windows/winldr.c?rev=45775&r1=45774&r2=45775&view=diff > ====================================================================== > ======== > --- trunk/reactos/boot/freeldr/freeldr/windows/winldr.c > [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/windows/winldr.c > [iso-8859-1] Wed Mar 3 03:38:56 2010 > @@ -37,6 +37,7 @@ > > extern BOOLEAN UseRealHeap; > extern ULONG LoaderPagesSpanned; > +extern BOOLEAN AcpiPresent; > > BOOLEAN > WinLdrCheckForLoadedDll(IN OUT PLOADER_PARAMETER_BLOCK WinLdrBlock, > @@ -195,6 +196,13 @@ > Extension->MajorVersion = (VersionToBoot & 0xFF00) >> 8; > Extension->MinorVersion = VersionToBoot & 0xFF; > Extension->Profile.Status = 2; > + > + /* Check if ACPI is present */ > + if (AcpiPresent) > + { > + /* See KiRosFrldrLpbToNtLpb for details */ > + Extension->AcpiTable = (PVOID)1; > + } > > /* Load drivers database */ > strcpy(MiscFiles, BootPath); > >

15 years, 5 months

1
0
0 0

Wine Gecko Installer @ 2nd boot

by James Tabor

Hi! I guess we need to vendor drop and add to our build this missing component. James

15 years, 5 months

3
3
0 0

Re: [ros-dev] [ros-diffs] [sir_richard] 45777: [NTOS]: Do the "funny message" (not really funny, my apologies) shenanigans after the system components have shutdown, and reset the display and call the HAL at least at DPC level (should probably do it

by WaxDragon

Axe them. On Mar 3, 2010 3:51 AM, "Christoph von Wittich" <Christoph(a)apiviewer.de> wrote: remove++ Am 03.03.2010 09:31, schrieb Ged Murphy: > sir_richard(a)svn.reactos.org wrote: > >> Did you know the "funny messages" take up more storage sp...

15 years, 5 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [sir_richard] 45777: [NTOS]: Do the "funny message" (not really funny, my apologies) shenanigans after the system components have shutdown, and reset the display and call the HAL at least at DPC level (should probably do it

by Olaf Siejka

This space can be used better by ACPI finally working, not to mention tha ACPI will render it useless anyway. remove++ 2010/3/3 Christoph von Wittich <Christoph(a)apiviewer.de> > remove++ > > Am 03.03.2010 09:31, schrieb Ged Murphy: > > sir_richard(a)svn.reactos.org wrote: > > > >> Did you know the "funny messages" take up more storage space than an > average embedded micro-controller OS? > > > > I've never liked these and I think they should be removed. > > They aren't funny and I'm not 12 years old.... > > > > Ged. > > > > > > > > > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

15 years, 5 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [sir_richard] 45777: [NTOS]: Do the "funny message" (not really funny, my apologies) shenanigans after the system components have shutdown, and reset the display and call the HAL at least at DPC level (should probably do it at HIGH IRQL, r

by Ged Murphy

sir_richard(a)svn.reactos.org wrote: > Did you know the "funny messages" take up more storage space than an average embedded micro-controller OS? I've never liked these and I think they should be removed. They aren't funny and I'm not 12 years old.... Ged.

15 years, 5 months

3
3
0 0

Time to Branch for Release

by James Tabor

FYI, I've tested Firefox 3.6, SeaMonkey 2.0.3, OOo 2.4.3, AbiWord 2.6.8 and bot tests are okay with Qemu and Hardware at rev 45734. James

15 years, 5 months

4
6
0 0

Re: [ros-dev] [ros-diffs] [janderwald] 45759: [KSPROXY] - Implement IPersistPropertyBag interface - Implement IKsObject interface - Implement enumerating supported property/method/event set from driver and loading the corresponding ksproxy plugins

by Ged Murphy

janderwald(a)svn.reactos.org wrote: > - OutputDebugString("UNIMPLEMENTED\n"); > + OutputDebugStringW(L"UNIMPLEMENTED\n"); Why the change? This is one of the few functions when it's better to use the A version as the W version calls the A Ged.

15 years, 5 months

1
0
0 0

Re: [ros-dev] Ros-dev Digest, Vol 67, Issue 2

by ODD Death

Most Visual Basic 6 and Visual C++ applications are working fine, i have tested FLV CAP but having problems in socket binding...

15 years, 5 months

1
0
0 0

Problem with _IO_STACK_LOCATION defines in winddk.h

by Wiljan Derks

I am trying to build 64 drivers using gcc. I actually got a driver working now but had to fix a problem in winddk.h winddk.h has the following line just before "typedef struct _IO_STACK_LOCATION": #include <pshpack4.h> That causes gcc to ignore the "POINTER_ALIGNMENT" attributes used inside this struct. So it does not align these fields to the next 8 byte multiple as required for 64 bit. I now removed the "#include <pshpack4.h>" and the "#include <poppack.h>" at the end and that make the structure work properly on 64 bit for at least the iocontrol. Wiljan

15 years, 5 months

1
0
0 0

ReactOS, Andrew Faulds has invited you to open a Google mail account

by Andrew Faulds

I've been using Google Mail and thought you might like to try it out. Here's an invitation to create an account. ----------------------------------------------------------------------- Andrew Faulds has invited you to open a free Google Mail account. To accept this invitation and register for your account, visit http://mail.google.com/mail/a-e6777bd09-b4d66660a7-cc7400ade44d27c3 Once you create your account, Andrew Faulds will be notified with your new email address so you can stay in touch with Google Mail! If you haven't already heard about Google Mail, it's a new search-based webmail service that offers: - Over 2,700 megabytes (two gigabytes) of free storage - Built-in Google search that instantly finds any message you want - Automatic arrangement of messages and related replies into "conversations" - Powerful spam protection using innovative Google technology - No large, annoying ads--just small text ads and related pages that are relevant to the content of your messages To learn more about Google Mail before registering, visit: http://mail.google.com/mail/help/intl/en_GB/benefits.html We're still working every day to improve Google Mail, so we might ask for your comments and suggestions periodically. We hope you'll like Google Mail. We do. And, it's only going to get better. Thanks, The Google Mail Team (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser).

15 years, 5 months

1
0
0 0

Real HW Regression. Richard, this is for you

by Daniel Reimer

Hi, first my congratz to the great work you do recently. HAL really needed your attention :-D But... I stumbled over a nice regression last night. I wanted to install HEAD on the Notebook we will use on Chemnitzer Linux Tage to show ROS and failed to get to 1st stage at all. After some regression testing I tracked this down to this range: r45319 still works up to 3rd stage. r45324 fails to even get in 1st stage. The 5 revs in between dont build at all, because r45324 was a build fix for r45320 and this one was a biiig rewrite by Richard. The screen stays black and when I blindly type "CONT" , I get: ***STOP: 0x0000007B (0xF1BCDB60,0xC0000034,0x00000000,0x00000000) Its a really big problem to get more output from it because it has no Serial Ports at all. We tried to set /DEBUG DEBUGPORT=SCREEN /SOS but nothing shows up. So if someone finds a possible reason for that regression or a nice way to get the needed debuggin Information, plz tell me. It would be very important to get ROS run on it again. Machine is a: Acer Extensa 4100 wmli / Aspire 1690 wmli Acer Crane Mainboard Intel Pentium III Mobile CPU ATI Mobility Radeon X700 1 GB DDR RAM Thx for the help.

15 years, 5 months

1
0
0 0

Is Sound Support added

by Arko Provo Mukherjee

Hi Gurus, Like to know whether we have Sound Support for React OS. If not is there any development going on for this? Can you give me the contact of the person who is working on incorporating / maintaining sound support in React OS? Kind Regards Arko

15 years, 5 months

2
3
0 0

Trunk is broken

by Gabriel ilardi

Hi all, Just that this doesn't get lost, trunk's broken in two ways: 1) after 45640 you get the "CMP_WaitNoPending..." in 2nd stage in vbox being unable to proceed. Bug 4142: http://www.reactos.org/bugzilla/show_bug.cgi?id=4142 2) after 45645 installation stops at 1st stage with an assert: Assertion 'GuardedMutex->Owner != Thread' failed at ntoskrnl\include\/internal/k e_x.h line 1596 Entered debugger on embedded INT3 at 0x0008:0x808dc52e. kdb:> PuTTYbt Eip: <ntoskrnl.exe:dc52f (lib\rtl\i386\debug_asm.S:33 (DbgBreakPoint@0))> Frames: <ntoskrnl.exe:9aaa4 (ntoskrnl/include//internal/ke_x.h:1596 (MmNotPresentFault@1 2))> <ntoskrnl.exe:9b6e3 (ntoskrnl/mm/mmfault.c:298 (MmAccessFault@16))> <ntoskrnl.exe:66fb (ntoskrnl/ke/i386/traphdlr.c:1132 (@KiTrap0EHandler@4))> <ntoskrnl.exe:1b21c (ntoskrnl/cc/view.c:463 (CcRosLookupCacheSegment@8))> <ntoskrnl.exe:ac31a (ntoskrnl/mm/section.c:1251 (MmNotPresentFaultSectionView@16 ))> <ntoskrnl.exe:9adb9 (ntoskrnl/mm/mmfault.c:219 (MmNotPresentFault@12))> <ntoskrnl.exe:9b6e3 (ntoskrnl/mm/mmfault.c:298 (MmAccessFault@16))> <ntoskrnl.exe:66fb (ntoskrnl/ke/i386/traphdlr.c:1132 (@KiTrap0EHandler@4))> <b085a008> <ntoskrnl.exe:601e <ntoskrnl.exe:6412 (ntoskrnl/ke/i386/traphdlr.c:1517 (@KiFastC allEntryHandler@8))> <00000000> kdb:> Thanks. _________________________________________________________________ La tua privacy è al sicuro con Internet Explorer 8. Scopri di più http://www.microsoft.com/italy/windows/internet-explorer/features/browse-pr…

15 years, 5 months

5
4
0 0

Hive Corruption

by James Tabor

FYI! I noticed a strange bug when working with OOo 2.4.3 after installing and running writer, then closing it, there was a random crash! This resulted in a hive corruption crash leaving the system unbootable! The only change I did was svn up trunk to the current revision 45668. Last revision was something bootable before 45640. The changes I've commit have been tested for over two weeks and some new ones this week. Thanks, James

15 years, 5 months

1
0
0 0

[ros-diffs] [tkreuzer] 45659: [GDI32] - Quickfix the region leak, by commenting out the user mode part in DeleteRegion. Thanks to Caemyr for finding the guilty revision.

by James Tabor

Thanks Caemyr!!!! Kick Ass!!! Wow,,,, that means GdiBatch has been turned off? I'll look into that soon as I get back. Thanks, James

15 years, 5 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 45640: Partially revert patches 45626 and 45633. Several services do not report their status to the service manager properly. Therefore we must not use any code that relies on service status information as part of the setup and boo

by Ged Murphy

Are these our services and if so do you have a note of which ones? -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of ekohl(a)svn.reactos.org Sent: 20 February 2010 23:11 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [ekohl] 45640: Partially revert patches 45626 and 45633. Several services do not report their status to the service manager properly. Therefore we must not use any code that relies on service status information as part of the setup and boot pr Author: ekohl Date: Sun Feb 21 00:10:53 2010 New Revision: 45640 URL: http://svn.reactos.org/svn/reactos?rev=45640&view=rev Log: Partially revert patches 45626 and 45633. Several services do not report their status to the service manager properly. Therefore we must not use any code that relies on service status information as part of the setup and boot processes as long as these issues have not been fixed. The service manager still needs to provide fake information about the service status. Modified: trunk/reactos/base/system/services/database.c trunk/reactos/dll/win32/syssetup/install.c Modified: trunk/reactos/base/system/services/database.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/services/datab… ============================================================================== --- trunk/reactos/base/system/services/database.c [iso-8859-1] (original) +++ trunk/reactos/base/system/services/database.c [iso-8859-1] Sun Feb 21 00:10:53 2010 @@ -1054,7 +1054,7 @@ { Group->ServicesRunning = TRUE; } - Service->Status.dwCurrentState = SERVICE_START_PENDING; + Service->Status.dwCurrentState = SERVICE_RUNNING; } #if 0 else Modified: trunk/reactos/dll/win32/syssetup/install.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/syssetup/install… ============================================================================== --- trunk/reactos/dll/win32/syssetup/install.c [iso-8859-1] (original) +++ trunk/reactos/dll/win32/syssetup/install.c [iso-8859-1] Sun Feb 21 00:10:53 2010 @@ -473,34 +473,17 @@ static BOOL EnableUserModePnpManager(VOID) { - SERVICE_STATUS_PROCESS ServiceStatus; SC_HANDLE hSCManager = NULL; SC_HANDLE hService = NULL; - DWORD dwStartTickCount; - DWORD dwOldCheckPoint; - DWORD BytesNeeded = 0; - DWORD dwWaitTime; - DWORD dwMaxWait; - HANDLE hEvent; BOOL ret = FALSE; - hEvent = OpenEventW(EVENT_ALL_ACCESS, - FALSE, - L"SC_AutoStartComplete"); - if (hEvent == NULL) - goto cleanup; - - WaitForSingleObject(hEvent, INFINITE); - - hSCManager = OpenSCManager(NULL, - NULL, - SC_MANAGER_CONNECT); + hSCManager = OpenSCManager(NULL, NULL, 0); if (hSCManager == NULL) goto cleanup; hService = OpenServiceW(hSCManager, L"PlugPlay", - SERVICE_CHANGE_CONFIG | SERVICE_START | SERVICE_QUERY_STATUS); + SERVICE_CHANGE_CONFIG | SERVICE_START); if (hService == NULL) goto cleanup; @@ -515,69 +498,9 @@ ret = StartServiceW(hService, 0, NULL); if (!ret) - { - /* If the service is already running, just return TRUE */ - ret = GetLastError() == ERROR_SERVICE_ALREADY_RUNNING; goto cleanup; - } - - ret = QueryServiceStatusEx(hService, - SC_STATUS_PROCESS_INFO, - (LPBYTE)&ServiceStatus, - sizeof(SERVICE_STATUS_PROCESS), - &BytesNeeded); - if (!ret) - goto cleanup; - - /* We don't want to wait for more than 30 seconds */ - dwMaxWait = 30000; - dwStartTickCount = GetTickCount(); - - /* Loop until it's running */ - while (ServiceStatus.dwCurrentState != SERVICE_RUNNING) - { - dwOldCheckPoint = ServiceStatus.dwCheckPoint; - dwWaitTime = ServiceStatus.dwWaitHint / 10; - - /* Get the latest status info */ - if (!QueryServiceStatusEx(hService, - SC_STATUS_PROCESS_INFO, - (LPBYTE)&ServiceStatus, - sizeof(SERVICE_STATUS_PROCESS), - &BytesNeeded)) - { - /* Something went wrong... */ - break; - } - - /* Is the service making progress? */ - if (ServiceStatus.dwCheckPoint > dwOldCheckPoint) - { - /* It is, get the latest tickcount to reset the max wait time */ - dwStartTickCount = GetTickCount(); - dwOldCheckPoint = ServiceStatus.dwCheckPoint; - } - else - { - /* It's not, make sure we haven't exceeded our wait time */ - if (GetTickCount() >= dwStartTickCount + dwMaxWait) - { - /* We have, give up */ - break; - } - } - - /* Adjust the wait hint times */ - if (dwWaitTime < 200) - dwWaitTime = 200; - else if (dwWaitTime > 10000) - dwWaitTime = 10000; - - /* Wait before trying again */ - Sleep(dwWaitTime); - } - - ret = ServiceStatus.dwCurrentState == SERVICE_RUNNING; + + ret = TRUE; cleanup: if (hSCManager != NULL)

15 years, 5 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 45637: [SERVICES] Disable a number of debug messages in the service manager.

by Aleksey Bragin

On Feb 20, 2010, at 11:52 PM, ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Sat Feb 20 21:52:14 2010 > New Revision: 45637 > > URL: http://svn.reactos.org/svn/reactos?rev=45637&view=rev > Log: > [SERVICES] > Disable a number of debug messages in the service manager. > - DPRINT1("RpcServerUseProtseqEpW() failed (Status %lx)\n", > Status); > + DPRINT("RpcServerUseProtseqEpW() failed (Status %lx)\n", > Status); > - DPRINT1("RpcServerRegisterIf() failed (Status %lx)\n", > Status); > + DPRINT("RpcServerRegisterIf() failed (Status %lx)\n", > Status); ..etc Why disable critical failures notifications? Or they are not so critical?

15 years, 5 months

2
1
0 0

Test Bot Crash

by James Tabor

I'm aware of the crash and it should have updated on the next commit. I'll add the ros hack back to the gdi32 font.c test when I get back. James

15 years, 5 months

2
2
0 0

Use Mobile Save Paper

by arkoprovomukherjee＠gmail.com

15 years, 5 months

2
1
0 0

Test Bot Crash!

by James Tabor

45619 Running Wine Test, Module: msi, Test: msi <Snip ,,,...> msi.c:2502: Test failed: Expected lang to be unchanged, got 1033 msi.c:2504: Test failed: Expected 260, got 4 msi: 3328 tests executed (0 marked as todo, 181 failures), 0 skipped. (ARM³::PAGFAULT:306) FAULT ON PAGE TABLES! (ARM³::PAGFAULT:313) PAGE TABLES FAULTED IN! (ARM³::PAGFAULT:306) FAULT ON PAGE TABLES! (ARM³::PAGFAULT:313) PAGE TABLES FAULTED IN! Non stop!

15 years, 5 months

1
0
0 0

arwinss does not mean compatibility

by James Tabor

The point was made on IRC, if we are having issues, "I'll just have to use arwinss then". This was in reference to the region leak. We see the leak due to the compatibility of ReactOS. We use tools from the "Net" to examine the GDI handle counts. Might I add a point, these tools are written for Windows. ;^) How do we really know that the same leak does not occur with arwinss. Are there tools to measure this? Are there checks in wine to make sure wine does not exceed a limit? So far, from the patches added to arwinss from ReactOS, there are limitations to the use of wine. These same patches have been added to ReactOS after porting wine. Is it safe to assume, we have these same limitations in ReactOS? Can we help that we use wine 24/7 when we sync/port from wine? ReactOS has the same bugs if we do. Over and over this has been the issue in the past. Pick on someone else for this leak, I'm not looking for it anymore, James There was a leak before I started to fix it. Bug 4980

15 years, 5 months

2
2
0 0

Trunk locked

by Aleksey Bragin

Hello, the trunk is locked to find and fix regressions introduced since January, 2010. Members of the bugfixing team are: sir_richard, Physicus, me. If someone else volunteers - please let me know, I will add you to the committers list. WBR, Aleksey Bragin.

15 years, 5 months

3
3
0 0

You have been invited to join Rahul Nagpal

by rahulnagpal1989＠yahoo.com

null PS: If you don't want to join this site, use this link: http://rahulnagpal.webs.com/apps/auth/confirm?inviteID=46885840&hash=8670c0…

15 years, 5 months

2
1
0 0

Regression list

by Olaf Siejka

1. ReactOS fails to boot at first stage, on my real hardware since rev. 45320 with BugCheck 7B (7E recently).

15 years, 5 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 45565: [REACTOS] Add asm.h containing macros to make assembly code both GAS and ML compatible at the same time. [NTOS/HAL] Move trap entry points from C into a GAS/ML compatile assembly file (might need fine tuning for ML). The

by Gabriel ilardi

Hi Timo, This commit introduces a crash for me in vbox at the end of 1st stage: (base/setup/usetup/bootsup.c:2060) No or unknown boot loader found (ntoskrnl/io/iomgr/file.c:420) Using IopParseDevice() hack. Requested invalid attributes: 9 (ntoskrnl/io/iomgr/file.c:420) Using IopParseDevice() hack. Requested invalid attributes: 9 (ntoskrnl/io/iomgr/file.c:420) Using IopParseDevice() hack. Requested invalid attributes: 116 (ntoskrnl/ps/thread.c:119) PS: Unhandled Kernel Mode Exception Pointers = 0xFA264718 (ntoskrnl/ps/thread.c:126) Code c0000005 Addr 80107DBE Info0 00000000 Info1 00000020 Info2 00000000 Info3 00000020 *** Fatal System Error: 0x0000007e (0xC0000005,0x80107DBE,0xFA264BFC,0xFA26483C) [7hPuTTYEntered debugger on embedded INT3 at 0x0008:0x808dc124. kdb:> bt Eip: <ntoskrnl.exe:dc125 (lib/rtl/i386/debug_asm.S:42 (RtlpBreakWithStatusInstruction))> Frames: <ntoskrnl.exe:a3a7 (ntoskrnl/ke/bug.c:1110 (KeBugCheckWithTf@24))> <ntoskrnl.exe:a4e2 (ntoskrnl/ke/bug.c:1448 (KeBugCheckEx@20))> <ntoskrnl.exe:cbccb (ntoskrnl/ps/thread.c:159 (_SEHExcept.33686))> <ntoskrnl.exe:cbcdc (ntoskrnl/ps/thread.c:159 (_SEHExcept.33686))> <ntoskrnl.exe:d984b (lib/pseh/i386/framebased-gcchack.c:132 (_SEH2FrameHandler))> <ntoskrnl.exe:dbb98 (lib/rtl/i386/except_asm.s:188 (RtlpExecuteHandler2@20))> <ntoskrnl.exe:dbb6c (lib/rtl/i386/except_asm.s:153 (RtlpExecuteHandler@20))> <ntoskrnl.exe:325a (ntoskrnl/ke/i386/exp.c:938 (KiDispatchException@20))> <ntoskrnl.exe:36e3 (ntoskrnl/ke/i386/exp.c:1144 (KiDispatchExceptionFromTrapFrame@28))> <ntoskrnl.exe:67e0 (ntoskrnl/ke/i386/traphdlr.c:1181 (@KiTrap0EHandler@4))> <00000000> kdb:> Gabriel. > Date: Wed, 10 Feb 2010 23:24:59 +0000 > To: ros-diffs(a)reactos.org > From: tkreuzer(a)svn.reactos.org > Subject: [ros-diffs] [tkreuzer] 45565: [REACTOS] Add asm.h containing macros to make assembly code both GAS and ML compatible at the same time. [NTOS/HAL] Move trap entry points from C into a GAS/ML compatile assembly file (might need fine tuning for ML). The entries are generated by a shared assembly macro TRAP_ENTRY. Removed KiTrapStub, KiIsV8086TrapSafe, KiIsUserTrapSafe, KiSetSaneSegments, removed segment handling from KiEnter*Trap. [NTOS] Make KiFastCallEntryHandler and KiSystemServiceHandler FASTCALL and pass the systemcall number in TrapFrame->Eax [HAL] Use _setjmp/longjmp instead of saving a trapframe in HalpBiosCall > > Author: tkreuzer > Date: Thu Feb 11 00:24:59 2010 > New Revision: 45565 > > URL: http://svn.reactos.org/svn/reactos?rev=45565&view=rev > Log: > [REACTOS] Add asm.h containing macros to make assembly code both GAS and ML compatible at the same time. > [NTOS/HAL] Move trap entry points from C into a GAS/ML compatile assembly file (might need fine tuning for ML). The entries are generated by a shared assembly macro TRAP_ENTRY. Removed KiTrapStub, KiIsV8086TrapSafe, KiIsUserTrapSafe, KiSetSaneSegments, removed segment handling from KiEnter*Trap. > [NTOS] Make KiFastCallEntryHandler and KiSystemServiceHandler FASTCALL and pass the systemcall number in TrapFrame->Eax > [HAL] Use _setjmp/longjmp instead of saving a trapframe in HalpBiosCall > > Added: > trunk/reactos/hal/halx86/generic/trap.S (with props) > trunk/reactos/include/reactos/asm.h (with props) > Modified: > trunk/reactos/hal/halx86/generic/bios.c > trunk/reactos/hal/halx86/generic/pic.c > trunk/reactos/hal/halx86/generic/systimer.S > trunk/reactos/hal/halx86/generic/timer.c > trunk/reactos/hal/halx86/hal.rbuild > trunk/reactos/hal/halx86/hal_generic.rbuild > trunk/reactos/hal/halx86/halmps.rbuild > trunk/reactos/hal/halx86/halxbox.rbuild > trunk/reactos/hal/halx86/mp/apic.c > trunk/reactos/include/ndk/i386/asm.h > trunk/reactos/ntoskrnl/ex/i386/fastinterlck_asm.S > trunk/reactos/ntoskrnl/ex/i386/interlck_asm.S > trunk/reactos/ntoskrnl/include/internal/i386/asmmacro.S > trunk/reactos/ntoskrnl/include/internal/trap_x.h > trunk/reactos/ntoskrnl/ke/i386/irqobj.c > trunk/reactos/ntoskrnl/ke/i386/trap.s > trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > trunk/reactos/ntoskrnl/ke/i386/usercall_asm.S > > Modified: trunk/reactos/hal/halx86/generic/bios.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/bios.c?… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/bios.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/bios.c [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -12,6 +12,9 @@ > #include <hal.h> > #define NDEBUG > #include <debug.h> > +#include <setjmp.h> > + > +void HalpTrap0D(); > > /* GLOBALS ********************************************************************/ > > @@ -46,6 +49,9 @@ > > /* Where the real mode code ends */ > extern PVOID HalpRealModeEnd; > + > +/* Context saved for return from v86 mode */ > +jmp_buf HalpSavedContext; > > /* REAL MODE CODE AND STACK START HERE ****************************************/ > > @@ -230,60 +236,44 @@ > while (TRUE); > } > > -KiTrap(HalpTrap0D, 0); > - > VOID > DECLSPEC_NORETURN > -HalpTrap06(VOID) > -{ > - PKTRAP_FRAME TrapFrame; > - > +HalpTrap06() > +{ > /* Restore ES/DS to known good values first */ > Ke386SetEs(KGDT_R3_DATA | RPL_MASK); > Ke386SetDs(KGDT_R3_DATA | RPL_MASK); > - > - /* Read trap frame address */ > - TrapFrame = (PKTRAP_FRAME)HalpSavedEsp; > - > - /* Restore segments from the trap frame */ > - Ke386SetGs(TrapFrame->SegGs); > - Ke386SetFs(TrapFrame->SegFs); > - Ke386SetEs(TrapFrame->SegEs); > - Ke386SetDs(TrapFrame->SegDs); > - > - /* Restore EFlags */ > - __writeeflags(TrapFrame->EFlags); > - > - /* Exit the V86 mode trap frame */ > - KiCallReturn(TrapFrame); > + > + /* Restore the stack */ > + KeGetPcr()->TSS->Esp0 = HalpSavedEsp0; > + > + /* Return back to where we left */ > + longjmp(HalpSavedContext, 1); > + UNREACHABLE; > } > > /* V8086 ENTER ****************************************************************/ > > VOID > -FASTCALL > -DECLSPEC_NORETURN > -HalpBiosCallHandler(IN PKTRAP_FRAME TrapFrame) > +NTAPI > +HalpBiosCall() > { > /* Must be volatile so it doesn't get optimized away! */ > volatile KTRAP_FRAME V86TrapFrame; > ULONG_PTR StackOffset, CodeOffset; > > - /* Fill out the quick-n-dirty trap frame */ > - TrapFrame->EFlags = __readeflags(); > - TrapFrame->SegGs = Ke386GetGs(); > - TrapFrame->SegFs = Ke386GetFs(); > - TrapFrame->SegEs = Ke386GetEs(); > - TrapFrame->SegDs = Ke386GetDs(); > - > - /* Our stack (the frame) */ > - HalpSavedEsp = (ULONG_PTR)TrapFrame; > + /* Save the context, check for return */ > + if (_setjmp(HalpSavedContext)) > + { > + /* Returned from v86 */ > + return; > + } > > /* Kill alignment faults */ > __writecr0(__readcr0() & ~CR0_AM); > > /* Set new stack address */ > - KeGetPcr()->TSS->Esp0 = HalpSavedEsp - sizeof(FX_SAVE_AREA); > + KeGetPcr()->TSS->Esp0 = (ULONG)&V86TrapFrame - 0x20 - sizeof(FX_SAVE_AREA); > > /* Compute segmented IP and SP offsets */ > StackOffset = (ULONG_PTR)&HalpRealModeEnd - 4 - (ULONG_PTR)HalpRealModeStart; > @@ -304,8 +294,6 @@ > KiDirectTrapReturn((PKTRAP_FRAME)&V86TrapFrame); > } > > -KiTrampoline(HalpBiosCall, KI_PUSH_FAKE_ERROR_CODE | KI_NONVOLATILES_ONLY); > - > /* FUNCTIONS ******************************************************************/ > > VOID > > Modified: trunk/reactos/hal/halx86/generic/pic.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/pic.c?r… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/pic.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/pic.c [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -1335,4 +1335,3 @@ > } > } > > -KiTrap(HalpApcInterrupt, KI_SOFTWARE_TRAP); > > Modified: trunk/reactos/hal/halx86/generic/systimer.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/systime… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/systimer.S [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/systimer.S [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -8,7 +8,6 @@ > /* INCLUDES ******************************************************************/ > > #include <asm.h> > -#include <internal/i386/asmmacro.S> > .intel_syntax noprefix > > /* GLOBALS *******************************************************************/ > > Modified: trunk/reactos/hal/halx86/generic/timer.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/timer.c… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/timer.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/timer.c [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -161,8 +161,6 @@ > KiEoiHelper(TrapFrame); > } > > -KiTrap(HalpClockInterrupt, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(HalpProfileInterrupt, KI_PUSH_FAKE_ERROR_CODE); > > /* PUBLIC FUNCTIONS ***********************************************************/ > > > Added: trunk/reactos/hal/halx86/generic/trap.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/trap.S?… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/trap.S (added) > +++ trunk/reactos/hal/halx86/generic/trap.S [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -1,0 +1,23 @@ > +/* > + * FILE: ntoskrnl/ke/i386/trap.S > + * COPYRIGHT: See COPYING in the top level directory > + * PURPOSE: System Traps, Entrypoints and Exitpoints > + * PROGRAMMER: Timo Kreuzer (timo.kreuzer(a)reactos.org) > + * NOTE: See asmmacro.S for the shared entry/exit code. > + */ > + > +/* INCLUDES ******************************************************************/ > + > +#include <reactos/asm.h> > +#include <ndk/i386/asm.h> > +#include <internal/i386/asmmacro.S> > + > +.code32 > +.text > + > +TRAP_ENTRY HalpTrap0D, 0 > +TRAP_ENTRY HalpApcInterrupt, KI_SOFTWARE_TRAP > +TRAP_ENTRY HalpClockInterrupt, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY HalpProfileInterrupt, KI_PUSH_FAKE_ERROR_CODE > + > + > > Propchange: trunk/reactos/hal/halx86/generic/trap.S > ------------------------------------------------------------------------------ > svn:eol-style = native > > Modified: trunk/reactos/hal/halx86/hal.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/hal.rbuild?rev=… > ============================================================================== > --- trunk/reactos/hal/halx86/hal.rbuild [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/hal.rbuild [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -10,6 +10,7 @@ > <library>hal_generic</library> > <library>hal_generic_up</library> > <library>ntoskrnl</library> > + <library>libcntpr</library> > <directory name="up"> > <file>halinit_up.c</file> > <file>halup.rc</file> > > Modified: trunk/reactos/hal/halx86/hal_generic.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/hal_generic.rbu… > ============================================================================== > --- trunk/reactos/hal/halx86/hal_generic.rbuild [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/hal_generic.rbuild [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -28,6 +28,7 @@ > <file>sysinfo.c</file> > <file>systimer.S</file> > <file>timer.c</file> > + <file>trap.S</file> > <file>usage.c</file> > </directory> > <directory name="include"> > > Modified: trunk/reactos/hal/halx86/halmps.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/halmps.rbuild?r… > ============================================================================== > --- trunk/reactos/hal/halx86/halmps.rbuild [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/halmps.rbuild [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -11,6 +11,7 @@ > <library>hal_generic</library> > <library>hal_generic_mp</library> > <library>ntoskrnl</library> > + <library>libcntpr</library> > <directory name="mp"> > <file>mps.S</file> > <file>mpsboot.asm</file> > > Modified: trunk/reactos/hal/halx86/halxbox.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/halxbox.rbuild?… > ============================================================================== > --- trunk/reactos/hal/halx86/halxbox.rbuild [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/halxbox.rbuild [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -10,6 +10,7 @@ > <library>hal_generic</library> > <library>hal_generic_up</library> > <library>ntoskrnl</library> > + <library>libcntpr</library> > <directory name="xbox"> > <file>halinit_xbox.c</file> > <file>part_xbox.c</file> > > Modified: trunk/reactos/hal/halx86/mp/apic.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/mp/apic.c?rev=4… > ============================================================================== > --- trunk/reactos/hal/halx86/mp/apic.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/mp/apic.c [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -1110,4 +1110,25 @@ > > #endif > > +VOID > +FASTCALL > +DECLSPEC_NORETURN > +HalpApcInterruptHandler(IN PKTRAP_FRAME TrapFrame) > +{ > + /* Set up a fake INT Stack */ > + TrapFrame->EFlags = __readeflags(); > + TrapFrame->SegCs = KGDT_R0_CODE; > + TrapFrame->Eip = TrapFrame->Eax; > + > + /* Build the trap frame */ > + KiEnterInterruptTrap(TrapFrame); > + > + /* unimplemented */ > + UNIMPLEMENTED; > + > + /* Exit the interrupt */ > + KiEoiHelper(TrapFrame); > + > +} > + > /* EOF */ > > Modified: trunk/reactos/include/ndk/i386/asm.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ndk/i386/asm.h?rev… > ============================================================================== > --- trunk/reactos/include/ndk/i386/asm.h [iso-8859-1] (original) > +++ trunk/reactos/include/ndk/i386/asm.h [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -248,10 +248,12 @@ > #define KINTERRUPT_SERVICE_CONTEXT 0x10 > #define KINTERRUPT_TICK_COUNT 0x18 > #define KINTERRUPT_ACTUAL_LOCK 0x1C > +#define KINTERRUPT_DISPATCH_ADDRESS 0x20 > #define KINTERRUPT_VECTOR 0x24 > #define KINTERRUPT_IRQL 0x28 > #define KINTERRUPT_SYNCHRONIZE_IRQL 0x29 > #define KINTERRUPT_DISPATCH_COUNT 0x38 > +#define KINTERRUPT_DISPATCH_CODE 0x3C > > // > // KGDTENTRY Offsets > > Added: trunk/reactos/include/reactos/asm.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/reactos/asm.h?rev=… > ============================================================================== > --- trunk/reactos/include/reactos/asm.h (added) > +++ trunk/reactos/include/reactos/asm.h [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -1,0 +1,190 @@ > +/* > + * COPYRIGHT: See COPYING in the top level directory > + * PROJECT: ReactOS Kernel > + * FILE: ntoskrnl/include/amd64/asmmacro.S > + * PURPOSE: ASM macros for for GAS and MASM/ML64 > + * PROGRAMMERS: Timo Kreuzer (timo.kreuzer(a)reactos.org) > + */ > + > +#ifdef _MSC_VER > + > +/* Allow ".name" identifiers */ > +OPTION DOTNAME > + > +.586 > +.MODEL FLAT > + > +/* Hex numbers need to be in 01ABh format */ > +#define HEX(x) 0##x##h > + > +/* Macro values need to be marked */ > +#define VAL(x) x > + > +/* MASM/ML doesn't want explicit [rip] addressing */ > +rip = 0 > + > +/* Due to MASM's reverse syntax, we are forced to use a precompiler macro */ > +#define MACRO(name, ...) name MACRO __VA_ARGS__ > + > +/* To avoid reverse syntax we provide a new macro .PROC, replacing PROC... */ > +.PROC MACRO name > + name PROC FRAME > + _name: > +ENDM > + > +/* ... and .ENDP, replacing ENDP */ > +.ENDP MACRO name > + name ENDP > +ENDM > + > +/* MASM doesn't have an ASCII macro */ > +.ASCII MACRO text > + DB text > +ENDM > + > +/* MASM doesn't have an ASCIZ macro */ > +.ASCIZ MACRO text > + DB text, 0 > +ENDM > + > +.text MACRO > +ENDM > + > +.code64 MACRO > + .code > +ENDM > + > +.code32 MACRO > + .code > +ENDM > + > +UNIMPLEMENTED MACRO name > +ENDM > + > +/* We need this to distinguish repeat from macros */ > +#define ENDR ENDM > + > +#else /***********************************************************************/ > + > +/* Force intel syntax */ > +.intel_syntax noprefix > +.code64 > + > +.altmacro > + > +/* Hex numbers need to be in 0x1AB format */ > +#define HEX(x) 0x##x > + > +/* Macro values need to be marked */ > +#define VAL(x) \x > + > +/* Due to MASM's reverse syntax, we are forced to use a precompiler macro */ > +#define MACRO(...) .macro __VA_ARGS__ > +#define ENDM .endm > + > +/* To avoid reverse syntax we provide a new macro .PROC, replacing PROC... */ > +.macro .PROC name > + .func \name > + \name: > + .cfi_startproc > + .equ cfa_current_offset, -8 > +.endm > + > +/* ... and .ENDP, replacing ENDP */ > +.macro .ENDP name > + .cfi_endproc > + .endfunc > +.endm > + > +/* MASM compatible PUBLIC */ > +.macro PUBLIC symbol > + .global \symbol > +.endm > + > +/* MASM compatible ALIGN */ > +#define ALIGN .align > + > +/* MASM compatible REPEAT, additional ENDR */ > +#define REPEAT .rept > +#define ENDR .endr > + > +/* MASM compatible EXTERN */ > +.macro EXTERN name > +.endm > + > +/* MASM needs an END tag */ > +#define END > + > +.macro .MODEL model > +.endm > + > +.macro .code > + .text > +.endm > + > +/* Macros for x64 stack unwind OPs */ > + > +.macro .allocstack size > + .cfi_adjust_cfa_offset \size > + .set cfa_current_offset, cfa_current_offset - \size > +.endm > + > +code = 1 > +.macro .pushframe param=0 > + .if (\param) > + .cfi_adjust_cfa_offset 0x30 > + .set cfa_current_offset, cfa_current_offset - 0x30 > + .else > + .cfi_adjust_cfa_offset 0x28 > + .set cfa_current_offset, cfa_current_offset - 0x28 > + .endif > +.endm > + > +.macro .pushreg reg > + .cfi_adjust_cfa_offset 8 > + .equ cfa_current_offset, cfa_current_offset - 8 > + .cfi_offset \reg, cfa_current_offset > +.endm > + > +.macro .savereg reg, offset > + // checkme!!! > + .cfi_offset \reg, \offset > +.endm > + > +.macro .savexmm128 reg, offset > + // checkme!!! > + .cfi_offset \reg, \offset > +.endm > + > +.macro .setframe reg, offset > + .cfi_def_cfa reg, \offset > + .equ cfa_current_offset, \offset > +.endm > + > +.macro .endprolog > +.endm > + > +.macro UNIMPLEMENTED2 file, line, func > + > + jmp 3f > +1: .asciz "\func" > +2: .asciz \file > +3: > + sub rsp, 0x20 > + lea rcx, MsgUnimplemented[rip] > + lea rdx, 1b[rip] > + lea r8, 2b[rip] > + mov r9, \line > + call DbgPrint > + add rsp, 0x20 > +.endm > +#define UNIMPLEMENTED UNIMPLEMENTED2 __FILE__, __LINE__, > + > +/* MASM/ML uses ".if" for runtime conditionals, and "if" for compile time > + conditionals. We therefore use "if", too. .if shouldn't be used at all */ > +#define if .if > +#define endif .endif > +#define else .else > +#define elseif .elseif > + > +#endif > > Propchange: trunk/reactos/include/reactos/asm.h > ------------------------------------------------------------------------------ > svn:eol-style = native > > Modified: trunk/reactos/ntoskrnl/ex/i386/fastinterlck_asm.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/i386/fastinter… > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/i386/fastinterlck_asm.S [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/i386/fastinterlck_asm.S [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -7,11 +7,15 @@ > */ > > /* INCLUDES ******************************************************************/ > + > +#include <reactos/asm.h> > #include <ndk/asm.h> > #include <internal/i386/asmmacro.S> > -.intel_syntax noprefix > > /* FUNCTIONS ****************************************************************/ > + > +.code32 > +.text > > /* > * NOTE: These functions must obey the following rules: > > Modified: trunk/reactos/ntoskrnl/ex/i386/interlck_asm.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/i386/interlck_… > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/i386/interlck_asm.S [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/i386/interlck_asm.S [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -7,11 +7,15 @@ > */ > > /* INCLUDES ******************************************************************/ > + > +#include <reactos/asm.h> > #include <ndk/asm.h> > #include <internal/i386/asmmacro.S> > -.intel_syntax noprefix > > /* FUNCTIONS ****************************************************************/ > + > +.code32 > +.text > > /* > * NOTE: These functions must obey the following rules: > > Modified: trunk/reactos/ntoskrnl/include/internal/i386/asmmacro.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/i386/asmmacro.S [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/i386/asmmacro.S [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -4,17 +4,12 @@ > * FILE: ntoskrnl/include/i386/asmmacro.S > * PURPOSE: Assembly Macros for Spinlocks and common Trap Code > * PROGRAMMERS: Alex Ionescu (alex(a)relsoft.net) > + * Timo Kreuzer (timo.kreuzer(a)reactos.org) > */ > > -/* INCLUDES ******************************************************************/ > - > -#include <ndk/asm.h> > - > // Arguments for idt > -#define INT_32_DPL0 0x8E00 > -#define INT_32_DPL3 0xEE00 > - > -.intel_syntax noprefix > +#define INT_32_DPL0 HEX(08E00) > +#define INT_32_DPL3 HEX(0EE00) > > // > // These macros are inlined equivalents of KiAcquire/ReleaseSpinlock, that is, > @@ -30,7 +25,7 @@ > // #IFDEF CONFIG_SMP > // .spin > // <any necessary steps to be able to jump back safely> > -/ SPIN_ON_LOCK(reg, .BeginYourFunction) > +// SPIN_ON_LOCK(reg, .BeginYourFunction) > // #ENDIF > // > #ifdef CONFIG_SMP > @@ -64,74 +59,139 @@ > // > // @remark None. > // > -.macro idt Handler, Bits > +MACRO(idt, Handler, Bits) > .long \Handler > .short \Bits > .short KGDT_R0_CODE > -.endm > +ENDM > > -// > -// @name GENERATE_IDT_STUB > -// > -// This macro creates an IDT entry for an unexpected interrupt handler. > -// > -// @param None. > -// > -// @remark None. > -// > -.macro GENERATE_IDT_STUB Number > -idt _KiUnexpectedInterrupt&Number, INT_32_DPL0 > -.endm > > -// > -// @name GENERATE_IDT_STUBS > -// > -// This macro creates unexpected interrupt IDT entries. > -// > -// @param None. > -// > -// @remark None. > -// > -.altmacro > -.macro GENERATE_IDT_STUBS > -.set i, 0 > -.rept 208 > - GENERATE_IDT_STUB %i > - .set i, i + 1 > -.endr > -.endm > +KI_PUSH_FAKE_ERROR_CODE = HEX(0001) > +KI_UNUSED = HEX(0002) > +KI_NONVOLATILES_ONLY = HEX(0004) > +KI_FAST_SYSTEM_CALL = HEX(0008) > +KI_SOFTWARE_TRAP = HEX(0010) > +KI_HARDWARE_INT = HEX(0020) > +KI_DONT_SAVE_SEGS = HEX(0100) > > -// > -// @name GENERATE_INT_HANDLER > -// > -// This macro creates an unexpected interrupt handler. > -// > -// @param None. > -// > -// @remark None. > -// > -.macro GENERATE_INT_HANDLER Number > -.func KiUnexpectedInterrupt&Number > -_KiUnexpectedInterrupt&Number: > - mov eax, PRIMARY_VECTOR_BASE + Number > - jmp _KiEndUnexpectedRange@0 > -.endfunc > -.endm > +MACRO(KiEnterTrap, Flags) > + LOCAL kernel_trap > + LOCAL not_v86_trap > + LOCAL set_sane_segs > > -// > -// @name GENERATE_INT_HANDLERS > -// > -// This macro creates the unexpected interrupt handlers. > -// > -// @param None. > -// > -// @remark None. > -// > -.altmacro > -.macro GENERATE_INT_HANDLERS > -.set i, 0 > -.rept 208 > - GENERATE_INT_HANDLER %i > - .set i, i + 1 > -.endr > -.endm > + /* Check what kind of trap frame this trap requires */ > + if (Flags AND KI_FAST_SYSTEM_CALL) > + > + /* SYSENTER requires us to build a complete ring transition trap frame */ > + FrameSize = KTRAP_FRAME_V86_ES > + > + /* Fixup fs. cx is free to clobber */ > + mov cx, KGDT_R0_PCR > + mov fs, cx > + > + /* Get pointer to the TSS */ > + mov ecx, fs:[KPCR_TSS] > + > + /* Get a stack pointer */ > + mov esp, [ecx + KTSS_ESP0] > + > + elseif (Flags AND KI_SOFTWARE_TRAP) > + > + /* Software traps need a complete non-ring transition trap frame */ > + FrameSize = KTRAP_FRAME_ESP > + > + /* Software traps need to get their EIP from the caller's frame */ > + pop eax > + > + elseif (Flags AND KI_PUSH_FAKE_ERROR_CODE) > + > + /* If the trap doesn't have an error code, we'll make space for it */ > + FrameSize = KTRAP_FRAME_EIP > + > + else > + > + /* The trap already has an error code, so just make space for the rest */ > + FrameSize = KTRAP_FRAME_ERROR_CODE > + > + endif > + > + /* Save nonvolatile registers */ > + mov [esp - FrameSize + KTRAP_FRAME_EBP], ebp > + mov [esp - FrameSize + KTRAP_FRAME_EBX], ebx > + mov [esp - FrameSize + KTRAP_FRAME_ESI], esi > + mov [esp - FrameSize + KTRAP_FRAME_EDI], edi > + > + /* Save eax for system calls, for use by the C handler */ > + mov [esp - FrameSize + KTRAP_FRAME_EAX], eax > + > + /* Does the caller want nonvolatiles only? */ > + if ((Flags AND KI_NONVOLATILES_ONLY) == 0) > + /* Otherwise, save the volatiles as well */ > + mov [esp - FrameSize + KTRAP_FRAME_ECX], ecx > + mov [esp - FrameSize + KTRAP_FRAME_EDX], edx > + endif > + > + /* Save segment registers? */ > + if ((Flags AND KI_DONT_SAVE_SEGS) == 0) > + > + /* Check for V86 mode */ > + test byte ptr [esp - FrameSize + KTRAP_FRAME_EFLAGS + 2], (EFLAGS_V86_MASK >> 16) > + jz not_v86_trap > + > + /* Restore V8086 segments into Protected Mode segments */ > + mov eax, [esp - FrameSize + KTRAP_FRAME_V86_DS] > + mov ecx, [esp - FrameSize + KTRAP_FRAME_V86_ES] > + mov [esp - FrameSize + KTRAP_FRAME_DS], eax > + mov [esp - FrameSize + KTRAP_FRAME_ES], ecx > + mov eax, [esp - FrameSize + KTRAP_FRAME_V86_FS] > + mov ecx, [esp - FrameSize + KTRAP_FRAME_V86_GS] > + mov [esp - FrameSize + KTRAP_FRAME_FS], eax > + mov [esp - FrameSize + KTRAP_FRAME_GS], ecx > + jmp set_sane_segs > + > + not_v86_trap: > + > + /* Save segment selectors */ > + mov eax, ds > + mov ecx, es > + mov [esp - FrameSize + KTRAP_FRAME_DS], eax > + mov [esp - FrameSize + KTRAP_FRAME_ES], ecx > + mov eax, fs > + mov ecx, gs > + mov [esp - FrameSize + KTRAP_FRAME_FS], eax > + mov [esp - FrameSize + KTRAP_FRAME_GS], ecx > + > + endif > + > +set_sane_segs: > + /* Load correct data segments */ > + mov ax, KGDT_R3_DATA OR RPL_MASK > + mov ds, ax > + mov es, ax > + > + /* Fast system calls have fs already fixed */ > + if ((Flags AND KI_FAST_SYSTEM_CALL) == 0) > + /* Otherwise fix fs now */ > + mov ax, KGDT_R0_PCR > + mov fs, ax > + endif > + > + /* Make space for this frame */ > + sub esp, FrameSize > + > + /* Clear direction flag */ > + cld > + > + /* Set parameter 1 (ECX) to point to the frame */ > + mov ecx, esp > + > +ENDM > + > +MACRO(TRAP_ENTRY, Trap, Flags) > +EXTERN @&Trap&Handler@4 :PROC > + PUBLIC _&Trap > + _&Trap: > + KiEnterTrap Flags > + jmp @&Trap&Handler@4 > +ENDM > + > > Modified: trunk/reactos/ntoskrnl/include/internal/trap_x.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/trap_x.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/trap_x.h [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -196,68 +196,6 @@ > asm volatile(".byte 0xC4\n.byte 0xC4\n"); > } > > -// > -// Returns whether or not this is a V86 trap by checking the EFLAGS field. > -// > -// FIXME: GCC 4.5 Can Improve this with "goto labels" > -// > -BOOLEAN > -FORCEINLINE > -KiIsV8086TrapSafe(IN PKTRAP_FRAME TrapFrame) > -{ > - BOOLEAN Result; > - > - /* > - * The check MUST be done this way, as we guarantee that no DS/ES/FS segment > - * is used (since it might be garbage). > - * > - * Instead, we use the SS segment which is guaranteed to be correct. Because > - * operate in 32-bit flat mode, this works just fine. > - */ > - asm volatile > - ( > - "testl $%c[f], %%ss:%1\n" > - "setnz %0\n" > - : "=a"(Result) > - : "m"(TrapFrame->EFlags), > - [f] "i"(EFLAGS_V86_MASK) > - ); > - > - /* If V86 flag was set */ > - return Result; > -} > - > -// > -// Returns whether or not this is a user-mode trap by checking the SegCs field. > -// > -// FIXME: GCC 4.5 Can Improve this with "goto labels" > -// > -BOOLEAN > -FORCEINLINE > -KiIsUserTrapSafe(IN PKTRAP_FRAME TrapFrame) > -{ > - BOOLEAN Result; > - > - /* > - * The check MUST be done this way, as we guarantee that no DS/ES/FS segment > - * is used (since it might be garbage). > - * > - * Instead, we use the SS segment which is guaranteed to be correct. Because > - * operate in 32-bit flat mode, this works just fine. > - */ > - asm volatile > - ( > - "cmp $%c[f], %%ss:%1\n" > - "setnz %0\n" > - : "=a"(Result) > - : "m"(TrapFrame->SegCs), > - [f] "i"(KGDT_R0_CODE) > - ); > - > - /* If V86 flag was set */ > - return Result; > -} > - > VOID > FORCEINLINE > KiUserSystemCall(IN PKTRAP_FRAME TrapFrame) > @@ -279,30 +217,6 @@ > : > : "r"(TrapFrame->SegCs) > ); > -} > - > -VOID > -FORCEINLINE > -KiSetSaneSegments(IN PKTRAP_FRAME TrapFrame) > -{ > - ULONG Ds, Es; > - > - /* > - * We really have to get a good DS/ES first before touching any data. > - * > - * These two reads will either go in a register (with optimizations ON) or > - * a stack variable (which is on SS:ESP, guaranteed to be good/valid). > - * > - * Because the assembly is marked volatile, the order of instructions is > - * as-is, otherwise the optimizer could simply get rid of our DS/ES. > - * > - */ > - Ds = Ke386GetDs(); > - Es = Ke386GetEs(); > - Ke386SetDs(KGDT_R3_DATA | RPL_MASK); > - Ke386SetEs(KGDT_R3_DATA | RPL_MASK); > - TrapFrame->SegDs = Ds; > - TrapFrame->SegEs = Es; > } > > // > @@ -643,17 +557,9 @@ > FORCEINLINE > KiEnterV86Trap(IN PKTRAP_FRAME TrapFrame) > { > - /* Load correct registers */ > - Ke386SetFs(KGDT_R0_PCR); > - Ke386SetDs(KGDT_R3_DATA | RPL_MASK); > - Ke386SetEs(KGDT_R3_DATA | RPL_MASK); > - > /* Save exception list */ > TrapFrame->ExceptionList = KeGetPcr()->Tib.ExceptionList; > > - /* Clear direction flag */ > - Ke386ClearDirectionFlag(); > - > /* Save DR7 and check for debugging */ > TrapFrame->Dr7 = __readdr(7); > if (__builtin_expect(TrapFrame->Dr7 & ~DR7_RESERVED_MASK, 0)) > @@ -670,40 +576,10 @@ > FORCEINLINE > KiEnterInterruptTrap(IN PKTRAP_FRAME TrapFrame) > { > - /* Check for V86 mode, otherwise check for ring 3 code */ > - if (__builtin_expect(KiIsV8086TrapSafe(TrapFrame), 0)) > - { > - /* Set correct segments */ > - Ke386SetDs(KGDT_R3_DATA | RPL_MASK); > - Ke386SetEs(KGDT_R3_DATA | RPL_MASK); > - Ke386SetFs(KGDT_R0_PCR); > - > - /* Restore V8086 segments into Protected Mode segments */ > - TrapFrame->SegFs = TrapFrame->V86Fs; > - TrapFrame->SegGs = TrapFrame->V86Gs; > - TrapFrame->SegDs = TrapFrame->V86Ds; > - TrapFrame->SegEs = TrapFrame->V86Es; > - } > - else if (__builtin_expect(KiIsUserTrapSafe(TrapFrame), 1)) /* Ring 3 is more common */ > - { > - /* Switch to sane segments */ > - KiSetSaneSegments(TrapFrame); > - > - /* Save FS/GS */ > - TrapFrame->SegFs = Ke386GetFs(); > - TrapFrame->SegGs = Ke386GetGs(); > - > - /* Set correct FS */ > - Ke386SetFs(KGDT_R0_PCR); > - } > - > /* Save exception list and terminate it */ > TrapFrame->ExceptionList = KeGetPcr()->Tib.ExceptionList; > KeGetPcr()->Tib.ExceptionList = EXCEPTION_CHAIN_END; > > - /* Clear direction flag */ > - Ke386ClearDirectionFlag(); > - > /* Flush DR7 and check for debugging */ > TrapFrame->Dr7 = 0; > if (__builtin_expect(KeGetCurrentThread()->DispatcherHeader.DebugActive & 0xFF, 0)) > @@ -723,29 +599,8 @@ > FORCEINLINE > KiEnterTrap(IN PKTRAP_FRAME TrapFrame) > { > - /* Switch to sane segments */ > - KiSetSaneSegments(TrapFrame); > - > - /* Now we can save the other segments and then switch to the correct FS */ > - TrapFrame->SegFs = Ke386GetFs(); > - TrapFrame->SegGs = Ke386GetGs(); > - Ke386SetFs(KGDT_R0_PCR); > - > /* Save exception list */ > TrapFrame->ExceptionList = KeGetPcr()->Tib.ExceptionList; > - > - /* Check for V86 mode */ > - if (__builtin_expect(TrapFrame->EFlags & EFLAGS_V86_MASK, 0)) > - { > - /* Restore V8086 segments into Protected Mode segments */ > - TrapFrame->SegFs = TrapFrame->V86Fs; > - TrapFrame->SegGs = TrapFrame->V86Gs; > - TrapFrame->SegDs = TrapFrame->V86Ds; > - TrapFrame->SegEs = TrapFrame->V86Es; > - } > - > - /* Clear direction flag */ > - Ke386ClearDirectionFlag(); > > /* Flush DR7 and check for debugging */ > TrapFrame->Dr7 = 0; > @@ -759,130 +614,4 @@ > KiFillTrapFrameDebug(TrapFrame); > } > > -// > -// Generates a Trap Prolog Stub for the given name > -// > -#define KI_PUSH_FAKE_ERROR_CODE 0x1 > -#define KI_UNUSED 0x2 > -#define KI_NONVOLATILES_ONLY 0x4 > -#define KI_FAST_SYSTEM_CALL 0x8 > -#define KI_SOFTWARE_TRAP 0x10 > -#define KI_HARDWARE_INT 0x20 > -#define KiTrap(x, y) VOID DECLSPEC_NORETURN x(VOID) { KiTrapStub(y, x##Handler); UNREACHABLE; } > -#define KiTrampoline(x, y) VOID DECLSPEC_NOINLINE x(VOID) { KiTrapStub(y, x##Handler); } > - > -// > -// Trap Prolog Stub > -// > -VOID > -FORCEINLINE > -KiTrapStub(IN ULONG Flags, > - IN PVOID Handler) > -{ > - ULONG FrameSize; > - > - /* Is this a fast system call? They don't have a stack! */ > - if (Flags & KI_FAST_SYSTEM_CALL) __asm__ __volatile__ > - ( > - "movl %%ss:%c[t], %%esp\n" > - "movl %c[e](%%esp), %%esp\n" > - : > - : [e] "i"(FIELD_OFFSET(KTSS, Esp0)), > - [t] "i"(&PCR->TSS) > - : "%esp" > - ); > - > - /* Check what kind of trap frame this trap requires */ > - if (Flags & KI_SOFTWARE_TRAP) > - { > - /* Software traps need a complete non-ring transition trap frame */ > - FrameSize = FIELD_OFFSET(KTRAP_FRAME, HardwareEsp); > - } > - else if (Flags & KI_FAST_SYSTEM_CALL) > - { > - /* SYSENTER requires us to build a complete ring transition trap frame */ > - FrameSize = FIELD_OFFSET(KTRAP_FRAME, V86Es); > - > - /* And it only preserves nonvolatile registers */ > - Flags |= KI_NONVOLATILES_ONLY; > - } > - else if (Flags & KI_PUSH_FAKE_ERROR_CODE) > - { > - /* If the trap doesn't have an error code, we'll make space for it */ > - FrameSize = FIELD_OFFSET(KTRAP_FRAME, Eip); > - } > - else > - { > - /* The trap already has an error code, so just make space for the rest */ > - FrameSize = FIELD_OFFSET(KTRAP_FRAME, ErrCode); > - } > - > - /* Software traps need to get their EIP from the caller's frame */ > - if (Flags & KI_SOFTWARE_TRAP) __asm__ __volatile__ ("popl %%eax\n":::"%esp"); > - > - /* Save nonvolatile registers */ > - __asm__ __volatile__ > - ( > - /* EBX, ESI, EDI and EBP are saved */ > - "movl %%ebp, %c[p](%%esp)\n" > - "movl %%ebx, %c[b](%%esp)\n" > - "movl %%esi, %c[s](%%esp)\n" > - "movl %%edi, %c[i](%%esp)\n" > - : > - : [b] "i"(- FrameSize + FIELD_OFFSET(KTRAP_FRAME, Ebx)), > - [s] "i"(- FrameSize + FIELD_OFFSET(KTRAP_FRAME, Esi)), > - [i] "i"(- FrameSize + FIELD_OFFSET(KTRAP_FRAME, Edi)), > - [p] "i"(- FrameSize + FIELD_OFFSET(KTRAP_FRAME, Ebp)) > - : "%esp" > - ); > - > - /* Does the caller want nonvolatiles only? */ > - if (!(Flags & KI_NONVOLATILES_ONLY)) __asm__ __volatile__ > - ( > - /* Otherwise, save the volatiles as well */ > - "movl %%eax, %c[a](%%esp)\n" > - "movl %%ecx, %c[c](%%esp)\n" > - "movl %%edx, %c[d](%%esp)\n" > - : > - : [a] "i"(- FrameSize + FIELD_OFFSET(KTRAP_FRAME, Eax)), > - [c] "i"(- FrameSize + FIELD_OFFSET(KTRAP_FRAME, Ecx)), > - [d] "i"(- FrameSize + FIELD_OFFSET(KTRAP_FRAME, Edx)) > - : "%esp" > - ); > - > - /* Now set parameter 1 (ECX) to point to the frame */ > - __asm__ __volatile__ ("movl %%esp, %%ecx\n":::"%esp"); > - > - /* Now go ahead and make space for this frame */ > - __asm__ __volatile__ ("subl $%c[e],%%esp\n":: [e] "i"(FrameSize) : "%esp"); > - __asm__ __volatile__ ("subl $%c[e],%%ecx\n":: [e] "i"(FrameSize) : "%ecx"); > - > - /* > - * For hardware interrupts, set parameter 2 (EDX) to hold KINTERRUPT. > - * This code will be dynamically patched when an interrupt is registered! > - */ > - if (Flags & KI_HARDWARE_INT) __asm__ __volatile__ > - ( > - ".globl _KiInterruptTemplate2ndDispatch\n_KiInterruptTemplate2ndDispatch:\n" > - "movl $0, %%edx\n" > - ".globl _KiInterruptTemplateObject\n_KiInterruptTemplateObject:\n" > - ::: "%edx" > - ); > - > - /* Now jump to the C handler */ > - if (Flags & KI_HARDWARE_INT)__asm__ __volatile__ > - ( > - /* > - * For hardware interrupts, use an absolute JMP instead of a relative JMP > - * since the position of this code is arbitrary in memory, and therefore > - * the compiler-generated offset will not be correct. > - */ > - "jmp *%0\n" > - ".globl _KiInterruptTemplateDispatch\n_KiInterruptTemplateDispatch:\n" > - : > - : "a"(Handler) > - ); > - else __asm__ __volatile__ ("jmp %c[x]\n":: [x] "i"(Handler)); > -} > - > #endif > > Modified: trunk/reactos/ntoskrnl/ke/i386/irqobj.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/irqobj.c?… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/irqobj.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/irqobj.c [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -233,7 +233,7 @@ > KIRQL OldIrql; > BOOLEAN Handled; > PLIST_ENTRY NextEntry, ListHead; > - > + > /* Increase interrupt count */ > KeGetCurrentPrcb()->InterruptCount++; > > @@ -299,7 +299,7 @@ > /* Now call the epilogue code */ > KiExitInterrupt(TrapFrame, OldIrql, TRUE); > } > - } > +} > > VOID > FASTCALL > @@ -313,8 +313,6 @@ > ((PKI_INTERRUPT_DISPATCH*)Interrupt->DispatchAddress)(TrapFrame, Interrupt); > } > > -KiTrap(KiInterruptTemplate, KI_PUSH_FAKE_ERROR_CODE | KI_HARDWARE_INT); > -KiTrap(KiUnexpectedInterruptTail, KI_PUSH_FAKE_ERROR_CODE); > > /* PUBLIC FUNCTIONS **********************************************************/ > > > Modified: trunk/reactos/ntoskrnl/ke/i386/trap.s > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/trap.s?re… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/trap.s [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/trap.s [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -3,19 +3,33 @@ > * COPYRIGHT: See COPYING in the top level directory > * PURPOSE: System Traps, Entrypoints and Exitpoints > * PROGRAMMER: Alex Ionescu (alex(a)relsoft.net) > + * Timo Kreuzer (timo.kreuzer(a)reactos.org) > * NOTE: See asmmacro.S for the shared entry/exit code. > */ > > /* INCLUDES ******************************************************************/ > > -#include <asm.h> > +#include <reactos/asm.h> > +#include <ndk/i386/asm.h> > #include <internal/i386/asmmacro.S> > -.intel_syntax noprefix > + > +MACRO(GENERATE_IDT_STUB, Number) > +idt _KiUnexpectedInterrupt&Number, INT_32_DPL0 > +ENDM > + > +MACRO(GENERATE_INT_HANDLER, Number) > +.func KiUnexpectedInterrupt&Number > +_KiUnexpectedInterrupt&Number: > + mov eax, PRIMARY_VECTOR_BASE + Number > + jmp _KiEndUnexpectedRange@0 > +.endfunc > +ENDM > > /* GLOBALS *******************************************************************/ > > .data > -.globl _KiIdt > + > +PUBLIC _KiIdt > _KiIdt: > /* This is the Software Interrupt Table that we handle in this file: */ > idt _KiTrap00, INT_32_DPL0 /* INT 00: Divide Error (#DE) */ > @@ -47,26 +61,86 @@ > idt _KiDebugService, INT_32_DPL3 /* INT 2D: Debug Service Handler */ > idt _KiSystemService, INT_32_DPL3 /* INT 2E: System Call Service Handler */ > idt _KiTrap0F, INT_32_DPL0 /* INT 2F: RESERVED */ > -GENERATE_IDT_STUBS /* INT 30-FF: UNEXPECTED INTERRUPTS */ > +i = 0 > +.rept 208 > + GENERATE_IDT_STUB %i > + i = i + 1 > +.endr > > -.globl _KiIdtDescriptor > +PUBLIC _KiIdtDescriptor > _KiIdtDescriptor: > .short 0 > .short 0x7FF > .long _KiIdt > > -.globl _KiUnexpectedEntrySize > +PUBLIC _KiUnexpectedEntrySize > _KiUnexpectedEntrySize: > .long _KiUnexpectedInterrupt1 - _KiUnexpectedInterrupt0 > > +/******************************************************************************/ > +.code32 > .text > -/* HARDWARE INTERRUPT HANDLERS ************************************************/ > > -.globl _KiStartUnexpectedRange@0 > +TRAP_ENTRY KiTrap00, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiTrap01, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiTrap03, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiTrap04, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiTrap05, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiTrap06, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiTrap07, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiTrap08, 0 > +TRAP_ENTRY KiTrap09, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiTrap0A, 0 > +TRAP_ENTRY KiTrap0B, 0 > +TRAP_ENTRY KiTrap0C, 0 > +TRAP_ENTRY KiTrap0D, 0 > +TRAP_ENTRY KiTrap0E, 0 > +TRAP_ENTRY KiTrap0F, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiTrap10, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiTrap11, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiTrap13, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiGetTickCount, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiCallbackReturn, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiRaiseAssertion, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiDebugService, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiUnexpectedInterruptTail, KI_PUSH_FAKE_ERROR_CODE > + > +ALIGN 4 > +EXTERN @KiInterruptTemplateHandler@8 > +PUBLIC _KiInterruptTemplate > +_KiInterruptTemplate: > + KiEnterTrap KI_PUSH_FAKE_ERROR_CODE > +PUBLIC _KiInterruptTemplate2ndDispatch > +_KiInterruptTemplate2ndDispatch: > + mov edx, 0 > +PUBLIC _KiInterruptTemplateObject > +_KiInterruptTemplateObject: > + mov eax, offset @KiInterruptTemplateHandler@8 > + jmp eax > +PUBLIC _KiInterruptTemplateDispatch > +_KiInterruptTemplateDispatch: > + > +EXTERN @KiSystemServiceHandler@8:PROC > +PUBLIC _KiSystemService > +_KiSystemService: > + KiEnterTrap (KI_PUSH_FAKE_ERROR_CODE OR KI_NONVOLATILES_ONLY OR KI_DONT_SAVE_SEGS) > + jmp @KiSystemServiceHandler@8 > + > +EXTERN @KiFastCallEntryHandler@8:PROC > +PUBLIC _KiFastCallEntry > +_KiFastCallEntry: > + KiEnterTrap (KI_FAST_SYSTEM_CALL OR KI_NONVOLATILES_ONLY OR KI_DONT_SAVE_SEGS) > + jmp @KiFastCallEntryHandler@8 > + > +PUBLIC _KiStartUnexpectedRange@0 > _KiStartUnexpectedRange@0: > - > -GENERATE_INT_HANDLERS > - > -.globl _KiEndUnexpectedRange@0 > +i = 0 > +.rept 208 > + GENERATE_INT_HANDLER %i > + i = i + 1 > +.endr > +PUBLIC _KiEndUnexpectedRange@0 > _KiEndUnexpectedRange@0: > jmp _KiUnexpectedInterruptTail > + > +END > > Modified: trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/traphdlr.… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -53,7 +53,15 @@ > return ((TrapFrame->EFlags & EFLAGS_V86_MASK) || > ((KiUserTrap(TrapFrame)) && (PsGetCurrentProcess()->VdmObjects))); > } > - > + > +BOOLEAN > +FORCEINLINE > +KiV86Trap(IN PKTRAP_FRAME TrapFrame) > +{ > + /* Check if the V8086 flag is on */ > + return ((TrapFrame->EFlags & EFLAGS_V86_MASK) != 0); > +} > + > /* TRAP EXIT CODE *************************************************************/ > > VOID > @@ -223,7 +231,7 @@ > DataOffset, > TrapFrame); > } > - > + > /* Check for invalid operation */ > if (Error & FSW_INVALID_OPERATION) > { > @@ -540,7 +548,7 @@ > KIRQL OldIrql; > > /* Check for V86 GPF */ > - if (__builtin_expect(KiIsV8086TrapSafe(TrapFrame), 1)) > + if (__builtin_expect(KiV86Trap(TrapFrame), 1)) > { > /* Enter V86 trap */ > KiEnterV86Trap(TrapFrame); > @@ -800,7 +808,7 @@ > KIRQL OldIrql; > > /* Check for V86 GPF */ > - if (__builtin_expect(KiIsV8086TrapSafe(TrapFrame), 1)) > + if (__builtin_expect(KiV86Trap(TrapFrame), 1)) > { > /* Enter V86 trap */ > KiEnterV86Trap(TrapFrame); > @@ -845,7 +853,7 @@ > > /* Check for user-mode GPF */ > if (KiUserTrap(TrapFrame)) > - { > + { > /* Should not be VDM */ > ASSERT(KiVdmTrap(TrapFrame) == FALSE); > > @@ -1502,19 +1510,13 @@ > } > > VOID > -__attribute__((regparm(3))) > -DECLSPEC_NORETURN > -KiFastCallEntryHandler(IN ULONG ServiceNumber, > - IN PVOID Arguments, > - IN PKTRAP_FRAME TrapFrame) > +FASTCALL > +DECLSPEC_NORETURN > +KiFastCallEntryHandler(IN PKTRAP_FRAME TrapFrame, > + IN PVOID Arguments) > { > PKTHREAD Thread; > - > - /* Fixup segments */ > - Ke386SetFs(KGDT_R0_PCR); > - Ke386SetDs(KGDT_R3_DATA | RPL_MASK); > - Ke386SetEs(KGDT_R3_DATA | RPL_MASK); > - > + > /* Set up a fake INT Stack and enable interrupts */ > TrapFrame->HardwareSegSs = KGDT_R3_DATA | RPL_MASK; > TrapFrame->HardwareEsp = (ULONG_PTR)Arguments; > @@ -1531,7 +1533,7 @@ > > /* Call the shared handler (inline) */ > KiSystemCallHandler(TrapFrame, > - ServiceNumber, > + TrapFrame->Eax, > Arguments, > Thread, > UserMode, > @@ -1540,64 +1542,28 @@ > } > > VOID > -__attribute__((regparm(3))) > -DECLSPEC_NORETURN > -KiSystemServiceHandler(IN ULONG ServiceNumber, > - IN PVOID Arguments, > - IN PKTRAP_FRAME TrapFrame) > -{ > - USHORT SegFs; > +FASTCALL > +DECLSPEC_NORETURN > +KiSystemServiceHandler(IN PKTRAP_FRAME TrapFrame, > + IN PVOID Arguments) > +{ > PKTHREAD Thread; > > - /* Save and fixup FS */ > - SegFs = Ke386GetFs(); > - Ke386SetFs(KGDT_R0_PCR); > - > /* Get the current thread */ > Thread = KeGetCurrentThread(); > > /* Chain trap frames */ > TrapFrame->Edx = (ULONG_PTR)Thread->TrapFrame; > > - /* Clear direction flag */ > - Ke386ClearDirectionFlag(); > - > /* Call the shared handler (inline) */ > KiSystemCallHandler(TrapFrame, > - ServiceNumber, > + TrapFrame->Eax, > Arguments, > Thread, > KiUserTrap(TrapFrame), > Thread->PreviousMode, > - SegFs); > -} > - > -/* CPU AND SOFTWARE TRAPS *****************************************************/ > - > -KiTrap(KiTrap00, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiTrap01, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiTrap03, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiTrap04, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiTrap05, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiTrap06, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiTrap07, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiTrap08, 0); > -KiTrap(KiTrap09, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiTrap0A, 0); > -KiTrap(KiTrap0B, 0); > -KiTrap(KiTrap0C, 0); > -KiTrap(KiTrap0D, 0); > -KiTrap(KiTrap0E, 0); > -KiTrap(KiTrap0F, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiTrap10, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiTrap11, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiTrap13, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiGetTickCount, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiCallbackReturn, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiRaiseAssertion, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiDebugService, KI_PUSH_FAKE_ERROR_CODE); > -KiTrap(KiSystemService, KI_PUSH_FAKE_ERROR_CODE | KI_NONVOLATILES_ONLY); > -KiTrap(KiFastCallEntry, KI_FAST_SYSTEM_CALL); > + TrapFrame->SegFs); > +} > > /* > * @implemented > > Modified: trunk/reactos/ntoskrnl/ke/i386/usercall_asm.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/usercall_… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/usercall_asm.S [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/usercall_asm.S [iso-8859-1] Thu Feb 11 00:24:59 2010 > @@ -8,11 +8,14 @@ > > /* INCLUDES ******************************************************************/ > > -#include <asm.h> > +#include <reactos/asm.h> > +#include <ndk/i386/asm.h> > #include <internal/i386/asmmacro.S> > -.intel_syntax noprefix > > /* FUNCTIONS ****************************************************************/ > + > +.code32 > +.text > > .globl _KiGetUserModeStackAddress@0 > .func KiGetUserModeStackAddress@0 > > _________________________________________________________________ Tutto lo spazio che ti serve, lo trovi su Hotmail http://www.windowslive.it/hotmail/SpazioDisponibile.aspx

15 years, 5 months

1
0
0 0

FLISOL 2010

by Raúl Avila Catalá

Hi for all the ReactOS community, soon brings near to him the FLISOL2010 and want to take the CD that appears in the ReactOS page, since the discharge from tub makes to him impossible for the limited bandwidth that has in the island... Please if some interested party in collaborating, it need a CD that it contains the operative system ( in Spanish ), the source code of ReactOS and some manuals ( in Spanish )... I, will make oneself responsible for make copy them and distribute it for the happening, in order that the Cuban community that has not access to the Internet can obtain " the alternative of Windows ". They can me write directly to my address of post: raul08012(a)cha.jovenclub.cu R++

15 years, 5 months

10
19
0 0

[HAL]: Regression in Real Hardware relates to HAL changes

by victor martinez

Hi, One big regression has been detected due to the HAL changes: Scenario: Real Hardware. One CDROM attached to IDE in Slave Mode in its own. What happens: It bugchecks since 45324.Latest working revision known 45319. DebugLog: http://www.reactos.org/paste/index.php/6511/ Reporter: Caemyr. Suspicious revisions in the range (45319-45324): 45320: [HAL]: Rewrite IRQL handling. (sir_richard) 45324: [HAL]: fix HalEndSystemInterrupt prototype.(spetreolle) Also there are users reporting problems(maybe not related) with CDRom under Vbox. Please look at it. Thanks :) PS: Sorry for double posting.But i prefer this in a new thread. _________________________________________________________________ Los auténticos Hotmail y Messenger en tu Blackberry con Movistar. ¡Descárgatelos ya! http://serviciosmoviles.es.msn.com/messenger/blackberry.aspx

15 years, 5 months

1
0
0 0

RosBE 1.5 is here - Mandatory update!

by Colin Finck

Hi folks, Finally, the new version 1.5 of the ReactOS Build Environment has been finished. The new releases for Windows and Unix are available at http://reactos.org/wiki/Build_Environment. With the new version, we're finally moving to newer toolchain versions (Binutils 2.20.51-20091222, GCC 4.4.3). These allow us to get rid of many old hacks, but also require some new modifications to the source. Unfortunately, these changes are incompatible to our current build environment, so the update to 1.5 is mandatory. I've also taken the chance to get rid of some other hacks, which had required a united TRUNK and RosBE update (like calling the makefile "makefile.auto" instead of "makefile-i386.auto" just for the i386 architecture). The patch for these changes is available at http://www.reactos.org/bugzilla/show_bug.cgi?id=4810 and was tested and improved for months now. I've been told to commit it very soon to not delay the migration to RosBE 1.5 once again. Therefore, please prepare yourselves with the new RosBE as soon as possible. Best regards, Colin

15 years, 5 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [sir_richard] 45525: [MISC]: Build fixes to sync up with latest changes. [SETUPLDR]: Do not build on ARM. On a side note, I offer a bountry for "if ARCH != ARM" support in .rbuild files, instead of only allowing ==.

by Hervé Poussineau

Hi, sir_richard(a)svn.reactos.org a écrit : > Author: sir_richard > Date: Tue Feb 9 04:05:49 2010 > New Revision: 45525 > > URL: http://svn.reactos.org/svn/reactos?rev=45525&view=rev > Log: > [MISC]: Build fixes to sync up with latest changes. > [SETUPLDR]: Do not build on ARM. On a side note, I offer a bountry for "if ARCH != ARM" support in .rbuild files, instead of only allowing ==. > I think <ifnot property="ARCH" value="arm"> ... </ifnot> will fit your needs Hervé

15 years, 5 months

1
0
0 0

Trap handler rewrite

by Timo Kreuzer

No doubt the new code is a huge advantage over the old code. Still there are some issues in my opinion. Currently the trap handlers are generated inside C code by a macro called KiTrap(), located in trap_x.h. This macro creates a C function, that uses KiTrapStub inline function to create the actual entry stub. KiTrapStub is 90% pure gcc inline assembly. At the end it does a jmp to the real C handler. Most C handlers will start processing with an inline function KiEnterTrap, which is C code with inline assembly functions like KiSetSaneSegments, Ke386GetFs. KiTrap06Handler/Trap0DHandler are exceptions, they use KiIsV8086TrapSafe to determine in inline assembly if we have a v86 trap. In this case KiEnterV86Trap is used instead of KiEnterTrap. KiTrap02 is also an exception, it's a pure C handler Now what's wrong? 1.) The gcc inline assembly is very compiler specific and MSVC unfriendly. The old method using GAS specific asm files was at least linkable with MSVC code. The new code needs porting. 2.) The current C code makes assumptions about what the compiler will do, ignoring the ABI, which requires that you do not change ds/es in C code, not even temporarily and that the direction flag is clear on function entry. The compiler might at any place use ds/es for whatever it likes. It must be a valid flat segment. Only using stack variables might work on the current gcc, but might fail on other compilers. A good example would be MSVC's use of __security_cookie, which is referenced on function entry through ds. I remember that not having cleared the direction flag in a trap handler caused strange random bugs in the past, we should avoid making this mistake again. KiTrapStub even changes esp inside C code (in cases where the function is entered without valid esp) Suggested modifications: Implement the trap entry functions in a pure assembly file, using assembly macros which would combine KiTrapStub and the segment handling part of KiEnterTrap. Trap exit could possibly be done this way as well. On the amd64 branch the C handlers return a status value back to the assembly stub, but a jump or call could be done as well. It would be possible to use ML for these assembly files as well. This works fine in the amd64 branch. Also strictly stick to C ABI instead of using compiler extensions and making assumptions about how the compiler works. It would improve portability, make the code safe and also more readable. And we would not really add more assembly, just move the current inline assembly to a pure assembly file. Possible performance disadvantages: I don't see any. We might end up with a jmp or call instruction more, but we can possibly safe this somewhere else. And maybe finally someone deletes the disgusting Ke386SetDs()... ;-) Regards, Timo

15 years, 5 months

2
1
0 0

Fwd: Mail delivery failed: returning message to sender

by Andrew Faulds

Hmm... either his email address is invalid, the server is playing up or it filters out UK addresses... ---------- Forwarded message ---------- From: Mail Delivery System <Mailer-Daemon(a)jovenclub.cu> Date: Fri, Feb 5, 2010 at 6:58 PM Subject: Mail delivery failed: returning message to sender To: ajfweb(a)googlemail.com This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: cl2raul(a)cha.jovenclub.cu SMTP error from remote mail server after RCPT TO:< cl2raul(a)cha.jovenclub.cu>: host 192.168.54.3 [192.168.54.3]: 550 5.1.1 <cl2raul(a)cha.jovenclub.cu>: Recipient address rejected: User unknown in local recipient table ------ This is a copy of the message, including all the headers. ------ Return-path: <ajfweb(a)googlemail.com> Received: from [192.168.250.1] (helo=mx1.jovenclub.cu) by tinored.jovenclub.cu with esmtp (Exim 4.63) (envelope-from <ajfweb(a)googlemail.com>) id 1NdTNq-000HgO-6D for cl2raul(a)cha.jovenclub.cu; Fri, 05 Feb 2010 18:58:26 +0000 Received: from mailnull by mx1.jovenclub.cu with spam-scanned (Exim 4.63 (FreeBSD)) (envelope-from <ajfweb(a)googlemail.com>) id 1NdTNq-000IDE-7k for cl2raul(a)cha.jovenclub.cu; Fri, 05 Feb 2010 18:58:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mx1.jovenclub.cu X-Spam-Level: X-Spam-Status: No, score=-1.2 required=4.0 tests=ALL_TRUSTED,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR autolearn=ham version=3.1.6 Received: from mail-pz0-f182.google.com ([209.85.222.182]) by mx1.jovenclub.cu with esmtp (Exim 4.63 (FreeBSD)) (envelope-from <ajfweb(a)googlemail.com>) id 1NdTNn-000ICP-09 for cl2raul(a)cha.jovenclub.cu; Fri, 05 Feb 2010 18:58:26 +0000 Received: by pzk12 with SMTP id 12so4356424pzk.13 for <cl2raul(a)cha.jovenclub.cu>; Fri, 05 Feb 2010 10:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=Qjk7GMbRPg6inIkmDQ9DobZkrya+x133yYcrqGKOV/s=; b=E7Ib+hPZq0DnQoANH+Nm+wXSRntTlNmh6rFqQQzQl9/mUB4U/lfGq2/2DAeL/3CSi4 qDexVPr9cJgfYJQgbrWenSF0AStaHKKPXnx8cLdXbgmTKuS/NxH3vp1wTE1PJmWwEA71 1OWpVC6onFv/M3rFvazpXkBl5Qj7IJk1wr7Hw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=iY13PwPYzh1Na4Qq70qyWEjChhA0VmqlvPgD9zjgwXB+PtIWJzISeq/Fa928RmuhLb y1mOwDTK3ucwm6AZ03TdGRwUV87eHbPn8AW16r8gdvIbzn6cPg8g+p6dBk9B9jP5YrCv hQY2IrCYgkLpRmsV1iyzmhxm0EJ4NDBHnP3Gc= MIME-Version: 1.0 Received: by 10.141.90.15 with SMTP id s15mr2119324rvl.137.1265396333097; Fri, 05 Feb 2010 10:58:53 -0800 (PST) In-Reply-To: < 41245.192.168.54.4.1265395610.squirrel(a)webmail.cha.jovenclub.cu> References: <41245.192.168.54.4.1265395610.squirrel(a)webmail.cha.jovenclub.cu > From: Andrew Faulds <ajfweb(a)googlemail.com> Date: Fri, 5 Feb 2010 18:58:33 +0000 Message-ID: <bac4c08c1002051058i494abe2oe655dd2a5ab4c9f1(a)mail.gmail.com> Subject: Re: [ros-dev] FLISOL 2010 To: cl2raul(a)cha.jovenclub.cu, ReactOS Development List <ros-dev(a)reactos.org> Content-Type: multipart/alternative; boundary=000e0cd1124eef34f0047edf0ac2 --000e0cd1124eef34f0047edf0ac2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please do bear in mind ReactOS is in ALPHA, i.e. not suitable for normal use. If you want such a CD, my advice would be to download the debug version of reactos from the website and source code then burn the two files (the ISO and the zip file) to a CD. ReactOS has one CD if I remember correctly, that does all languages (If I'm wrong please correct me) Also, AFAIK ReactOS has no manuals, it has SOME documentation in the wiki, but overall it lacks much documentation. 2010/2/5 Ra=FAl Avila Catal=E1 <raul08012(a)cha.jovenclub.cu> > Hi for all the ReactOS community, soon brings near to him the FLISOL2010 > and want to take the CD that appears in the ReactOS page, since the > discharge from tub makes to him impossible for the limited bandwidth that > has in the island... > > Please if some interested party in collaborating, it need a CD that it > contains the operative system ( in Spanish ), the source code of ReactOS > and some manuals ( in Spanish )... > > I, will make oneself responsible for make copy them and distribute it for > the happening, in order that the Cuban community that has not access to > the Internet can obtain " the alternative of Windows ". > > They can me write directly to my address of post: > raul08012(a)cha.jovenclub.cu > > > R++ > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > --000e0cd1124eef34f0047edf0ac2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please do bear in mind ReactOS is in ALPHA, i.e. not suitable for normal us= e. If you want such a CD, my advice would be to download the debug versi= on of reactos from the website and source code then burn the two files (the= ISO and the zip file) to a CD. ReactOS has one CD if I remember correctly, that does all languages (If= I'm wrong please correct me) Also, AFAIK ReactOS has no manuals= , it has SOME documentation in the wiki, but overall it lacks much document= ation. <div class=3D"gmail_quote">2010/2/5 Ra=FAl Avila Catal=E1 <<a href=3D"mailto:raul08012@cha.jovenclub.cu">raul08012(a)cha.jovenc= lub.cu</a>> <blockquote class=3D"gmail_quote" style=3D"margin:= 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left= : 1ex;"> Hi for all the ReactOS community, soon brings near to him the FLISOL2010<br= > and want to take the CD that appears in the ReactOS page, since the discharge from tub makes to him impossible for the limited bandwidth that<b= r> has in the island... Please if some interested party in collaborating, it need a CD that it contains the operative system ( in Spanish ), the source code of ReactOS<br= > and some manuals ( in Spanish )... I, will make oneself responsible for make copy them and distribute it for<b= r> the happening, in order that the Cuban community that has not access to the Internet can obtain " the alternative of Windows ". They can me write directly to my address of post: <a href=3D"mailto:raul080= 12(a)cha.jovenclub.cu">raul08012(a)cha.jovenclub.cu</a> R++ _______________________________________________ Ros-dev mailing list <a href=3D"mailto:Ros-dev@reactos.org">Ros-dev(a)reactos.org</a> <a href=3D"http://www.reactos.org/mailman/listinfo/ros-dev" target=3D"_blan= k">http://www.reactos.org/mailman/listinfo/ros-dev</a> </blockquote></div> --000e0cd1124eef34f0047edf0ac2--

15 years, 5 months

1
0
0 0

Debugging at the next level...

by Timo Kreuzer

Source level debugging thanks to MSVC and pdb files. Only the line numbers seem to be a bit off.

15 years, 5 months

4
3
0 0

ros-amd64-bringup! Surprise! No Region Leaks!

by James Tabor

Since this is true and the ros-amd64-bringup tree is up to date with the region and WND code I committed without the assumed fixes to the region leaks in my working tree,,,,,,,,,,, Also to note I was looking for a ghost,,,,, wasting my TIME!,,,, Is it possible to build ros-amd64-bringup in 32 bit mode? So,,,,, I can continue my work and commit my updates to head knowing I'm not the FFFf ff uf problem! FYFI: I just finished a point to point compare and the only differences are kernel changes! Thanks, James

15 years, 5 months

3
5
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 45433: [NTOS] On MSVC implement _lgdt, __sgdt, __lldt, __sldt, __ltr and __str as assembly functions, because there is no inline assembly. The MSVC/ML64 built kernel now boots and WinDbg connects.

by Steven Edwards

On Thu, Feb 4, 2010 at 10:05 PM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Fri Feb 5 04:05:51 2010 > New Revision: 45433 > > URL: http://svn.reactos.org/svn/reactos?rev=45433&view=rev > Log: > [NTOS] > On MSVC implement _lgdt, __sgdt, __lldt, __sldt, __ltr and __str as assembly functions, because there is no inline assembly. > The MSVC/ML64 built kernel now boots and WinDbg connects. And there was much rejoicing ;) -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

15 years, 5 months

1
0
0 0

Kernel Crash per Rev 45401

by James Tabor

Seems to be very common. *** Fatal System Error: 0x0000007f (0x00000008,0x00000000,0x00000000,0x00000000) Entered debugger on embedded INT3 at 0x0008:0x808c6708. kdb:> bt Eip: <ntoskrnl.exe:c6709 (lib/rtl/i386/debug_asm.S:42 (RtlpBreakWithStatusInstruction))> Frames: <ntoskrnl.exe:9e6d (ntoskrnl/ke/bug.c:1110 (KeBugCheckWithTf@24))> <ntoskrnl.exe:35d7 (ntoskrnl/ke/i386/exp.c:1170 (KeRaiseUserException@4))> <ntoskrnl.exe:60cb (ntoskrnl/ke/i386/traphdlr.c:741 (@KiTrap09Handler@4))> <00000000> kdb:>

15 years, 5 months

1
0
0 0

would You try to implement The Microsoft Active Accessibility standarts to The Reactos?

by Mgr. Janusz Chmiel

Dear core developers of Reactos, I Am very nicely surpriced by The fact, that so complex project like developing new operating system from scratch based on Windows XP kernel and API functions calls exists. I tried to install The Reactos and i can tell You, that even visually impaired user can install Reactos to The empty computer harddrive without need to even make unattended installation. I was able to successfully install Reactos operating system to my computer. I Am now solving issue, how to install The driver for my sound cart when many functions of Reactos are for now only accessible with mouse. So please, if Reactos device manager is reporting, That The sound device is working correctly, but only multimedia adapter list item is presenting my Soundmax integrated digital audio sound cart, it do not means, that Reactos can automatically use this eevice without need to add The driver? I tried to install The driver by using The setup program provided with The driver, i unfortunately have got a error message, that setup has occurred an error and must be closed. Please check, if another instance of setup is not active. By using add new hardware wizard, could i install The driver by specifiing The exact location for this driver? It is The WDM based driver for Soundmax digital integrated audio, which is build in The motherboard of The IBM Thinkpat 2668. I would like to know, if Microsoft Active accessibility standards could be implemented on The future during developing Reactos. I found out, that oleacc.dll is being presented and is The part of The Reactos installation. But i do not know, if You could implement MSAA standarts, because knowing The API functions and The object methods and properties will not be probably enough to ensure, that MSAA standarts would work. I would like to test some screen reader, which is based on using API calls and by using MSAA calls, but i do not know, if it is implemented. My problems is now to add sound cart driver to test this. I Am advanced user with some advanced system administration knowledge, i know Windows operating systems starting with Windows for Workgroups 3.11 to Windows XP Professional. I can use Linux distributions to copy some needed files to The partition, where Reactos has been installed. I can even find necessary debug logs and send them as AN E-mails by using Linux distribution. Linux distro could help me in The situations, when Reactos can not give me some feetback. Installing sound driver manually by using registry editor is not easy task and i can not perform it without screen reader support. I Am surpriced by The stability of Reactos. Eventhough some API calls are not awailable for now, The kernel is very stable and i have never got some crash dialog Window informing me, that application has crashed, sorry for any problems. If You would try to think about implementation of MSAA, many visually impaired users would be very very glad because of it. And later, what about triing to implement some hod keys for controlling The user interface and for controlling The Explorer? Thank you very much, i Am ready for debugging and testing The Reactos. PS: I have never able to install and run Windows XP so quickly, without using Nlite program, which is able to modifi setup.sif file and some other files on Windows XP installation CD, i would never been able to perform The installation of commercial Windows XP myself. Only with Reactos, i could perform this without stress and without need to use some other external utility. I AM also very very glad, that Reactos is even able to work as a live CD. And here are some links for downloading freeware or opensource screen readers, which are fully compatible with Windows Xp and are not based on Display chaining manager DCM, which is too complex to implement even on future for You. Those screen readers are based on using API calls and on using MSAA standarts. Unfortunately, NVDA will not work, because some important libraryes are not The part of The installation of Reactos. It is probably wrong idea triing to mix original libraries from Microsoft with Yours operating system, because i think, that it could cause some confuses and often crashes. Because i can really constructively cooperate with You, i will send You The list of libraryes, on which NVDA screen reader is depend on. And here is The direct link for downloading latest stable version of NVDA, which do not have to be installed, You can only unzip it and place it on some directory on Yours Reactos installation. http://www.nvda-project.org/download/releases/nvda_2009.1_portable.exe I Am recommending You to join to The NVDA development mailing list. YOu will need to have YOur sound drivers properly configured. NVDA screen reader is by The default triing to load included Espeak speech synthesizer, which is The part of NVDA package. This speech synthesizer is written by using Microsoft Visual C++ express 2005, and The original source code of this speech synthesizer variant for WIndows has been modified so this synthesizer is not working like The SAPI5 compatible speech synthesizer, but like a Activex library, which can be called from NVDA. Espeak will very probably depend on wdmaud.drv and NVDA is also using winmm.dll library. The list of dlls, which NVDA is using will be sended on The separate E-mail. PS: Please, try to allow visually impaired computer users to use freeware and fully functional operating system, which is based on standarts of WIndows XP and 2003. If MSAA standarts are too complex to develope from scrath for You to prevent random crashes while using Yours future new dlls, which would come out from this standarts, i will understand it. You are working on very, very complex project while using legally obtained technical information from various sources. PS: I know, that it is not possible to use products, which are developed by Microsoft on other operating system, that on original operating system from Microsoft, so triing to donwload WIndows Internet Explorer 8.0 and triing to use it with Reactos will probably not be legal. But if it is so, never mind. There is Mozilla Firefox WEB browser, which is working with NVDA screen reader very nicely, and also Opera WEB browser is able to provide some accessibility support for visually impaired computer users. And Openoffice ORG is also working very nicely. But for now, i would atleast like to try, if NVDA can speak atleast somethink or if many API calls are not presented. Thank You for cooperation with me. With kindness regards. Janusz Chmiel

15 years, 5 months

4
6
0 0

SVN server

by Aleksey Bragin

Hi, we're upgrading the SVN server currently, which should finish shortly. It's in readonly state until the upgrade finishes. WBR, Aleksey Bragin.

15 years, 5 months

1
1
0 0

[ros-diffs] [evb] 45403: -

by James Tabor

My best guess or 45402 but~ the test bot is dead, I hope this is leading somewhere good and fast!

15 years, 5 months

1
0
0 0

The list of DLLS, on which NVDA screen reader is strictly depend

by Mgr. Janusz Chmiel

Dear developers of Reactos, As i promised in my previous E-mail, i AM sending You The list of dlls, on which NVDA screen reader is strictly depend and without them will not work. Thank You for any feetback provided. OLEAUT32.dll - C:\WINDOWS\system32\OLEAUT32.dll USER32.dll - C:\WINDOWS\system32\USER32.dll POWRPROF.dll - C:\WINDOWS\system32\POWRPROF.dll SHELL32.dll - C:\WINDOWS\system32\SHELL32.dll ole32.dll - C:\WINDOWS\system32\ole32.dll WINMM.dll - C:\WINDOWS\system32\WINMM.dll WSOCK32.dll - C:\WINDOWS\system32\WSOCK32.dll COMDLG32.dll - C:\WINDOWS\system32\COMDLG32.dll ADVAPI32.dll - C:\WINDOWS\system32\ADVAPI32.dll msvcrt.dll - C:\WINDOWS\system32\msvcrt.dll WS2_32.DLL - C:\WINDOWS\system32\WS2_32.DLL GDI32.dll - C:\WINDOWS\system32\GDI32.dll VERSION.dll - C:\WINDOWS\system32\VERSION.dll KERNEL32.dll - C:\WINDOWS\system32\KERNEL32.dll COMCTL32.dll - C:\WINDOWS\system32\COMCTL32.dll RPCRT4.dll - C:\WINDOWS\system32\RPCRT4.dll Extracting all API calls from NVDA source code written in Python will not be easy task, and extracting those calls from source code written in C language for several helper libraryes will not be asy to.

15 years, 6 months

3
3
0 0

RosBE 1.5 Release Candidates

by Colin Finck

Hello everybody, After some more updates, fixes and strange problems, Daniel and I finally released new RCs of RosBE-Windows and RosBE-Unix 1.5. Daniel published a changelog for the Windows version at http://dreimer.de.vu. The Unix version fixes building problems on many hosts, especially 64-bit ones. Like RosBE-Windows, it also includes updated tools such as GCC 4.4.3. Besides, all supplied libraries are guaranteed to contain STABS+ symbols useful for debugging with e.g. GDB. Finally, make/makex now reports the correct return value instead of always 0 :-) You can download RosBE-Windows 1.5-RC4 and RosBE-Unix 1.5-RC2 at http://reactos.colinfinck.de. Please test out both of them using the latest code patch at http://www.reactos.org/bugzilla/show_bug.cgi?id=4810, so that we can move to RosBE 1.5 and GCC 4.4.x soon. For the Unix version, I'm especially looking for testers using non-Linux operating systems such as Mac OS X or FreeBSD. Current RosBE works well on them, but the previous RC made problems. Best regards, Colin

15 years, 6 months

3
2
0 0

Trap0D while not in V86 mode

by Kamil Hornicek

posting as requested in r45348.. (hal/halx86/generic/bios.c:228) HAL: Trap0D while not in V86 mode DbgEbp: 0 DbgEip: 0 DbgArgMark: 0 DbgArgPointer: 0 TempSegCs: 0 TempEsp: 0 Dr0: 0 Dr1: 0 Dr2: 0 Dr3: 0 Dr6: 0 Dr7: 0 SegGs: 0 SegEs: 0 SegDs: 0 Edx: 2697 Ecx: eba5aa34 Eax: 0 PreviousPreviousMode: 0 ExceptionList: eba5ad80 SegFs: 0 Edi: 7000 Esi: 8436a Ebx: eba5aa34 Ebp: eba5aa30 ErrCode: 0 Eip: 80604a80 SegCs: 8 EFlags: 13086 HardwareEsp: 0 HardwareSegSs: a000 V86Es: eba5ad48 V86Ds: 0 V86Fs: 0 V86Gs: 0

15 years, 6 months

1
0
0 0

r45321: STABS+ and -g* option change

by Sylvain Petreolle

This change keeps the ability to plug GDB into ReactOS and fixes libxlst. It also fixes bootcd with Rosbe 1.5 trunk builds. With -g0 enabled in RosBE-Unix 1.5 instead of STABS+, previous builds of bootcd used to fail to allocate memory and crash. Kind regards, Sylvain Petreolle

15 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [sir_richard] 45297: [PERF]: Not in any way a scientific number you should bet the farm on, but we do now count the number of cycles at the very first instruction of kernel initialization, at the moment SMSS initializes the registry (when

by Ged Murphy

This is really interesting. It'd be great to have this up in testman somehow. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of sir_richard(a)svn.reactos.org Sent: 28 January 2010 15:51 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [sir_richard] 45297: [PERF]: Not in any way a scientific number you should bet the farm on, but we do now count the number of cycles at the very first instruction of kernel initialization, at the moment SMSS initializes the registry (when we c Author: sir_richard Date: Thu Jan 28 16:51:18 2010 New Revision: 45297 URL: http://svn.reactos.org/svn/reactos?rev=45297&view=rev Log: [PERF]: Not in any way a scientific number you should bet the farm on, but we do now count the number of cycles at the very first instruction of kernel initialization, at the moment SMSS initializes the registry (when we call kernel initialization complete), and at the moment there have been 12 processes created (10 without counting idle/system), which is a bit less than a normal GUI boot. We also display the number if interrupts, system calls, and context switches it took to get us there. A purely comparative number, perhaps worthy for inclusion in testman/regression tests? Modified: trunk/reactos/ntoskrnl/config/ntapi.c trunk/reactos/ntoskrnl/include/internal/ke.h trunk/reactos/ntoskrnl/ke/i386/kiinit.c trunk/reactos/ntoskrnl/ps/process.c Modified: trunk/reactos/ntoskrnl/config/ntapi.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/ntapi.c?re… ============================================================================== --- trunk/reactos/ntoskrnl/config/ntapi.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/config/ntapi.c [iso-8859-1] Thu Jan 28 16:51:18 2010 @@ -890,6 +890,14 @@ /* Always do this as kernel mode */ if (KeGetPreviousMode() == UserMode) return ZwInitializeRegistry(Flag); + /* Enough of the system has booted by now */ + BootCyclesEnd = __rdtsc(); + DPRINT1("Boot took %I64d cycles!\n", BootCyclesEnd - BootCycles); + DPRINT1("Interrupts: %d System Calls: %d Context Switches: %d\n", + KeGetCurrentPrcb()->InterruptCount, + KeGetCurrentPrcb()->KeSystemCalls, + KeGetContextSwitches(KeGetCurrentPrcb())); + /* Validate flag */ if (Flag > CM_BOOT_FLAG_MAX) return STATUS_INVALID_PARAMETER; Modified: trunk/reactos/ntoskrnl/include/internal/ke.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… ============================================================================== --- trunk/reactos/ntoskrnl/include/internal/ke.h [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/include/internal/ke.h [iso-8859-1] Thu Jan 28 16:51:18 2010 @@ -139,6 +139,8 @@ extern ULONG KiFreezeFlag; extern ULONG KiDPCTimeout; extern PGDI_BATCHFLUSH_ROUTINE KeGdiFlushUserBatch; +extern ULONGLONG BootCycles, BootCyclesEnd; +extern ULONG ProcessCount; /* MACROS *************************************************************************/ Modified: trunk/reactos/ntoskrnl/ke/i386/kiinit.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/kiinit.c?… ============================================================================== --- trunk/reactos/ntoskrnl/ke/i386/kiinit.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/ke/i386/kiinit.c [iso-8859-1] Thu Jan 28 16:51:18 2010 @@ -24,6 +24,10 @@ /* Spinlocks used only on X86 */ KSPIN_LOCK KiFreezeExecutionLock; KSPIN_LOCK Ki486CompatibilityLock; + +/* Perf */ +ULONG ProcessCount; +ULONGLONG BootCycles, BootCyclesEnd; /* FUNCTIONS *****************************************************************/ @@ -683,6 +687,9 @@ PKTSS Tss; PKIPCR Pcr; + /* Boot cycles timestamp */ + BootCycles = __rdtsc(); + /* Check if we are being booted from FreeLDR */ if (!((ULONG_PTR)LoaderBlock & 0x80000000)) KiRosPrepareForSystemStartup((PROS_LOADER_PARAMETER_BLOCK)LoaderBlock); Modified: trunk/reactos/ntoskrnl/ps/process.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/process.c?rev=… ============================================================================== --- trunk/reactos/ntoskrnl/ps/process.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/ps/process.c [iso-8859-1] Thu Jan 28 16:51:18 2010 @@ -843,6 +843,18 @@ /* Run the Notification Routines */ PspRunCreateProcessNotifyRoutines(Process, TRUE); + + /* If 12 processes have been created, enough of user-mode is ready */ + if (++ProcessCount == 12) + { + /* Enough of the system has booted by now */ + BootCyclesEnd = __rdtsc(); + DPRINT1("User Boot took %I64d cycles!\n", BootCyclesEnd - BootCycles); + DPRINT1("Interrupts: %d System Calls: %d Context Switches: %d\n", + KeGetCurrentPrcb()->InterruptCount, + KeGetCurrentPrcb()->KeSystemCalls, + KeGetContextSwitches(KeGetCurrentPrcb())); + } CleanupWithRef: /*

15 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [mkupfer] 45302: this log message left intentionally non-descriptive

by Ged Murphy

This is a bad idea. Ignoring the fact that the code is a serious crash hazard, you've now got a public place which needs to be kept current. I bet I can name at least 10 developers which aren't on this list. On Thu, Jan 28, 2010 at 10:18 PM, <mkupfer(a)svn.reactos.org> wrote: > Author: mkupfer > Date: Thu Jan 28 23:18:31 2010 > New Revision: 45302 > > URL: http://svn.reactos.org/svn/reactos?rev=45302&view=rev > Log: > this log message left intentionally non-descriptive > > Modified: > trunk/reactos/dll/cpl/sysdm/general.c > trunk/reactos/dll/cpl/sysdm/lang/de-DE.rc > trunk/reactos/dll/cpl/sysdm/lang/en-US.rc > trunk/reactos/dll/cpl/sysdm/resource.h > > Modified: trunk/reactos/dll/cpl/sysdm/general.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/cpl/sysdm/general.c?re… > > ============================================================================== > --- trunk/reactos/dll/cpl/sysdm/general.c [iso-8859-1] (original) > +++ trunk/reactos/dll/cpl/sysdm/general.c [iso-8859-1] Thu Jan 28 23:18:31 > 2010 > @@ -12,6 +12,9 @@ > > #include "precomp.h" > > +#define ANIM_STEP 2 > +#define ANIM_TIME 50 > + > typedef struct _IMGINFO > { > HBITMAP hBitmap; > @@ -19,6 +22,7 @@ > INT cySource; > } IMGINFO, *PIMGINFO; > > +PIMGINFO pImgInfo = NULL; > > void > ShowLastWin32Error(HWND hWndOwner) > @@ -70,6 +74,124 @@ > } > } > > +LRESULT CALLBACK RosImageProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM > lParam) > +{ > + static UINT timerid = 0, top = 0, offset; > + static HBITMAP hBitmap2; > + RECT r; > + NONCLIENTMETRICS ncm; > + HFONT hfont; > + BITMAP bitmap; > + HDC dc, sdc; > + TCHAR devtext[2048]; > + switch (uMsg) > + { > + case WM_LBUTTONDBLCLK: > + if (wParam & (MK_CONTROL | MK_SHIFT)) > + { > + if (timerid == 0) > + { > + top = 0; // set top > + > + // build new bitmap > + GetObject(pImgInfo->hBitmap, > sizeof(BITMAP), &bitmap); > + dc = > CreateCompatibleDC(GetDC(NULL)); > + sdc = CreateCompatibleDC(dc); > + ncm.cbSize = > sizeof(NONCLIENTMETRICS); > + > SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), > &ncm, 0); > + > + hfont = > CreateFontIndirect(&ncm.lfMessageFont); > + SelectObject(dc, hfont); > + SetRect(&r, 0, 0, 0, 0); > + LoadString(hApplet, IDS_DEVS, > devtext, sizeof(devtext) / sizeof(TCHAR)); > + DrawText(dc, devtext, -1, &r, > DT_CALCRECT); > + hBitmap2 = > CreateBitmap(pImgInfo->cxSource, (2 * pImgInfo->cySource) + (r.bottom + 1 - > r.top), bitmap.bmPlanes, bitmap.bmBitsPixel, NULL); > + SelectObject(sdc, > pImgInfo->hBitmap); > + SelectObject(dc, hBitmap2); > + offset = 0; > + BitBlt(dc, 0, offset, > bitmap.bmWidth, bitmap.bmHeight, sdc, 0, 0, SRCCOPY); > + offset += bitmap.bmHeight; > + > + SetRect(&r, 0, offset, > bitmap.bmWidth, offset + (r.bottom - r.top) + 1); > + FillRect(dc, &r, > GetSysColorBrush(COLOR_3DFACE)); > + SetBkMode(dc, TRANSPARENT); > + OffsetRect(&r, 1, 1); > + SetTextColor(dc, > GetSysColor(COLOR_BTNSHADOW)); > + DrawText(dc, devtext, -1, &r, > DT_CENTER); > + OffsetRect(&r, -1, -1); > + SetTextColor(dc, > GetSysColor(COLOR_WINDOWTEXT)); > + DrawText(dc, devtext, -1, &r, > DT_CENTER); > + offset += r.bottom - r.top; > + > + BitBlt(dc, 0, offset, > bitmap.bmWidth, bitmap.bmHeight, sdc, 0, 0, SRCCOPY); > + offset += bitmap.bmHeight; > + DeleteDC(sdc); > + DeleteDC(dc); > + > + timerid = SetTimer(hwnd, 1, > ANIM_TIME, NULL); > + } > + } > + break; > + case WM_LBUTTONDOWN: > + if (timerid) > + { > + KillTimer(hwnd, timerid); > + top = 0; > + timerid = 0; > + DeleteObject(hBitmap2); > + InvalidateRect(hwnd, NULL, FALSE); > + } > + break; > + case WM_TIMER: > + top += ANIM_STEP; > + if (top > offset - pImgInfo->cySource) > + { > + KillTimer(hwnd, timerid); > + top = 0; > + timerid = 0; > + DeleteObject(hBitmap2); > + } > + InvalidateRect(hwnd, NULL, FALSE); > + break; > + case WM_PAINT: > + { > + PAINTSTRUCT PS; > + HDC hdcMem, hdc; > + LONG left; > + if (wParam != 0) > + { > + hdc = (HDC)wParam; > + } else > + { > + hdc = BeginPaint(hwnd,&PS); > + } > + GetClientRect(hwnd,&PS.rcPaint); > + > + /* position image in center of dialog */ > + left = (PS.rcPaint.right - pImgInfo->cxSource) / 2; > + hdcMem = CreateCompatibleDC(hdc); > + > + if (hdcMem != NULL) > + { > + SelectObject(hdcMem, timerid ? hBitmap2 : > pImgInfo->hBitmap); > + BitBlt(hdc, > + left, > + PS.rcPaint.top, > + PS.rcPaint.right - PS.rcPaint.left, > + PS.rcPaint.top + pImgInfo->cySource, > + hdcMem, > + 0, > + top, > + SRCCOPY); > + DeleteDC(hdcMem); > + } > + if (wParam == 0) > + EndPaint(hwnd,&PS); > + break; > + } > + } > + return TRUE; > +} > > static VOID > SetRegTextData(HWND hwnd, > @@ -372,12 +494,9 @@ > WPARAM wParam, > LPARAM lParam) > { > - PIMGINFO pImgInfo; > > UNREFERENCED_PARAMETER(lParam); > UNREFERENCED_PARAMETER(wParam); > - > - pImgInfo = (PIMGINFO)GetWindowLongPtr(hwndDlg, DWLP_USER); > > switch (uMsg) > { > @@ -389,9 +508,8 @@ > return FALSE; > } > > - SetWindowLongPtr(hwndDlg, DWLP_USER, (LONG_PTR)pImgInfo); > - > InitImageInfo(pImgInfo); > + SetWindowLongPtr(GetDlgItem(hwndDlg, IDC_ROSIMG), GWL_WNDPROC, > (LONG)RosImageProc); > GetSystemInformation(hwndDlg); > break; > > > Modified: trunk/reactos/dll/cpl/sysdm/lang/de-DE.rc > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/cpl/sysdm/lang/de-DE.r… > > ============================================================================== > --- trunk/reactos/dll/cpl/sysdm/lang/de-DE.rc [iso-8859-1] (original) > +++ trunk/reactos/dll/cpl/sysdm/lang/de-DE.rc [iso-8859-1] Thu Jan 28 > 23:18:31 2010 > @@ -289,4 +289,5 @@ > IDS_USERPROFILE_TYPE "Typ" > IDS_USERPROFILE_STATUS "Status" > IDS_USERPROFILE_MODIFIED "Geändert" > -END > + IDS_DEVS "\nReactOS Team\n\nProjektkoordinator\n\nAleksey > Bragin\n\nEntwicklerteam\n\nAleksey Bragin\nAndrew Greenwood\nAndrey > Korotaev\nArt Yerkes\nChristoph von Wittich\nColin Finck\nDaniel > Reimer\nDmitry Chapyshev\nEric Kohl\nGed Murphy\nGregor Brunmar\nHervé > Poussineau\nJames Tabor\nJeffrey Morlan\nJohannes > Anderwald\nKJK::Hyperion\nMaarten Bosma\nMagnus Olsen\nMarc > Piulachs\nMatthias Kupfer\nMike Nordell\nPeter Ward\nPierre > Schweitzer\nSaveliy Tretiakov\nStefan Ginsberg\nSylvain Petreolle\nThomas > Blümel\nTimo Kreuzer \n\nAlex Ionescu\nFilip Navara\nGunnar Dalsnes\nMartin > Fuchs\nRoyce Mitchell III\nBrandon Turner\nBrian Palmer\nCasper > Hornstrup\nDavid Welch\nEmanuele Aliberti\nGé van Geldorp\nGregor > Anich\nJason Filby\nJens Collin\nMichael Wirth\nNathan Woods\nRobert > Dickenson\nRex Jolliff\nVizzini \n\nRelease Verantwortliche\n\nColin > Finck\nZ98\n\nWebseitenteam\n\nColin Finck\nJaix Bly\nKlemens > Friedl\nZ98\n\nMedienteam\n\nMindflyer\nWierd_W\n\nweiterer Dank geht > an\n\nalle Mitwirkenden\nWine Team\n\n" > +END > > Modified: trunk/reactos/dll/cpl/sysdm/lang/en-US.rc > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/cpl/sysdm/lang/en-US.r… > > ============================================================================== > --- trunk/reactos/dll/cpl/sysdm/lang/en-US.rc [iso-8859-1] (original) > +++ trunk/reactos/dll/cpl/sysdm/lang/en-US.rc [iso-8859-1] Thu Jan 28 > 23:18:31 2010 > @@ -284,4 +284,5 @@ > IDS_USERPROFILE_TYPE "Type" > IDS_USERPROFILE_STATUS "Status" > IDS_USERPROFILE_MODIFIED "Modified" > -END > + IDS_DEVS "\nReactOS Team\n\nProject Coordinator\n\nAleksey > Bragin\n\nDevelopment Team\n\nAleksey Bragin\nAndrew Greenwood\nAndrey > Korotaev\nArt Yerkes\nChristoph von Wittich\nColin Finck\nDaniel > Reimer\nDmitry Chapyshev\nEric Kohl\nGed Murphy\nGregor Brunmar\nHervé > Poussineau\nJames Tabor\nJeffrey Morlan\nJohannes > Anderwald\nKJK::Hyperion\nMaarten Bosma\nMagnus Olsen\nMarc > Piulachs\nMatthias Kupfer\nMike Nordell\nPeter Ward\nPierre > Schweitzer\nSaveliy Tretiakov\nStefan Ginsberg\nSylvain Petreolle\nThomas > Blümel\nTimo Kreuzer \n\nAlex Ionescu\nFilip Navara\nGunnar Dalsnes\nMartin > Fuchs\nRoyce Mitchell III\nBrandon Turner\nBrian Palmer\nCasper > Hornstrup\nDavid Welch\nEmanuele Aliberti\nGé van Geldorp\nGregor > Anich\nJason Filby\nJens Collin\nMichael Wirth\nNathan Woods\nRobert > Dickenson\nRex Jolliff\nVizzini \n\nRelease Engineers\n\nColin > Finck\nZ98\n\nWebsite Team\n\nColin Finck\nJaix Bly\nKlemens > Friedl\nZ98\n\nMedia Team\n\nMindflyer\nWierd_W\n\nfurther thanks go > to\n\nall Contributers\nWine Team\n\n" > +END > > Modified: trunk/reactos/dll/cpl/sysdm/resource.h > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/cpl/sysdm/resource.h?r… > > ============================================================================== > --- trunk/reactos/dll/cpl/sysdm/resource.h [iso-8859-1] (original) > +++ trunk/reactos/dll/cpl/sysdm/resource.h [iso-8859-1] Thu Jan 28 23:18:31 > 2010 > @@ -156,5 +156,6 @@ > #define RC_LICENSE 1502 > #define RTDATA 1503 > > +#define IDS_DEVS 2000 > > #endif /* __CPL_RESOURCE_H */ > > >

15 years, 6 months

3
2
0 0

ARM port: SWI call numbering

by Theo Markettos

I wonder if I could get in touch with the folks doing the ARM port... Executive summary: From a look at the code I think ARM ReactOS uses SWIs (syscalls) numbered from zero. There's a de-facto ARM standard that splits up SWI numbering so different OSs get allocated different numbering ranges. It would be handy if ReactOS could pick one that doesn't clash with other OSs. I wondered if the ARM port folks might consider changing SWI base at some point. For more details, a brief history lesson. The ARM1 and ARM2 chips were originally developed at Acorn Computers in 1983-7. The first ARM machine was the Archimedes, launched by Acorn in 1987. The Archimedes was supplied with Arthur, which in 1988 became RISC OS, a co-operatively multitasking OS. RISC OS is still around and runs on modern hardware such as the BeagleBoard - see http://www.riscosopen.org/ SWI instructions on the ARM have a 24 bit 'comment' field. As originally envisaged this would hold the syscall number, a bit like INT on x86 and TRAP on 68k. Acorn for their OSs (and there were no other ARM OSs at the time) chose a numbering scheme where bits 20-23 denote the OS. For the ones I know about: 23--20 0000 RISC OS 1000 RISC iX (4.3 BSD ported to ARM2/3) 1001 Formerly Linux (they've now don't use the comment field) 1111 ARM's OS independent routines And NetBSD use another value that I forget. The advantage of having non-overlapping SWI bases is that it allows cross-platform execution of binaries (a bit like WINE in effect, though I don't know the details of how WINE works). So it means RISC OS code (of which there is lots) could run on ReactOS, or vice versa, if somebody writes a syscall implementation for the other platform. So I wondered if there was any interest in making sure the syscall numbers didn't clash with other OSs? From what I see in: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/arm/usercall.c… it looks like your SWIs are numbered from zero, which is a clash. If you were interested in changing, do you have any idea how many SWIs you might use? RISC OS uses hundreds of thousands (SWIs are used as the interface to DLL-like code), but if you were to only need, say, 2^16 that might save the number space a bit. Thoughts? Comments? Flames? Thanks Theo

15 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [dreimer] 45286: - Add piperead to the setup. - Update ChangeLog.txt - Sync clean.ps1 to Colin's changes.

by Colin Finck

dreimer(a)svn.reactos.org wrote: > + if ("$ENV:ROS_AUTOMAKE" -eq "") { > + $ENV:ROS_AUTOMAKE = "makefile-$ENV:ROS_ARCH.auto" > + } > [...] That's not properly ported. My script only sets these variables locally due to "setlocal", yours permanently changes the environment variables. This will result in obvious problems when ROS_ARCH is changed. Don't know whether PS provides an equally elegant way to overwrite these variables locally like Batch does ;-) Best regards, Colin

15 years, 6 months

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev