- Ros-dev - ReactOS.org

[ros-diffs] [gadamopoulos] 51086: [win32k] - SetThreadDesktop: Actually set hdesk in PTHREADINFO Now GetThreadDesktop doesn't return 0

by James Tabor

This breaks the class test, so our message subsystem is broken and even abiword is effected by it.

14 years, 6 months

1
2
0 0

New builder available

by Olaf Siejka

Dear colleagues I am very pleased to inform you that a new builder has been just made operational. Named Patch_x86_GCCWin Debug, you can see it waterfall right now. Based on x86 RBuild trunk, its capable of downloading a patch from bugzilla, applying it to trunk, building reactos testcd and running winetests on it via VBox sysreg. To use it, just pass revision, as well as Parameter 1, name id, value: attachement id. For example, http://www.reactos.org/bugzilla/attachment.cgi?id=5989 name: id, value: 5989 Just the same way you use source for vbox retesting. Right now test ISOs are stored, named with x86_Patch, revision and patch id. Logs itself will be also stored (when i bugfix them) If any issues arise, please mail me or catch me on irc.

14 years, 6 months

8
9
0 0

Fwd: [hm] Open Source Hardware Convention 2011 en Madrid

by Javier Agustìn Fernàndez Arroyo

Hi all, let me forward this email that i have received i dunno if this is useful for you, as its a *hardware *meeting, but anyway.... have a look and let me know! P.S.: email is in english language at the bottom ---------- Forwarded message ---------- From: Syvic <syvic(a)sindormir.net> Date: 2011/3/18 Subject: [hm] Open Source Hardware Convention 2011 en Madrid To: Hackmeeting <hackmeeting(a)listas.sindominio.net> Buenas, (Perdón si os llega por duplicado) Hoy, tras unos cuantos meses de curro, lanzamos al mundo las OSHWCon 2011: (Catalán e inglés más abajo) La OSHWCon <http://oshwcon.org/es> es un encuentro anual de 3 días que organiza el colectivo Synusia <http://synusia.es/> en un esfuerzo de difundir el uso delHardware Libre<http://es.wikipedia.org/wiki/Hardware_libre> y de promocionar la electrónica y la filosofía del «Hazlo tú mismo<http://es.wikipedia.org/wiki/Diy>». Tendrá lugar en el Centro de Formación Padre Piquer<http://www.padrepiquer.com/> de Madrid los *días 23, 24 y 25 de Septiembre de 2011*. Durante la OSHWCon se ofrecerán *charlas*, *talleres*, *mesas redondas*, exposición de *proyectos personales* y sobre todo, un *lugar de encuentro para profesionales y aficionados al mundo de la electrónica*. La *asistencia * es *libre y gratuita* y está pensada para que nadie se quede fuera. Se programarán desde actividades de iniciación, hasta charlas y talleres de alto nivel técnico. Estamos trabajando para que durante la OSHWCon todo el mundo disfrute aprendiendo, intercambiando conocimientos, concursando e incluso jugando con la electrónica o la robótica, siempre desde la filosofía del *Open Source Hardware*. Contamos con *cuatro espacios* para celebrar varias *actividades simultáneas*, de forma que siempre habrá algo que hacer. Si tienes algo que aportar, quieres compartir tu última creación electrónica, eres experto en cierta materia electrónica y deseas explicarlo al mundo, háznoslo saber en el apartado «Propón tu charla<http://jhl.synusia.es/propuesta_charla>». Mira antes el «Call4Papers <http://jhl.synusia.es/call4papers>» para obtener más información acerca de las actividades en las que estamos interesados. Si quieres saber más acerca de qué nos motiva a realizar este encuentro, consulta la página «Manifiesto <http://jhl.synusia.es/manifiesto>». Estáis todos invitados a participar, ya sea como visitantes o como ponentes durante la Con. *¡Te esperamos el fin de semana del 23 al 25 de Septiembre!* Recuerda inscribirte <http://jhl.synusia.es/inscripcion> en la web si tienes pensado asistir. Además, una vez finalizada la OSHWCon, pondremos a disposición de todo el mundo las grabaciones de todas las actividades. Sobre Synusia Synusia <http://synusia.es/> es el grupo de trabajo de electrónica establecido en el C.F. Padre Piquer <http://www.padrepiquer.com/> que organiza esta Con. Synusia nació de la necesidad de crear un punto de encuentro donde compartir libremente y profundizar en el conocimiento de diferentes tecnologías electrónicas y el OSHW. Si estás interesado en participar en la OSHWCon o en saber más acerca de Synusia, no dudes en mandarnos un correo (Encontrarás más información en nuestra página web<http://synusia.es/>). Cualquier sugerencia será bienvenida. CATALÀ La Convenció de Hardware Lliure, Electrònica i Robòtica<http://oshwcon.org/ca> és una trobada anual de 3 dies que organitza el col.lectiu Synusia en un esforç per difondre l'ús del Maquinari Lliure i de promocionar l'electrònica i la filosofia de “Fes-ho tu mateix<http://ca.wikipedia.org/wiki/Do_It_Yourself>” Tindrà lloc en el Centre de Formació Padre Piquer<http://www.padrepiquer.com/> de Madrid els dies *23, 24 i 25 de setembre del 2011*. Durant el OSHWCon s'oferiran *xerrades*, *tallers*, *taules rodones*, exposició de *projectes personals* i, sobretot, un lloc de trobada pels professionals i aficionats al món de l'electrònica. *L'assistència és lliure i gratuïta* i està pensada perquè ningú es quedi fora. Es programaran des d'activitats d'iniciació fins a xerrades i tallers d' un alt nivell tècnic. Estem treballat per a que durant la convenció tothom disfruti aprenent, concursant i, fins i tot, jugant amb l'electrònica o la robòtica, sempre des de la filosofia de l' Open Source Hardware. Comptem amb *quatre espais* per celebrar diverses*activitats simultànies*, de manera que sempre hi haurà alguna cosa a fer. Si tens alguna cosa per aportar, vols compartir la teva darrera creació electrònica, ets expert en certa matèria electrònica i vols explicar-ho a tothom, fes-nos-ho saber en l'apartat “Proposa la teva xerrada<http://oshwcon.org/ca/proposa>”. Mira abans el “Call4Papers <http://oshwcon.org/ca/call4papers>” per obtenir més informació sobre les activitats que realitzem. Si vols saber més sobre què ens motiva a realitzar aquesta trobada, consulta la pàgina “Manifest<http://oshwcon.org/ca/manifest> ”. Esteu tots convidats a participar, ja sigui com a visitants o com a membres actius de el OSHWCon. *T'esperem el cap de setmana del 23 al 25 de setembre! * Recorda inscriure't a la web si tens pensat assistir-hi. A més, una vegada finalitzat la convenció, posarem a la disposició de tothom els enregistraments de les activitats. Sobre Synusia Synusia <http://synusia.es/> és el grup de treball d'electrònica establert en el C.F. Padre Piquer <http://www.padrepiquer.com/> que organitza aquesta convenció. Synusia va nèixer de la necessitat de crear un punt de trobada on es pogués compartir lliurement y profunditzar en el coneixement de diverses tecnologies electròniques i el OSHW. Si estàs interessat en participar en el OSHWCon o en saber més sobre Synusia, no dubtis en enviar-nos un correu (Trobaràs més informació a la nostra pàgina web <http://synusia.es/>). Qualsevol suggerència serà benvinguda. ENGLISH Open Source Hardware, Electronics and Robotics Convention<http://oshwcon.org/en> is a 3-days event organized by the Synusia group in an effort to spread the Open Source Software <http://en.wikipedia.org/wiki/Open-source_hardware> and to promote Electronics and the philosophy of "do it yourself<http://en.wikipedia.org/wiki/DIY>". The event will take place in Madrid, in C. F. Padre Piquer<http://www.padrepiquer.com/>, from *23 to 25 September 2011*. During the OSHWCon, visitors will be able to watch and participate in *talks, workshops, round table discussions*,*personal projects exhibitions* and, above all, we'll offer a meeting place for professionals and amateurs of the world of electronics. *Attendance is free and open to everyone*. Activities are intended to be for everybody: from beginners to hi-level talks and workshops. Our objective is for everybody to enjoy learning, sharing knowledge, taking part or even playing with electronics and robotics throughout the OSHWCon... All of it from the Open Source Hardware philosophy. There are *four different rooms/halls* to hold several *simultaneous activities*, so there will always be something interesting to do. If you have something to contribute with, you want to share your latest electronic creation or you are an expert on some electronic matters and you want to explain it to the world, let us know in "Suggest your talk<http://oshwcon.org/en/suggestyourtalk>". Check out first "Call4Papers <http://oshwcon.org/en/call4papers>" for more information about the activities we are into. In case you wonder what make us organize this event, take a look at our "Manifesto<http://oshwcon.org/en/manifesto> ". You are all welcome to participate, either as a visitor or as an active member of the OSHWCon. *We'll be waiting for you on September 23 to 25!* Please, remember to register first on our site if you are intended to come. We'll also offer the recordings of every activity once the OSHWCon come to close. About Synusia Synusia <http://synusia.es/> is the working group established in C. F. Padre Piquer <http://www.padrepiquer.com/> that organizes this Convention. Synusia<http://synusia.es/> was born from the need of setting up a meeting point where sharing and deepen into the knowledge of different electronic technologies. If you are willing to participate in the OSHWCon or you want to know more about Synusia, feel free to send us an email (you'll find out more in our web site<http://synusia.es/>). Any suggestions will be welcome! _______________________________________________ HackMeeting mailing list HackMeeting(a)listas.sindominio.net https://listas.sindominio.net/mailman/listinfo/hackmeeting

14 years, 6 months

2
2
0 0

Choice of google summer of code project

by Andrew Green

I have been investigating a lot of aspects about theming, and my make that my proposal. Though I have been thinking that will not be of much valuable in the short term or in learning ongoing skills that will be needed in reactos. Of course on of the stated goals of gsoc or to give programmers the skills to contribute in the long term. So I was wondering what were your ideas on what would be considered valuable short term and what would give the skills to to help reactos in the long term. I know it is still 18 hours until google summer of code organizations are announced, but I'm sure reactos will be accepted. Any thoughts or suggestions would be much appreciated.

14 years, 6 months

1
0
0 0

After the release

by Olaf Siejka

Hiya I would like to point out to actions in my opinion necessary to be done after the release: 1. Syncing: Starting a new development/release cycle is the best moment for winesync to be performed. Syncing early will give us much time to find and wipe all Wine-originated bugs, which are simply unavoidable. The Winesync itself should be spreaded to as many revisions as its possible/feasible, as it will help out testers to regress-test any issues more precisely. Before Winesync can be performed, CMake branch should be synchronized with current trunk and the revision synchronized - locked up as reference frame for any Trunk-CMake comparison tests. We would not want CMake effort to be delayed due to any issues with WINE code in trunk. 2. Patches Now guys, i know i`m repeating myself, but please be warned that i will not drop this issue. The way our project is handling patches from outside is absolutely counterproductive. This is the only way new devs can be recruited and get commit access, but delays in reviewing and even reacting to patches is disgraceful. We are driving away potential newcomers, something no one should wonder about, if it often takes months for someone to write down a simple question about the patch content... We are risking a potential project dawnfall if we continue doing this way. I know you are busy with real life, project and other stuff, but seriously, this approach will only make things even more difficult. I did all things i could think of to help you out. Patches are now clearly tagged, listed in accessible way ( http://www.reactos.org/wiki/Bug_Filters ), i even tried to filter them, moving old and questionable stuff into separate directory (WIP aka Work in progress). Right now i took the more direct step of assigning patches to devs personally. It might be questionable, please react in such cases and comment, i will gladly relocate, but please do react. Due to Daniel recent issues and lack of free time, i volunteered for commit translation patches, at least those that can be done easily. Next thing planned here, is a builder dedicated to patch testing, but this is just a rough plan for futher discussion. I would be grateful for ANY feedback from you, perhaps some things could be done better/differently. Thanks in advance for your comments

14 years, 6 months

2
1
0 0

Last 0.3.13 tests

by Colin Finck

Hi all, The branch with all planned changes for 0.3.13 has been finished now and I've uploaded a first build: http://svn.reactos.org/prereleases/ReactOS-0.3.13-prerelease-r51045-bootcd.… It's now time to test this build out and update http://reactos.org/wiki/Tests_for_0.3.13 accordingly. mIRC has already been discovered as a prominent failing application, which just crashes upon connecting (see http://www.reactos.org/bugzilla/show_bug.cgi?id=6005). I consider this a release blocker bug, so some networking guy should look at it. - Colin

14 years, 6 months

3
3
0 0

[ros-diffs] [gadamopoulos] 51031: [win32] - Rafal Harabien:

by James Tabor

Hi all! Since everyone works so fast to ride my ass for breaking things, I hope one of you have a fix for this one and also hope this did not make it into branch! The commit breaks things, I wanted Michael to review the patch before hand. I'm sure any of the IRC archives can find my comments. Going on Holiday, James

14 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [fireball] 51013: [NOTEPAD] - Edijs: Zero initialize the caption string. See issue #5992 for more details.

by Aleksey Bragin

I made a mistake, this patch was written by Rafal Harabien. WBR, Aleksey Bragin. On Mar 11, 2011, at 1:07 AM, fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Thu Mar 10 22:07:56 2011 > New Revision: 51013 > > URL: http://svn.reactos.org/svn/reactos?rev=51013&view=rev > Log: > [NOTEPAD] > - Edijs: Zero initialize the caption string. > See issue #5992 for more details. > > Modified: > trunk/reactos/base/applications/notepad/dialog.c

14 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 51011: FatCreateCcb has no params. Fixes building on msvc

by Gabriel ilardi

omg, glad to see you committing :-) > Date: Thu, 10 Mar 2011 15:37:51 +0000 > To: ros-diffs(a)reactos.org > From: gedmurphy(a)svn.reactos.org > Subject: [ros-diffs] [gedmurphy] 51011: FatCreateCcb has no params. Fixes building on msvc > > Author: gedmurphy > Date: Thu Mar 10 15:37:51 2011 > New Revision: 51011 > > URL: http://svn.reactos.org/svn/reactos?rev=51011&view=rev > Log: > FatCreateCcb has no params. > Fixes building on msvc > > Modified: > trunk/reactos/drivers/filesystems/fastfat_new/dir.c > > Modified: trunk/reactos/drivers/filesystems/fastfat_new/dir.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat_new/dir.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat_new/dir.c [iso-8859-1] Thu Mar 10 15:37:51 2011 > @@ -248,7 +248,7 @@ > } > > /* Set the file object */ > - Ccb = FatCreateCcb(IrpContext); > + Ccb = FatCreateCcb(); > FatSetFileObject(FileObject, > UserDirectoryOpen, > Dcb, > >

14 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [fireball] 50981: [NTOS/FSRTL] - Implement parameters checking i

by Pierre Schweitzer

Hi, this commits just shows you didn't understand how that function works. If you had, you wouldn't have said: "- Implement parameters checking in FsRtlIsNameInExpressionPrivate." It's already done. "- Add two shortcuts for common wildcard invocations to make the function faster." If you look at the algorithm, it will take at maximum as much loop iterations as name length. "- Second (main part of the function) is still under review." Thanks for discussing the issue with the original author of the algorithm, especially since you don't understand it. Furthermore, if you're not happy with said algorithm, you were asked to review it more than a year ago, and for at least 6 months. Thing that you NEVER did. So, now you discovered what my mail address is, contact me before committing anything wrong/useless to current code. And as you said less than a week ago, focus on fixing things that don't work, instead of rewriting working code. And as someone else also said once: 1:1 isn't the solution everywhere. Or if you think so, start dropping arwinss. Of course, don't take that personal, I like everyone ;-). Regards, P. Schweitzer

14 years, 6 months

6
10
0 0

Re: [ros-dev] [ros-diffs] [jimtabor] 50933: [Win32k|User32] - Clarify the meaning and the

by Johannes Anderwald

> Author: jimtabor > Date: Mon Feb 28 06:31:44 2011 > New Revision: 50933 > > URL: http://svn.reactos.org/svn/reactos?rev=50933&view=rev > Log: > [Win32k|User32] > - Clarify the meaning and the use of 0, 1 and 2 for user window regions, wine never did. Noticing patches not corresponding in correctness and understanding, leaving potential crashes in the DCE code, which depend on these types. > - Patch based on Rafal Harabien patch, fixes wine msg SetWindowRgn test, see also bug 5959. This change breaks Winamp 5.601: (ntoskrnl/ps/thread.c:119) PS: Unhandled Kernel Mode Exception Pointers = 0xF86A8568 (ntoskrnl/ps/thread.c:126) Code c0000005 Addr F87D4C3E Info0 00000000 Info1 00000020 Info2 00000000 Info3 00000020 *** Fatal System Error: 0x0000007e (0xC0000005,0xF87D4C3E,0xF86A8A50,0xF86A8690) [7hEntered debugger on embedded INT3 at 0x0008:0x808fd45c.bt Eip: <ntoskrnl.exe:fd45d (lib/rtl/i386/debug_asm.S:39 (RtlpBreakWithStatusInstruction))> Frames: <ntoskrnl.exe:a902 (ntoskrnl/ke/bug.c:1110 (KeBugCheckWithTf@24))> <ntoskrnl.exe:aa4d (ntoskrnl/ke/bug.c:1438 (KeBugCheckEx@20))> <ntoskrnl.exe:ead94 (ntoskrnl/ps/thread.c:129 (PspUnhandledExceptionInSystemThread))> <ntoskrnl.exe:eadaf (ntoskrnl/ps/thread.c:159 (_SEHExcept.39966))> <ntoskrnl.exe:fa9fa (lib/pseh/i386/framebased-gcchack.c:132 (_SEH2FrameHandler))> <ntoskrnl.exe:fcecb (lib/rtl/i386/except_asm.s:183 (RtlpExecuteHandler2))> <ntoskrnl.exe:fce9f (lib/rtl/i386/except_asm.s:150 (RtlpExecuteHandlerForUnwind))> <ntoskrnl.exe:3222 (ntoskrnl/ke/i386/exp.c:938 (KiDispatchException@20))> <ntoskrnl.exe:36bd (ntoskrnl/ke/i386/exp.c:1137 (KiDispatchExceptionFromTrapFrame@28))> <ntoskrnl.exe:6941 (ntoskrnl/include/internal/arch/../i386/ke.h:597 (@KiTrap0EHandler@4))> <ntoskrnl.exe:f7408 (ntoskrnl/ke/i386/trap.s:99 (VfIsVerificationEnabled@8))> <win32k.sys:bac39 (subsystems/win32/win32k/objects/region.c:2104 (@RGNOBJAPI_Lock@8))> <win32k.sys:bb0b3 (subsystems/win32/win32k/objects/region.c:3753 (NtGdiPtInRegion@12))> <win32k.sys:71bbb (subsystems/win32/win32k/ntuser/msgqueue.c:248 (@co_MsqInsertMouseMessage@4))> <win32k.sys:5ded4 (subsystems/win32/win32k/ntuser/cursoricon.c:205 (UserSetCursorPos))> <win32k.sys:66630 (subsystems/win32/win32k/ntuser/input.c:1134 (@IntMouseInput@4))> <win32k.sys:66cca (subsystems/win32/win32k/ntuser/input.c:194 (@ProcessMouseInputData@8))> <win32k.sys:66fbf (subsystems/win32/win32k/ntuser/input.c:308 (MouseThreadMain@4))> <ntoskrnl.exe:eac86 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <ntoskrnl.exe:5936 (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <ntoskrnl.exe:eac22 (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> WBR, Johannes

14 years, 6 months

2
9
0 0

Re: [ros-dev] [ros-diffs] [jgardou] 50991: [NTOSKRNL] - Print supported CPU features. - Simplify detection of non working but claimed SYSENTER support for intel processors - Workaround a virtualbox "feature" : claim that SY...

by Aleksey Bragin

On Mar 7, 2011, at 4:33 PM, jgardou(a)svn.reactos.org wrote: > Author: jgardou > /* Check if the CPU is too old to support SYSENTER */ > - if ((Prcb->CpuType < 6) || > - ((Prcb->CpuType == 6) && (Prcb->CpuStep < 0x0303))) > + if ((Reg[0] & 0x0FFF3FFF) < 0x00000633) > { It was intentionally done over CpuType and CpuStep. Now you criptified it back to a raw Reg[0] value and weird hardcoded constant. Could you please 1) elaborate this change and 2) if you still think it's correct, and if you still tihnk(!) Windows does it same way, then rework it to use Prcb->Cpu* instead of these magic values? Not to say adding a hack for VirtualBox is far from being a beautiful, and would need to be *at least* marked so that it's not forgotten. Thanks, Aleksey Bragin.

14 years, 6 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [jgardou] 50991: [NTOSKRNL] - Print supported CPU features. - Simplify detection of non working but claimed SYSENTER support for intel processors - Workaround a virtualbox "feature" : claim that SY...

by Timo Kreuzer

Am 07.03.2011 14:33, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Mar 7 13:33:10 2011 > New Revision: 50991 > ... > + Reg[3] |= 0x800; > ... > + if ((Reg[0]& 0x0FFF3FFF)< 0x00000633) I'd prefer symbolic constants over these magic numbers. > + > + DPRINT1("Supported CPU features :\n"); > +#define print_supported(kf_value) \ > + if(FeatureBits& kf_value) DPRINT1("\t" #kf_value "\n") > + print_supported(KF_V86_VIS); > + print_supported(KF_RDTSC); > + print_supported(KF_CR4); > + print_supported(KF_CMOV); > + print_supported(KF_GLOBAL_PAGE); > + print_supported(KF_LARGE_PAGE); > + print_supported(KF_MTRR); > + print_supported(KF_CMPXCHG8B); > + print_supported(KF_MMX); > + print_supported(KF_WORKING_PTE); > + print_supported(KF_PAT); > + print_supported(KF_FXSR); > + print_supported(KF_FAST_SYSCALL); > + print_supported(KF_XMMI); > + print_supported(KF_3DNOW); > + print_supported(KF_AMDK6MTRR); > + print_supported(KF_XMMI64); > + print_supported(KF_DTS); > + print_supported(KF_NX_BIT); > + print_supported(KF_NX_DISABLED); > + print_supported(KF_NX_ENABLED); > +#undef print_supported Can we make this more compact please? Like "Supported CPU features: V86_VIS, RDTSC ..." Thanks, Timo

14 years, 6 months

3
2
0 0

[ros-diffs] [jimtabor] 50987: [GDI32] - Remove the old SetDIBBits, it severed us well....

by James Tabor

[GDI32] - Remove the old SetDIBBits, it severed us well.... Hold on to the win32k call. - Tested, Area.exe, wine gdi32 bitmaps test, AbiWord 2.8.6, OOo 2.4.3, SM 2.0.11 and ReactOS applications. - Aimp 2.61.583 (FULL, painted okay), CoolPlayer 219, winamp 0.98d and winamp 2.95 (not FUll). The rest have drawing issue with DIB. See bug 5886. The sound applications have the same issue with revision 50933+ (region unassociated with the DC owner), except CoolPlayer and winamp 0.98d. There is also an issue with vbrun60spX too. I'm not sure how to move on and start compressed bitmaps. Thanks, James

14 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [fireball] 50967: - Revert 47615. Please fix actual sysreg instead of adding inconsistency between 1st, 2nd and 3rd stages debugging connections. This should fix sysreg3's inability to do backtrace...

by Timo Kreuzer

Hmm... I remember I added it to enable the possibility for backtraces in 1st stage for sysreg. Why does it now cause the opposite? And why is there an inconsistency? In 2nd stage there is an option for debug mode, in 1st stage there is none, so using kdserial (which imo is appropriate way to do it, I always select it) as default is as consistent as using "normal" debug, getting the input from the keyboard driver. Just my 0,002 ct/kb Timo Am 04.03.2011 17:57, schrieb fireball(a)svn.reactos.org: > Author: fireball > Date: Fri Mar 4 16:57:56 2011 > New Revision: 50967 > > URL: http://svn.reactos.org/svn/reactos?rev=50967&view=rev > Log: > - Revert 47615. Please fix actual sysreg instead of adding inconsistency between 1st, 2nd and 3rd stages debugging connections. This should fix sysreg3's inability to do backtraces. > See issue #5811 for more details. > > Modified: > trunk/reactos/boot/bootdata/txtsetup.sif > > Modified: trunk/reactos/boot/bootdata/txtsetup.sif > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/txtsetup.sif… > ============================================================================== > --- trunk/reactos/boot/bootdata/txtsetup.sif [iso-8859-1] (original) > +++ trunk/reactos/boot/bootdata/txtsetup.sif [iso-8859-1] Fri Mar 4 16:57:56 2011 > @@ -59,7 +59,7 @@ > [SetupData] > DefaultPath = \ReactOS > OsLoadOptions = "/NOGUIBOOT /NODEBUG" > -DbgOsLoadOptions = "/NOGUIBOOT /DEBUGPORT=COM1 /FIRSTCHANCE /KDSERIAL" > +DbgOsLoadOptions = "/NOGUIBOOT /DEBUGPORT=COM1 /FIRSTCHANCE" > ;OsLoadOptions = "/NOGUIBOOT /DEBUGPORT=SCREEN" > ;OsLoadOptions = "/NOGUIBOOT /DEBUGPORT=BOCHS" > > > >

14 years, 6 months

3
5
0 0

DHCP not working?

by Javier Agustìn Fernàndez Arroyo

Hi all, im testing ROS right now in real hardware... As i cannot log into IRC (via webchat.freenode.net, i cant even reach the page, i dont know why), let me post this in ML The think is, i have installed RealTek´s official driver for the NIC, and hardware is recognized... but, dhcp dont get any IP... any idea? log is attached btw, in the log there are many errors ("xxxx failed") about ndis.......

14 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 50942: [WIN32K] Do raster operation on 4 bytes instead of only 3. Fixes ... maybe noone has noticed yet ; -)

by Colin Finck

tkreuzer(a)svn.reactos.org wrote: > Do raster operation on 4 bytes instead of only 3. Quoting jgardou's commit before: > - When applying raster operation, do so only on 24 bits, we don't > support alpha channel in win32k I have no idea about DIB code, but just from the commit message I presume that this change to 24 bits has happened deliberately. - Colin

14 years, 6 months

3
2
0 0

Heap corruption detector is ready

by Aleksey Bragin

Hi all, I finished implementing main features of a special mechanism for monitoring uesrmode heap allocations in ReactOS. This mechanism is called Debug Page Heap, after the very similar mechanism present in recent versions of Microsoft Windows NT. Explaining the heap manager, the "usual" heap allocator (the one I also developed earlier) also contains a heap corruption detector, but it works post-factum, only after the respective block is freed its patterns are checked (if such heap flags are specified) and if they are damaged the block is reported. This makes debugging problematic, because a lot of code is executed between the moment the corruption occured and moment when the corrupted block is freed. Also it may be so that block's patterns are untouched, but internal heap structures are damaged. The usual heap allocator won't be able to catch this, but will crash with undetermined exception. Debug page heap (DPH) comes to solve this problem. Simply speaking it guards every block with a no-access page either after or before the block, so that when a badly written app wants to write beyond the allowed area, an exception occurs showing exactly the faulty instruction. Not so simply speaking, it's a rather complicated debugging tool with abilities to catch access-after-free cases also when they happen, and do some other nice tricks too. If you want to read more about it, look for "debug page heap" in MSDN and also visit URLs specified as references in rtl/heappage.c. How to use it? The best way is to use Microsoft's utility gflags.exe which is part of the Debugging package of WDK. To make long things short, just copy gflags.exe to C:\ReactOS\system32, boot your ReactOS installation, fire up cmd prompt and type: gflags /p /enable name.exe /full Now, when you run your app called name.exe, it will use the DPH heap allocator. Detailed information about gflags.exe could be found here: http:// msdn.microsoft.com/en-us/library/ff549557%28VS.85%29.aspx Also, I suggest looking in MSDN for page heap explanation (I provided some references in heappage.c too). Have fun! Aleksey.

14 years, 6 months

1
0
0 0

ReactOS Urgent Meeting

by Colin Finck

ReactOS Urgent Meeting Preamble ========= The following people which are generally considered as ReactOS-related people have called for an urgent project meeting. They agree with the meeting agenda and the rules for this meeting: * Giannis Adamopoulos * Johannes Anderwald * Maciej Białas * Aleksey Bragin * Colin Finck * Ziliang Guo * Kamil Hornicek * Amine Khaldi * Timo Kreuzer * Victor Martinez * Roel Messiant * Sylvain Petreolle * Pierre Schweitzer * Olaf Siejka * James Tabor * Art Yerkes As we have not established any general rules for meetings yet, we consider these demands enough to justify the need for such an urgent meeting. Based on the experiences Colin has from formal ReactOS Deutschland e.V. foundation meetings, we need at least a discussion leader and a minute taker to get an organized meeting done over IRC. General Information ==================== * Date and Time: Tuesday, 22nd February, 2011 - 20:00 UTC * Place: #reactos-meeting on Freenode * Meeting leader: Colin Finck * Minute taker: Amine Khaldi * Allowed Participants The following people are allowed to participate in the discussion on that channel. This list is taken from the people which were recently active on the #reactos-dev IRC channel. Others are not included as they don’t have a chance to know about the recent developments. If you consider yourself a ReactOS-related person, you may still ask Colin Finck to put you on this list. Apart from this, everybody may join as an observer. o Giannis Adamopoulos (smiley1_) o Johannes Anderwald (janderwald) o Maciej Białas (niski) o Aleksey Bragin (abragin) o Colin Finck (Colin_Finck) o Danny Götte (dangerground) o Ziliang Guo (ZWabbit) o Amine Khaldi (AmineKhaldi) o Timo Kreuzer (rosdude) o Matthias Kupfer (Collibri) o Victor Martinez (vicmarcal) o Roel Messiant (Mephisto) o Ged Murphy (GedMurphy) o Sylvain Petreolle (Usurp) o Daniel Reimer (dreimer) o Pierre Schweitzer (HeisSpiter) o Samuel Serapion (encoded) o Olaf Siejka (Caemyr) o James Tabor (jimtabor) o Art Yerkes (arty) Meeting Agenda =============== 1. Agree on a preliminary definition for the term "ReactOS Team Member". To create a basis for the next regular meeting, we need to know who may participate and who may not. As we need to focus on the release right now, this definition should only be preliminary and is subject to change in a future meeting. Some participants will present proposals for such a definition. 2. Establish regular meetings every month. This is the only chance to ensure discussions among a broad range of ReactOS Team members with binding decisions. These meetings should follow the rules of typical meetings, including meeting leaders and minute takers. In contrast to this meeting, all team members should be able to participate. Minutes should also be published on the website. Such regular meetings should begin after CLT2011 (after 20th March) due to the time it takes to prepare this event. 3. Set up binding 0.3.13 Release Plans. The CLT2011 event is a big PR chance for a new ReactOS release, so we should look forward to get a release ready by then. This point includes: 1. Getting information about the most annoying bugs and regressions. Victor Martinez and Olaf Siejka will report on this. 2. Building teams to care about each bug. As soon as a bug is fixed, a team has to report back about this to one of the release engineers. They will then add you to another team. Of course, you may also suggest stuff you want to work on afterwards. 3. Setting deadlines for the bugs. We need to determine what bugs can be realistically fixed in the given time. If a bug is not fixed by then, the appropriate team has to report back about this to one of the release engineers. They are then responsible for finding a solution. We believe that other topics, especially the ones discussed in the "ReactOS Reaction" document should be covered in the first regular meeting, so that we can focus on 0.3.13 right now.

14 years, 6 months

2
4
0 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 50867: [KERNEL32] Don't make GetBinaryTypeA() rely on Wine's strings conversions functions

by Aleksey Bragin

This commit sounds like FilenameA2W is some evil we should get rid of as soon as possible, otherwise it takes over the world. In fact, FilenameA2W is the same stuff which you just unwrapped, so instead of 1 line, there are 20 lines now. The only thing would be setting correct LastError, but for some reason I think Wine did it right too (they have tests). In my opinion, it makes sense to either rewrite the buggy code (buggy being really buggy or questionable origin, if code comes from Wine it doesn't automatically mean it's buggy), or let the shared code be shared and just update it from the latest Wine. WBR, Aleksey Bragin. On Feb 22, 2011, at 9:43 PM, pschweitzer(a)svn.reactos.org wrote: > Author: pschweitzer > Date: Tue Feb 22 18:43:38 2011 > New Revision: 50867 > > URL: http://svn.reactos.org/svn/reactos?rev=50867&view=rev > Log: > [KERNEL32] > Don't make GetBinaryTypeA() rely on Wine's strings conversions > functions > > Modified: > trunk/reactos/dll/win32/kernel32/file/bintype.c > > Modified: trunk/reactos/dll/win32/kernel32/file/bintype.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/ > kernel32/file/bintype.c?rev=50867&r1=50866&r2=50867&view=diff > ====================================================================== > ======== > --- trunk/reactos/dll/win32/kernel32/file/bintype.c [iso-8859-1] > (original) > +++ trunk/reactos/dll/win32/kernel32/file/bintype.c [iso-8859-1] > Tue Feb 22 18:43:38 2011 > @@ -301,23 +301,43 @@ > */ > BOOL > WINAPI > -GetBinaryTypeA ( > - LPCSTR lpApplicationName, > - LPDWORD lpBinaryType > - ) > +GetBinaryTypeA(IN LPCSTR lpApplicationName, > + OUT LPDWORD lpBinaryType) > { > - PWCHAR ApplicationNameW; > - > - if(!lpApplicationName || !lpBinaryType) > - { > - SetLastError(ERROR_INVALID_PARAMETER); > - return FALSE; > - } > - > - if (!(ApplicationNameW = FilenameA2W(lpApplicationName, FALSE))) > - return FALSE; > - > - return GetBinaryTypeW(ApplicationNameW, lpBinaryType); > + ANSI_STRING ApplicationNameString; > + UNICODE_STRING ApplicationNameW; > + BOOL StringAllocated = FALSE, Result; > + NTSTATUS Status; > + > + RtlInitAnsiString(&ApplicationNameString, lpApplicationName); > + > + if (ApplicationNameString.Length * sizeof(WCHAR) >= > NtCurrentTeb()->StaticUnicodeString.MaximumLength) > + { > + StringAllocated = TRUE; > + Status = RtlAnsiStringToUnicodeString(&ApplicationNameW, > &ApplicationNameString, TRUE); > + } > + else > + { > + Status = RtlAnsiStringToUnicodeString(&(NtCurrentTeb()- > >StaticUnicodeString), &ApplicationNameString, FALSE); > + } > + > + if (!NT_SUCCESS(Status)) > + { > + BaseSetLastNTError(Status); > + return FALSE; > + } > + > + if (StringAllocated) > + { > + Result = GetBinaryTypeW(ApplicationNameW.Buffer, > lpBinaryType); > + RtlFreeUnicodeString(&ApplicationNameW); > + } > + else > + { > + Result = GetBinaryTypeW(NtCurrentTeb()- > >StaticUnicodeString.Buffer, lpBinaryType); > + } > + > + return Result; > } > > /* EOF */ > >

14 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [akhaldi] 50854: [RTL] - Silence this dprint. It's flooding the

by Pierre Schweitzer

Hi, this debug wasn't supposed to be silent as it highlights a quite crappy situation in ReactOS. And that's even what one would call: "a hack". That way, you could also silence IopParseDevice hack debug... At least, you could have asked the author, I'm not that unreachable ;-). Regards, P. Schweitzer

14 years, 6 months

4
4
0 0

CallOneParam? 0x10? sometimes 0x20

by James Tabor

I noticed this everywhere, (subsystems/win32/win32k/objects/gdiobj.c:249) GDIOBJ_LockObj: Attempted to lock object 0x10064, wrong reuse counter (Handle: 0x0, Entry: 0x8) (subsystems/win32/win32k/objects/dclife.c:726) Could not lock source DC 00010064 (subsystems/win32/win32k/ntuser/simplecall.c:349) Calling invalid routine number 0x10 in NtUserCallOneParam(), Param=0x31 CallOneParam? Looks like a stack issue.

14 years, 6 months

2
2
0 0

Buidlbot (& trunk?) broken

by Pierre Schweitzer

Hi, it seems that recent changes lead buildbot to brokenness status. It's looping forever on a backtrace. Crash occurs in user32_winetest win. Before the end: win.c:1028: HCBT_DESTROYWND: hwnd 000A04E6 win.c:1058: previous shell window: 00020098 (subsystems/win32/win32k/ntuser/window.c:2500) Destroying the ShellWindow! (subsystems/win32/win32k/ntuser/message.c:1629) SendNotifyMessage: Failed in Broadcast! [7hEntered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0x47534D59 could not be written: Page not present. kdb:> bt Eip: <win32k.sys:7125d (include/ddk/wdm.h:8188 (@MsqCleanupMessageQueue@4))> Frames: <win32k.sys:71438 (subsystems/win32/win32k/ntuser/msgqueue.c:1575 (@MsqDestroyMessageQueue@4))> <win32k.sys:400a2 (subsystems/win32/win32k/main/dllmain.c:346 (Win32kThreadCallback@8))> <ntoskrnl.exe:dfc5d (ntoskrnl/ps/kill.c:693 (PspExitThread@4))> <ntoskrnl.exe:e002c (ntoskrnl/ps/kill.c:890 (PsExitSpecialApc@20))> <ntoskrnl.exe:9004 (ntoskrnl/ke/apc.c:471 (KiDeliverApc@12))> <ntoskrnl.exe:70be (ntoskrnl/include/internal/arch/../i386/ke.h:690 (@KiServiceExit@8))> <win32k.sys:e6a73 (subsystems/win32/win32k/ntuser/menu.c:0 (@IntCreateMenu@8))> <ff8848b8> <b0465eb0> <win32k.sys:e6a73 (subsystems/win32/win32k/ntuser/menu.c:0 (@IntCreateMenu@8))> <win32k.sys:e7153 (/mnt/ramdisk/buildbot/debug/obj/include/psdk/oleidl.h:0 (_SEH2FrameHandler))> <b0467604> <b04675cc> <b04667cc> <b0466794> <b0290874> <b029083c> <b04504ac> <b0450474> <b0464634> Regards, P. Schweitzer

14 years, 6 months

1
2
0 0

Releasing

by Aleksey Bragin

Hi, recently amount of new features added to the trunk decreased, and there were quite a lot of bugfixes coming in. In my opinion, it is a very good time for a release. After release is branched, it would be possible to sync wine shared code and continue with other changes. If there are no objections, let's start the work right away. Testers being the first team working, and Colin - when/if you have time for this release? WBR, Aleksey Bragin.

14 years, 7 months

10
17
0 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 50616: [RTL] Minor code changes to RTL (one would call them "optimisation"). Added some missing paged code. Plus added useful asserts (used to catch r50615 bug!)

by Timo Kreuzer

You wrote it was an optimization, but it rather looks like a functional change ("+ sizeof(WCHAR)"). is that intended? wdm:8428 #define RtlAnsiStringToUnicodeSize(String) ( \ NLS_MB_CODE_PAGE_TAG ? \ RtlxAnsiStringToUnicodeSize(String) : \ ((String)->Length + sizeof(ANSI_NULL)) * sizeof(WCHAR) \ ) wdm:8916 #define RtlUnicodeStringToAnsiSize(String) ( \ NLS_MB_CODE_PAGE_TAG ? \ RtlxUnicodeStringToAnsiSize(String) : \ ((String)->Length + sizeof(UNICODE_NULL)) / sizeof(WCHAR) \ ) Am 08.02.2011 00:23, schrieb pschweitzer(a)svn.reactos.org: > Author: pschweitzer > Date: Mon Feb 7 23:23:33 2011 > New Revision: 50616 > > URL: http://svn.reactos.org/svn/reactos?rev=50616&view=rev > Log: > [RTL] > Minor code changes to RTL (one would call them "optimisation"). Added some missing paged code. > Plus added useful asserts (used to catch r50615 bug!) > ... > - Length = RtlAnsiStringToUnicodeSize(AnsiSource); > + if (NlsMbCodePageTag == FALSE) > + { > + Length = AnsiSource->Length * 2 + sizeof(WCHAR); > + } > + else > + { > + Length = RtlxAnsiStringToUnicodeSize(AnsiSource); > + } ... > > - Length = RtlUnicodeStringToAnsiSize(UniSource); > + ASSERT(!(UniSource->Length& 1)); > + > + if (NlsMbCodePageTag == FALSE) > + { > + Length = (UniSource->Length + sizeof(WCHAR)) / sizeof(WCHAR); > + } > + else > + { > + Length = RtlxUnicodeStringToAnsiSize(UniSource); > + } > if (Length> MAXUSHORT) return STATUS_INVALID_PARAMETER_2;

14 years, 7 months

1
0
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