Ros-dev February 2011

ros-dev@reactos.org

14 participants
12 discussions

Sign driver for 64 Bit Build of Virtual Floppy Drive for Windows?

by Carsten Krüger

Hi, I know that for some open source projects React OS sign's windows drivers. Could you please sign the driver for virtual floppy drive? Motivation: Virtual Floppy drive is very helpfull, for example take freedos floppy image, include Samsung SpinPoint F4 EcoGreen HD204UI firmware update into the image and put it with unetbootin on usb stick. Problem: virtual floppy drive didn't run on windows 7 x64 because the need of driver signing. Homepage: http://vfd.sourceforge.net/ Description: >This is a virtual floppy drive for Windows NT / 2000 / XP developed by Ken Kato >(Reported to work also on 2003 Server and Vista). <-- and windows 7 x86, too. > >You can mount a floppy image file as a virtual floppy drive and directly access the contents -- >view, edit, rename, delete or create files on a virtual floppy, format a virtual floppy, >launch a program on a virtual floppy... almost anything you can do with a real floppy. vfdwin x64 driver build (unsigned) from "critical0" http://sourceforge.net/projects/vfd/files/2.1%20(February%2006%2C%202008)/v… vfdwin x64 driver build (unsigned) from "Igor Levicki" http://levicki.net/downloads/sendfile.php?path=vfd_x64/vfd_x64.zip Discussion about the different versions: http://levicki.net/articles/stories/2007/08/17/The_story_of_the_vfdwin_21_6… greetings Carsten

13 years, 9 months

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

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

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

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

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

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

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

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

Re: [ros-dev] [ros-diffs] [pschweitzer] 50612: [NTOSKRNL/PPC] Fix the fix, spotted by "ThFabba" on IRC

by Timo Kreuzer

Under "normal conditions" sizeof of an array covers the whole array. is this different for function paramters? Am 06.02.2011 14:50, schrieb pschweitzer(a)svn.reactos.org: > Author: pschweitzer > Date: Sun Feb 6 13:50:57 2011 > New Revision: 50612 > > URL: http://svn.reactos.org/svn/reactos?rev=50612&view=rev > Log: > [NTOSKRNL/PPC] > Fix the fix, spotted by "ThFabba" on IRC > > Modified: > trunk/reactos/ntoskrnl/ke/powerpc/cpu.c > > Modified: trunk/reactos/ntoskrnl/ke/powerpc/cpu.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/powerpc/cpu.c?… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/powerpc/cpu.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/powerpc/cpu.c [iso-8859-1] Sun Feb 6 13:50:57 2011 > @@ -44,7 +44,7 @@ > CPUID(IN ULONG CpuInfo[4], > IN ULONG InfoType) > { > - RtlZeroMemory(CpuInfo, sizeof(CpuInfo) * sizeof(ULONG)); > + RtlZeroMemory(CpuInfo, 4 * sizeof(ULONG)); > } > > VOID > > >

14 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev February 2011