- Ros-dev - ReactOS.org

by Colin Finck

https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-bac… I didn't expect Microsoft to switch to Git sooner than us..

8 years, 2 months

6
16
0 0

Re: [ros-dev] Microsoft switched to Git

by Brandin L Claar

Just move everything to GitHub: https://github.com/blog/966-improved-subversion-client-support -brandin > On Feb 15, 2017, at 06:32, ros-dev-request(a)reactos.org wrote: > > Send Ros-dev mailing list submissions to > ros-dev(a)reactos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.reactos.org/mailman/listinfo/ros-dev > or, via email, send a message with subject or body 'help' to > ros-dev-request(a)reactos.org > > You can reach the person managing the list at > ros-dev-owner(a)reactos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ros-dev digest..." > > > Today's Topics: > > 1. Re: Microsoft switched to Git (Ged Murphy) > 2. Re: Microsoft switched to Git (David Quintana (gigaherz)) > 3. Re: Microsoft switched to Git (Colin Finck) > 4. Re: Microsoft switched to Git (David Quintana (gigaherz)) > 5. Re: Microsoft switched to Git (Colin Finck) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 Feb 2017 11:04:52 -0000 > From: "Ged Murphy" <gedmurphy.maillists(a)gmail.com> > To: "'ReactOS Development List'" <ros-dev(a)reactos.org> > Subject: Re: [ros-dev] Microsoft switched to Git > Message-ID: <004701d2877b$55983010$00c89030$(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > I think the easiest path is to switch to a centralized style model using git. > That is, we have a master copy (aka trunk) that gives the feel of our existing model. That would allow devs that prefer SVN to mostly continue working as before, and give the devs who want to use git in a more traditional way the ability to branch off and work in a git style manner, then sync their changes back into 'trunk'. > > > -----Original Message----- > From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of Colin Finck > Sent: 15 February 2017 10:53 > To: ros-dev(a)reactos.org > Subject: Re: [ros-dev] Microsoft switched to Git > >> Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz): >> The number doesn't matter. The ReactOS project can't afford to lost >> any long-time members. Git would be a benefit for all of us, but it >> has to be a benefit for ALL of us. > > Let's not forget: > > - Part of the reasons developers had against Git may have been resolved by now. > - Part of the problem may be that "Git is so different" to some devs, but I think this can be resolved by a detailed Wiki article showing how to do the same thing in SVN and Git. We already wrote such articles for TortoiseSVN after all! > - And finally, we first need a plan for a Git move that doesn't suck. We tried SubGit and it failed for us. Then there is the "Merge workflow", which is supported very well by all tools, but creates a lot of parallel history. The "Rebase workflow" is more like what SVN does (keeping a linear history), but no idea how to enforce that with TortoiseGit. > > I think if a team could look after these things and help moving each and every developer towards Git, it may even be doable for us. > > Cheers, > > Colin > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > > > > ------------------------------ > > Message: 2 > Date: Wed, 15 Feb 2017 12:18:40 +0100 > From: "David Quintana (gigaherz)" <gigaherz(a)gmail.com> > To: ReactOS Development List <ros-dev(a)reactos.org> > Subject: Re: [ros-dev] Microsoft switched to Git > Message-ID: > <CADD3+ruo18pQos1QO+jCHg5V2-hyrrjSZ7Va1pfgm+tprDbDZw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > My belief is that the best path would be: > > Phase 0: This is how we are now. We have SVN master (trunk), and a > read-only git mirror, and a semi-updated github mirror for when a > contributor really wants to submit git PRs. > > Phase 1: Switch to using Git with PRs for submitting patches (Github's PR > system is really really nice these days, but other solutions exist). Setup > a SVN mirror "bot" that creates one svn commit for each push/merge detected > in the master branch, and allows the buildbots to continue working as they > do now. > > This would allow the existing svn-patch workflow to continue working, but > commits on svn wouldn't be allowed anymore. Developers are expected to at > least TRY to learn to use git (it's not that hard! I promise!). > > Phase 2: We switch the buildbots and testbots to pull from git, enable > testbot access for git PRs (such as with a github bot that responds to > "@rosbot runtest" or similar). The SVN mirror remains, for archival > purposes, but git commits aren't merged so regularly. Release tags/branches > can still be published through SVN, for ease of access. > > Phase 3: Everyone ends up agreeing that maintaining the svn mirror is no > longer worth the effort. > > Of course, anything like this will only happen if the entire team agrees to > it. > > On 15 February 2017 at 12:04, Ged Murphy <gedmurphy.maillists(a)gmail.com> > wrote: > >> I think the easiest path is to switch to a centralized style model using >> git. >> That is, we have a master copy (aka trunk) that gives the feel of our >> existing model. That would allow devs that prefer SVN to mostly continue >> working as before, and give the devs who want to use git in a more >> traditional way the ability to branch off and work in a git style manner, >> then sync their changes back into 'trunk'. >> >> >> -----Original Message----- >> From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of Colin >> Finck >> Sent: 15 February 2017 10:53 >> To: ros-dev(a)reactos.org >> Subject: Re: [ros-dev] Microsoft switched to Git >> >>> Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz): >>> The number doesn't matter. The ReactOS project can't afford to lost >>> any long-time members. Git would be a benefit for all of us, but it >>> has to be a benefit for ALL of us. >> >> Let's not forget: >> >> - Part of the reasons developers had against Git may have been resolved by >> now. >> - Part of the problem may be that "Git is so different" to some devs, but >> I think this can be resolved by a detailed Wiki article showing how to do >> the same thing in SVN and Git. We already wrote such articles for >> TortoiseSVN after all! >> - And finally, we first need a plan for a Git move that doesn't suck. We >> tried SubGit and it failed for us. Then there is the "Merge workflow", >> which is supported very well by all tools, but creates a lot of parallel >> history. The "Rebase workflow" is more like what SVN does (keeping a linear >> history), but no idea how to enforce that with TortoiseGit. >> >> I think if a team could look after these things and help moving each and >> every developer towards Git, it may even be doable for us. >> >> Cheers, >> >> Colin >> >> _______________________________________________ >> 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 >> >

8 years, 2 months

6
7
0 0

Re: [ros-dev] Microsoft switched to Git

by Alex Ionescu

How about I leave if we DON'T switch to Git? I fucking hate SVN now (read my e-mail from 8 years ago on this topic, lol!). Best regards, Alex Ionescu On Wed, Feb 15, 2017 at 3:32 AM, Colin Finck <colin(a)reactos.org> wrote: > Am 15.02.2017 um 12:18 schrieb David Quintana (gigaherz): >> Setup a SVN mirror "bot" that creates one svn commit for each push/merge >> detected in the master branch, and allows the buildbots to continue >> working as they do now. > > Let's not have a Git repository with a parallel SVN mirror again. SubGit > tried to accomplish this as a professional solution and it failed for us. > > There is no reason to take extra care of the Buildslaves at all. > The same infra people, who would do the switch to Git, could also change > the Buildslaves to use Git instead of SVN in the course of that. > > > - Colin > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

8 years, 2 months

1
0
0 0

(no subject)

by katahiromz .

Microsoft will use GVFS (Git Virtual File System) to manage their huge Git repository.

8 years, 2 months

1
0
0 0

FishEye DB being rebuilt

by Colin Finck

Hi all! As this is taking longer than expected, I should give a notice: In an attempt to restart hanging FishEye yet another time yesterday, its stored database of the reactos SVN repository was corrupted... I'm rebuilding it since yesterday evening, but parsing all the diffs is a long process. Can't give any ETA yet. So far, only commit information without diff is available at code.reactos.org. Cheers, Colin

8 years, 2 months

4
7
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 73795: [NTOSKRNL] Implement IopGetDeviceRelations().

by Thomas Faber

On 2017-02-13 23:38, ekohl(a)svn.reactos.org wrote: > + _SEH2_TRY > + { > + Relations = RelationsData->Relations; > + BufferSize = RelationsData->BufferSize; > + Buffer = RelationsData->Buffer; > + > + ProbeForWrite(RelationsData->Buffer, > + RelationsData->BufferSize, > + sizeof(CHAR)); > + } You need to use the local 'Buffer' and 'BufferSize' variables in the probe or you get a race condition. > + Status = IopInitiatePnpIrp(DeviceObject, > + &IoStatusBlock, > + IRP_MN_QUERY_DEVICE_RELATIONS, > + &Stack); > + if (!NT_SUCCESS(Status) || Status == STATUS_PENDING) > + { > + DPRINT1("IopInitiatePnpIrp() failed (Status 0x%08lx)\n", Status); > + goto done; > + } Failing on STATUS_PENDING seems broken. IoStatusBlock will go out of scope and the DeviceRelations set by the driver will be leaked. > + if (RequiredSize > 0) > + RequiredSize += sizeof(WCHAR); Not sure I understand the >0 condition. Best, Thomas

8 years, 2 months

1
0
0 0

UEFI Bootmgr vs. FreeLdr

by Colin Finck

Hi all! Seeing the recent UEFI Bootmgr work in trunk, I was wondering about its design. Will that be a UEFI-only boot loader or eventually replace/merge with FreeLdr to provide a common boot loader for BIOS and UEFI systems? Will it simply follow all design principles of the NT6+ boot loader or also implement some own ideas or take over those from FreeLdr? For instance, I totally like FreeLdr's configuration through INI files and would prefer that any day over NT6+ BCD registry hives. Cheers, Colin

8 years, 2 months

3
2
0 0

Google Summer of Code 2017

by Colin Finck

Hi all! Google Summer of Code 2017 is fast approaching, with February 9 being the deadline for projects to apply. With our record of successfully completing all 4 ideas (msahci, NTFS, lwIP, USB) last year, we should definitely apply again. Aleksey and Amine have already begun filling out the application form. Based on the 2016 ideas Wiki page, we have also created a new ideas page at https://reactos.org/wiki/Google_Summer_of_Code_2017_Ideas Please share your thoughts on these and add anything that's missing. What we now need are possible mentors. Who would be available for this? Cheers, Colin

8 years, 2 months

4
4
0 0

About JIRA Account

by JasonQSY

Hi, I’m interested in ros dev now and it seems that fixing small bugs could be a good start. Could I have a JIRA account and have a look at the issues? Or any suggestions about jobs could be done by a newcomer? - JasonQSY

8 years, 2 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [tfaber] 73631: [0.4.4] - Mask WndProc exceptions CORE-11915

by Alex Ionescu

In Windows, this is actually part of the AppCompat database. there's a flag in tagWND that enables/disables this behavior. Best regards, Alex Ionescu On Mon, Jan 30, 2017 at 3:35 AM, <tfaber(a)svn.reactos.org> wrote: > Author: tfaber > Date: Mon Jan 30 11:35:05 2017 > New Revision: 73631 > > URL: http://svn.reactos.org/svn/reactos?rev=73631&view=rev > Log: > [0.4.4] > - Mask WndProc exceptions > CORE-11915 > > Modified: > branches/ros-branch-0_4_4/reactos/win32ss/user/user32/windows/message.c > > Modified: branches/ros-branch-0_4_4/reactos/win32ss/user/user32/windows/message.c > URL: http://svn.reactos.org/svn/reactos/branches/ros-branch-0_4_4/reactos/win32s… > ============================================================================== > --- branches/ros-branch-0_4_4/reactos/win32ss/user/user32/windows/message.c [iso-8859-1] (original) > +++ branches/ros-branch-0_4_4/reactos/win32ss/user/user32/windows/message.c [iso-8859-1] Mon Jan 30 11:35:05 2017 > @@ -1464,20 +1464,15 @@ > > if (PreResult) goto Exit; > > - if (!Dialog) > - Result = CALL_EXTERN_WNDPROC(WndProc, AnsiMsg.hwnd, AnsiMsg.message, AnsiMsg.wParam, AnsiMsg.lParam); > - else > - { > _SEH2_TRY > { > Result = CALL_EXTERN_WNDPROC(WndProc, AnsiMsg.hwnd, AnsiMsg.message, AnsiMsg.wParam, AnsiMsg.lParam); > } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > { > - ERR("Exception Dialog Ansi %p Msg %d pti %p Wndpti %p\n",WndProc,Msg,GetW32ThreadInfo(),pWnd->head.pti); > + ERR("Exception when calling Ansi WndProc %p Msg %d pti %p Wndpti %p\n",WndProc,Msg,GetW32ThreadInfo(),pWnd->head.pti); > } > _SEH2_END; > - } > > if (Hook && MsgOverride) > { > @@ -1518,20 +1513,15 @@ > > if (PreResult) goto Exit; > > - if (!Dialog) > - Result = CALL_EXTERN_WNDPROC(WndProc, hWnd, Msg, wParam, lParam); > - else > - { > _SEH2_TRY > { > Result = CALL_EXTERN_WNDPROC(WndProc, hWnd, Msg, wParam, lParam); > } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > { > - ERR("Exception Dialog unicode %p Msg %d pti %p Wndpti %p\n",WndProc, Msg,GetW32ThreadInfo(),pWnd->head.pti); > + ERR("Exception when calling unicode WndProc %p Msg %d pti %p Wndpti %p\n",WndProc, Msg,GetW32ThreadInfo(),pWnd->head.pti); > } > _SEH2_END; > - } > > if (Hook && MsgOverride) > { > @@ -1611,20 +1601,15 @@ > > if (PreResult) goto Exit; > > - if (!Dialog) > - Result = CALL_EXTERN_WNDPROC(WndProc, hWnd, Msg, wParam, lParam); > - else > - { > _SEH2_TRY > { > Result = CALL_EXTERN_WNDPROC(WndProc, hWnd, Msg, wParam, lParam); > } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > { > - ERR("Exception Dialog Ansi %p Msg %d pti %p Wndpti %p\n",WndProc,Msg,GetW32ThreadInfo(),pWnd->head.pti); > + ERR("Exception when calling Ansi WndProc %p Msg %d pti %p Wndpti %p\n",WndProc,Msg,GetW32ThreadInfo(),pWnd->head.pti); > } > _SEH2_END; > - } > > if (Hook && MsgOverride) > { > @@ -1672,20 +1657,15 @@ > > if (PreResult) goto Exit; > > - if (!Dialog) > - Result = CALL_EXTERN_WNDPROC(WndProc, UnicodeMsg.hwnd, UnicodeMsg.message, UnicodeMsg.wParam, UnicodeMsg.lParam); > - else > - { > _SEH2_TRY > { > Result = CALL_EXTERN_WNDPROC(WndProc, UnicodeMsg.hwnd, UnicodeMsg.message, UnicodeMsg.wParam, UnicodeMsg.lParam); > } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > { > - ERR("Exception Dialog unicode %p Msg %d pti %p Wndpti %p\n",WndProc, Msg,GetW32ThreadInfo(),pWnd->head.pti); > + ERR("Exception when calling unicode WndProc %p Msg %d pti %p Wndpti %p\n",WndProc, Msg,GetW32ThreadInfo(),pWnd->head.pti); > } > _SEH2_END; > - } > > if (Hook && MsgOverride) > { > >

8 years, 2 months

1
0
0 0

Re: [ros-dev] Bootlogos for FOSDEM (was: "RE: FOSDEM 2017 - It's happening!")

by Hermès BÉLUSCA-MAÏTO

Hi ! After this successful poll, the winner bootlogo is without doubt the (d) version :-) I have committed it here : https://svn.reactos.org/svn/reactos?view=revision <https://svn.reactos.org/svn/reactos?view=revision&revision=73639> &revision=73639 This is the file “1.bmp”. As the bootlogo and the other boot images are 16-colour (palette) bitmaps, I had to adjust the palette of the other ones too (because they are occasionally rendered together). Cheers, Hermès De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Daniel Franzini Envoyé : lundi 30 janvier 2017 17:20 À : ReactOS Development List Objet : Re: [ros-dev] Bootlogos for FOSDEM (was: "RE: FOSDEM 2017 - It's happening!") I'd go with (h) first then (d) second. I agree with David but I prefer the (h) version of the logo. P.S.: I don't think that my opinion matters that much. On Mon, Jan 30, 2017 at 2:08 PM, David Quintana (gigaherz) <gigaherz(a)gmail.com> wrote: Ah I just realised I never wrote which version I prefer: d. Reason: it's more symmetric -- fills in the empty space to the right, corresponding to the copyright notice on the left. On 30 January 2017 at 16:40, Yaroslav Veremenko <yaroslav(a)veremenko.info> wrote: I like c/d (preferably more d). Yaroslav -----Original Message----- From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of Hermes BELUSCA-MAITO Sent: Saturday, January 28, 2017 8:29 AM To: 'ReactOS Development List' <ros-dev(a)reactos.org> Subject: [ros-dev] Bootlogos for FOSDEM (was: "RE: FOSDEM 2017 - It's happening!") Hello everyone, Upon an idea by Jared Smudde I modified a bit the ReactOS bootlogo to incorporate in addition the FOSDEM logo in it. See http://polariton.ad-l.ink/6WhjqNRrM/image.png or the attached file. I have done several versions and I would like to hear what you think from them (if possible, make a choice). Regards, Hermès -----Message d'origine----- De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Colin Finck Envoyé : jeudi 26 janvier 2017 00:16 À : 'ReactOS Development List' Objet : [ros-dev] FOSDEM 2017 - It's happening! Hi all! Hermès and me have just decided to go to FOSDEM this year. Which is a really good idea considering that we have a booth to staff there ;) Planning is currently happening at https://docs.google.com/document/d/1ofYUc7j0XwDH9SmNlGzNZlO8jOGhoPUn7KTRcFm… Just request access if you're a ReactOS member and like to add or comment stuff there. Hermès will be preparing an ISO in the upcoming days. Please test current trunk to see if any last minute fixes need to go there. If you have ideas what cool apps we shall show at FOSDEM, please also share them here. We will go with burning and giving away CDs again (hopefully the last time before USBs do it). I hope that this definite plan will also motivate others to join us or visit our booth! :) Cheers, Colin _______________________________________________ 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 _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Daniel "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth) "Yes, technogeeks can be funny, even if only to each other." (http://www.boogieonline.com/revolution/science/humor/)" "Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'')

8 years, 2 months

1
0
0 0

Re: [ros-dev] FOSDEM 2017 - It's happening!

by hermes.belusca＠sfr.fr

We use FreeLDR for the RAM booting, which loads in RAM an ISO (not a HDD image yet). For the LiveCD for example, the following lines can be added into freeldr.ini: [Operating Systems] ... LiveCD_RamDisk="LiveCD in RAM" ... [LiveCD_RamDisk] BootType=Windows2003 SystemPath=ramdisk(0)\reactos Options=/MININT /RDPATH=livecd\livecd.iso /RDEXPORTASCD FreeLdr will load the "livecd\livecd.iso" file from the boot drive (a USB key for example...) (the switch '/RDEXPORTASCD' explicitely specifies that the file is loaded as an ISO image, with read-only access, etc...). Then, "ramdisk(0)\reactos" specifies that the kernel etc... will be loaded from the "reactos" directory inside the root directory constituted by the ramdisk, once the ramdisk is loaded. Regards, Hermès

8 years, 2 months

2
1
0 0

Re: [ros-dev] Google Summer of Code 2017

by Alex Ionescu

So we said we 'completed msahci' but the code is languishing in a branch... Best regards, Alex Ionescu On Thu, Jan 26, 2017 at 3:13 PM, Colin Finck <colin(a)reactos.org> wrote: > Am 26.01.2017 um 23:46 schrieb Yaroslav Veremenko: >> Just a side note, looking at the list. I think you should remove SSH Service from it as Microsoft is currently poring OpenSSH on NT > > Yep, done that. Thanks for the hint! > > > - Colin > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

8 years, 2 months

2
1
0 0

Bootlogos for FOSDEM (was: "RE: FOSDEM 2017 - It's happening!")

by Hermès BÉLUSCA-MAÏTO

Hello everyone, Upon an idea by Jared Smudde I modified a bit the ReactOS bootlogo to incorporate in addition the FOSDEM logo in it. See http://polariton.ad-l.ink/6WhjqNRrM/image.png or the attached file. I have done several versions and I would like to hear what you think from them (if possible, make a choice). Regards, Hermès -----Message d'origine----- De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Colin Finck Envoyé : jeudi 26 janvier 2017 00:16 À : 'ReactOS Development List' Objet : [ros-dev] FOSDEM 2017 - It's happening! Hi all! Hermès and me have just decided to go to FOSDEM this year. Which is a really good idea considering that we have a booth to staff there ;) Planning is currently happening at https://docs.google.com/document/d/1ofYUc7j0XwDH9SmNlGzNZlO8jOGhoPUn7KTRcFm… Just request access if you're a ReactOS member and like to add or comment stuff there. Hermès will be preparing an ISO in the upcoming days. Please test current trunk to see if any last minute fixes need to go there. If you have ideas what cool apps we shall show at FOSDEM, please also share them here. We will go with burning and giving away CDs again (hopefully the last time before USBs do it). I hope that this definite plan will also motivate others to join us or visit our booth! :) Cheers, Colin _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

8 years, 2 months

9
10
0 0

FOSDEM Announcement on website

by Colin Finck

Hi all, Someone please announce our FOSDEM presence next Saturday and Sunday (February 4/5) on the website. Hermès and me will be there representing the ReactOS Project at our shared ReactOS/HaikuOS booth in the K Building, together with Adrien Destugues and François Revol from HaikuOS. - Colin

8 years, 2 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tfaber] 73607: [NTOS:MM] - Support MmSpecialPoolTag == '*' to mean all tags. By Serge Gautherie. CORE-12711 #resolve

by Alex Ionescu

On Sat, Jan 28, 2017 at 5:08 AM, <tfaber(a)svn.reactos.org> wrote: > MmSpecialPoolTag We should add support for '?'. This is just a few extra lines of code. Best regards, Alex Ionescu

8 years, 2 months

1
0
0 0

font penalty system

by katahiromz .

Hello, this is katahiromz aka a Win32 programmer and tester from Japan. At first, check out the x12 patch of CORE-6621. Please take a look at the WeightFromStyle and GetFontPenalty functions. The "DejaVu Sans Mono" fonts are in use, as substitute fonts. There is a problem. The penalty weight of "DejaVu Sans Mono Oblique" is lighter than one of "DejaVu Sans Mono Book" in the current penalty system of Table 1. The "Oblique" penalty is 4 of Italic Penalty. The "Book" penalty is 3 * ((400 - 350) / 10) == 15 of Weight Penalty. So, Oblique < Book! Should we adjust Italic Penalty to 16 or more?

8 years, 2 months

1
0
0 0

Problems in Build Tutorial

by JasonQSY

Hi, I’m a newcomer to ros-dev and currently try to build reactos. It is ok for me but I think there might be slight problems in the tutorial. > cd output-MinGW-i386 I think it maybe cd output-MinGW-i386/reactos . Running `ninja` under `output-MinGW-i386` fails. > generates a bootable ReactOS ISO file (bootcd.iso) placed into the output directory I find `bootcd.iso` under `reactos` instead of `reactos/output`. Are they outdated? - JasonQSY

8 years, 2 months

4
3
0 0

Office 2010 support

by Colin Finck

Hi all! During the monthly meeting yesterday, there was a high demand for full Office 2010 support under ReactOS. Let's call that Word, Excel and PowerPoint for now. If we get these applications to work, the potential customer may generously sponsor the ReactOS Project. While Hermès is already working on getting Word 2010 support as part of the ReactOS Community Edition, he has shown that this task easily splits into many subtasks, like full NTLM implementation, Printing, etc. If anybody volunteers to work on these, or otherwise contribute to get the full Office 2010 to work under ReactOS, we would be willing to support this with our foundation funds too! As a first step, let's make a list of related tasks and add them to https://jira.reactos.org/browse/CORE-12279 Hermès can probably help here. If you have other ideas on how to help with Office 2010, don't hesitate to tell. This needs teamwork! Let's not miss this opportunity to make ReactOS usable for the mass! - Colin

8 years, 2 months

1
0
0 0

FOSDEM 2017 - It's happening!

by Colin Finck

Hi all! Hermès and me have just decided to go to FOSDEM this year. Which is a really good idea considering that we have a booth to staff there ;) Planning is currently happening at https://docs.google.com/document/d/1ofYUc7j0XwDH9SmNlGzNZlO8jOGhoPUn7KTRcFm… Just request access if you're a ReactOS member and like to add or comment stuff there. Hermès will be preparing an ISO in the upcoming days. Please test current trunk to see if any last minute fixes need to go there. If you have ideas what cool apps we shall show at FOSDEM, please also share them here. We will go with burning and giving away CDs again (hopefully the last time before USBs do it). I hope that this definite plan will also motivate others to join us or visit our booth! :) Cheers, Colin

8 years, 2 months

4
4
0 0

Status Meeting (January 2017)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place today, 26th of January, 19:00 UTC. We skipped the last meeting because of holidays and unavailability of people. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. Alternatively we'll do it in #reactos-meeting on Freenode, depending on our admins mood. Please send agenda proposals to me before the meeting so we don't waste time trying to setup the agenda directly during the meeting. Regards, Aleksey Bragin

8 years, 3 months

1
1
0 0

MASM using longer opcode sequences than GAS

by Colin Finck

Hi all, In order to make our ISOs flashable to USB drives and bootable from them (cf. CORE-12648), I'm currently overhauling our ISO boot sector "isoboot.S". This adds a lot of code and while I stay in the 2K size limit when assembling it with GAS, I break it with MASM. Disassembling the assembled files shows the difference. A line like: mov word ptr ds:[GetlinsecPtr], ax is assembled by GAS to: A35B50 mov [0x505b],ax while MASM does this: 67A35B500000 mov [dword 0x505b],ax Is there any option to enforce the shorter opcode sequence for MASM too? The code uses a lot of similar MOVs and this seems to be the only reason why I break the 2K size limit with MASM. If there is no such option, what are the advantages of using MASM for our MSVC build anyway? Can't we just use GAS for both or decide on a common third-party assembler (NASM) for our assembly files? Cheers, Colin

8 years, 3 months

4
4
0 0

Re: [ros-dev] [ros-diffs] [jimtabor] 73532: [NtUser] - Fix menu surfing while using MS Office 2003. See CORE-12085 and CORE-12071.

by Thomas Faber

On 2017-01-13 05:06, jimtabor(a)svn.reactos.org wrote: > VOID FASTCALL > IntSendChildNCPaint(PWND pWnd) > { > + PWND Child; > + HWND *List, *phWnd; > + > + List = IntWinListChildren(UserGetDesktopWindow()); > + if ( List ) > + { > + for (phWnd = List; *phWnd; ++phWnd) > + { > + Child = ValidateHwndNoErr(*phWnd); > + if ( Child && Child->hrgnUpdate == NULL && Child->state & WNDS_SENDNCPAINT) > + { > + USER_REFERENCE_ENTRY Ref; > + UserRefObjectCo(Child, &Ref); > + IntSendNCPaint(Child, HRGN_WINDOW); > + UserDerefObjectCo(Child); > + } > + } > + } You leak List here, both in the normal case and in the exception-during-callout case.

8 years, 3 months

2
1
0 0

Was the idea to sertup USB-flash drive giveaway with ReactOS on FOSDEM buried?

by Alexander Rechitskiy

8 years, 3 months

1
0
0 0

Re: [ros-dev] USB from GSoC

by mvardan.dev

Hello Aleksey, About readiness to get merged I think decision should be done by Thomas or Amine. Related to collaboration with ROS, as I have informed on one of the monthly meetings, I have willing to contribute ReactOS. But for now I have probelm with time which is depend on many factors. We can schedule meeting in IRC or wherever you want, to discuss how I can help to our project. Thanks,Vardan. Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Aleksey Bragin <aleksey(a)reactos.org> Date: 12/20/16 03:00 (GMT+04:00) To: ReactOS Development List <ros-dev(a)reactos.org> Subject: [ros-dev] USB from GSoC Hello! What happened to the USB branch made by Vardan during GSoC 2016? Is it ready to be merged, or if not, what's holding it? Any input is appreciated, especially from Vardan himself. Regards, Aleksey Bragin _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

8 years, 3 months

2
1
0 0

CLT 2017. Who joins us?

by Daniel Reimer

Hello and happy new year, soon the deadline for CLT 2017 is here (07.01.) and that time I'd like to add the needed minimum of two ppl there BEFORE that. So... who will join me to https://chemnitzer.linux-tage.de aka 11./12.03.2017 in Chemnitz? The sooner I know it the better it is for planning ^^ (Quite shocking that it's almost a year again since list years CLT...) I am open for anyone asking to take part, BUT I would prefer guys who already were there and know what they will have to expect regarding masses of ppl, strange guys going on your nerves on a 15 min basis and of couse the fun we will have, too. So pleaase answer ASAP. I will join IRC today, too. So if anyone has some nice recent pics of milestones running in ROS, GIMME plz ^^ Greetings Daniel

8 years, 3 months

3
4
0 0

Re: [ros-dev] [ros-diffs] [jimtabor] 73475: [Win32SS|RTL] - Fix clipping for Draw Text. Inspired by Katayama Hirofumi MZ patch and ComCtl32/RichEd20/UxThmems. See CORE-2201.

by Thomas Faber

On 2016-12-22 11:39, jimtabor(a)svn.reactos.org wrote: > +#ifndef _WIN32K_ ///// Fix CORE-2201. > + if (!(flags & DT_NOCLIP) ) > + { > + int hasClip; > + hrgn = CreateRectRgn(0,0,0,0); > + if (hrgn) > + { > + hasClip = GetClipRgn(hdc, hrgn); > + // If the region to be retrieved is NULL, the return value is 0. > + if (hasClip != 1) > + { > + DeleteObject(hrgn); > + hrgn = NULL; > + } > + IntersectClipRect(hdc, rect->left, rect->top, rect->right, rect->bottom); > + } > + } > +#else > + if (!(flags & DT_NOCLIP) ) > + { > + int hasClip; > + hrgn = NtGdiCreateRectRgn(0,0,0,0); > + if (hrgn) > + { > + hasClip = NtGdiGetRandomRgn(hdc, hrgn, CLIPRGN); > + if (hasClip != 1) > + { > + GreDeleteObject(hrgn); > + hrgn = NULL; > + } > + NtGdiIntersectClipRect(hdc, rect->left, rect->top, rect->right, rect->bottom); > + } > + } > +#endif ///// Any particular reason not to simply do the NtGdi call in both user and kernel? Looks like they should be doing the exact same thing.

8 years, 3 months

2
1
0 0

The Terminator^W AHK bot needs a vacation

by Sylvain Petreolle

During Christmas, I have to leave the AHK bot room free of machine noise at my place. The bot is officially on vacation until Dec 27-28th :-) Happy Christmas, Sylvain Petreolle

8 years, 4 months

1
0
0 0

USB from GSoC

by Aleksey Bragin

Hello! What happened to the USB branch made by Vardan during GSoC 2016? Is it ready to be merged, or if not, what's holding it? Any input is appreciated, especially from Vardan himself. Regards, Aleksey Bragin

8 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [gadamopoulos] 73436: [SHELL32] - Initialize the shell icon cache only when needed or when FileIconInit is called (and not in the DllMain of shell32)

by Thomas Faber

On 2016-12-07 01:10, gadamopoulos(a)svn.reactos.org wrote: > [SHELL32] - Initialize the shell icon cache only when needed or when FileIconInit is called (and not in the DllMain of shell32) > --- trunk/reactos/dll/win32/shell32/iconcache.cpp [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/shell32/iconcache.cpp [iso-8859-1] Wed Dec 7 00:10:43 2016 > @@ -453,6 +453,9 @@ > sice.dwSourceIndex = dwSourceIndex; > sice.dwFlags = dwFlags; > > + if (!sic_hdpa) > + SIC_Initialize(); > + > EnterCriticalSection(&SHELL32_SicCS); > > if (NULL != DPA_GetPtr (sic_hdpa, 0)) > @@ -687,6 +690,9 @@ > RegCloseKey(hKeyShellIcons); > } > > + if (!sic_hdpa) > + SIC_Initialize(); > + > return SIC_LoadIcon(iconPath, iconIdx, 0); > } > This is great. Unfortunately now you have a race condition if multiple of these functions get called concurrently.

8 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 73433: [SERVICES] Create a new environment block when a service process is started. Patch by Hermès BÉLUSCA - MAÏTO. CORE-12414

by Ged Murphy

This leaks if ImpersonateLoggedOnUser fails and the environment block is non-null -----Original Message----- From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of ekohl(a)svn.reactos.org Sent: 06 December 2016 17:30 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [ekohl] 73433: [SERVICES] Create a new environment block when a service process is started. Patch by Hermès BÉLUSCA - MAÏTO. CORE-12414 + if (Service->lpImage->hToken) + { + /* User token: Run the service under the user account */ + + if (!CreateEnvironmentBlock(&lpEnvironment, Service->lpImage->hToken, FALSE)) + { + /* We failed, run the service with the current environment */ + DPRINT1("CreateEnvironmentBlock() failed with error %d, service '%S' will run with the current environment.\n", + Service->lpServiceName, GetLastError()); + lpEnvironment = NULL; + } + + /* Impersonate the new user */ + if (!ImpersonateLoggedOnUser(Service->lpImage->hToken)) + { + dwError = GetLastError(); + DPRINT1("ImpersonateLoggedOnUser() failed with error %d\n", GetLastError()); + return dwError; + }

8 years, 4 months

1
0
0 0

From this moment PVS-Studio is free of charge for opensource projects

by Alexander Rechitskiy

8 years, 4 months

4
4
0 0

Invitation to join ReactOS Deutschland e.V.

by Colin Finck

Hi all, This invitation is long overdue: Back in 2009 when our German foundation ReactOS Deutschland e.V. was established, it was merely the legal entity to handle the small amount of incoming donations. Today, things have drastically changed: Our fundraising campaign in 2014 as well as the successful website relaunch and 0.4 release brought us many more funds. By establishing scholarships and contracting IT freelancers, ReactOS Deutschland e.V. is actively funding the actual ReactOS development. Apart from that, it is sponsoring and planning the presentation of ReactOS on popular Open-Source exhibitions. Furthermore, we have created an English translation of our Articles of Association/Charter and moved to English reports a while ago. This finally allows non-German members to join. Therefore, I'm inviting all active ReactOS developers to join ReactOS Deutschland e.V. as active members. Needless to say, active members don't pay any membership fees and have full voting rights at our General Assembly. We usually have such a General Assembly every year and this is basically your only duty: Attend the General Assemblies so that decisions are backed by a strong majority. The only exception I have to make is that the members candidating for the Board need to be German speakers to communicate with the authorities. This is necessary from time to time. You find the Articles of Association as well as all annual reports on our website https://ev.reactos.org To become an active member, simply fill out the application at https://ev.reactos.org/files/Membership_Application.pdf and send it to me via mail. You can cross out the "Direct Debit Authorization", this part is only relevant for supporting members. Unfortunately, we're bound to snail mail and can't do applications electronically, because I need a real signature and proof of your application for the authorities. Looking forward to your applications! :) Cheers, Colin

8 years, 4 months

5
5
0 0

We can sell ReactOS CD on https://www.osdisc.com/affiliate

by Alexander Rechitskiy

8 years, 5 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 73233: [LSASRV] - No need to hardcode the name of the dll in the GetModuleHandleW call; - Use ARRAYSIZE instead of hardcoding string buffer sizes; - When initializing the "Network Sid", ...

by Thomas Faber

On 2016-11-14 17:19, hbelusca(a)svn.reactos.org wrote: > - hInstance = GetModuleHandleW(L"lsasrv.dll"); > + hInstance = GetModuleHandleW(NULL); Those are not equivalent at all.

8 years, 5 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [mjansen] 73180: [SHELL32_APITEST] Add some tests for ShellExecuteEx showing extension completion with the App Paths registry key. Patch by Yaroslav Veremenko. CORE-12049

by Thomas Faber

APITests should be named after a function. And in particular, they can't be named the same as a Wine test for the same module. This is currently causing result submission on Testbot to fail, so please rename this test. On 2016-11-09 23:13, mjansen(a)svn.reactos.org wrote: > Author: mjansen > Date: Wed Nov 9 22:13:26 2016 > New Revision: 73180 > > URL: http://svn.reactos.org/svn/reactos?rev=73180&view=rev > Log: > [SHELL32_APITEST] Add some tests for ShellExecuteEx showing extension completion with the App Paths registry key. Patch by Yaroslav Veremenko. CORE-12049 > > Added: > trunk/rostests/apitests/shell32/shlexec.cpp (with props) > Modified: > trunk/rostests/apitests/shell32/CMakeLists.txt > trunk/rostests/apitests/shell32/testlist.c

8 years, 5 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [phater] 73095: [TCPIP] Copy back unicast IP if broadcast is specified for listen. CORE-12152

by Thomas Faber

On 2016-11-02 12:24, phater(a)svn.reactos.org wrote: > + /* Check if we had an unspecified address */ > + if (Connection->AddressFile->Address.Address.IPv4Address != bindaddr.addr) > + { > + /* We did, so we need to copy back the address */ > + Connection->AddressFile->Address.Address.IPv4Address = bindaddr.addr; > + } Seems like you could shorten this to just the assignment?

8 years, 5 months

2
1
0 0

Re: [ros-dev] [ros-builds] Build GCCLin_x86: build failed

by Jerome Gardou

Someone's got to help me. I can't figure out how to make this thing patch the rostests directory. Le 31/10/2016 à 11:15, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder Build GCCLin_x86 while building ReactOS. > Full details are available at: > https://build.reactos.org/builders/Build%20GCCLin_x86/builds/16201 > > Buildbot URL: https://build.reactos.org/ > > Buildslave for this Build: HotelLux > > Build Reason: A build was forced by 'jgardou <jgardou@localhost>': Test ROSTESTS-155 > Build Source Stamp: HEAD > Blamelist: > > BUILD FAILED: failed patching > > sincerely, > -The Buildbot > > > > >

8 years, 5 months

2
2
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 73078: [BTRFS]: Fix compilation with MSVC too, as we don't have the 'FileFsSectorSizeInformation' FS information class in our headers (this is some Win8+ stuff). CORE-12223 #comment MSVC...

by Thomas Faber

And what's wrong with just adding it to our headers? On 2016-10-30 15:14, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Sun Oct 30 14:14:27 2016 > New Revision: 73078 > > URL: http://svn.reactos.org/svn/reactos?rev=73078&view=rev > Log: > [BTRFS]: Fix compilation with MSVC too, as we don't have the 'FileFsSectorSizeInformation' FS information class in our headers (this is some Win8+ stuff). > CORE-12223 #comment MSVC compilation fixed in r73078 ('FileFsSectorSizeInformation' absent in our headers). > > Modified: > trunk/reactos/drivers/filesystems/btrfs/btrfs.c > > Modified: trunk/reactos/drivers/filesystems/btrfs/btrfs.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/btrfs/… > ============================================================================== > --- trunk/reactos/drivers/filesystems/btrfs/btrfs.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/btrfs/btrfs.c [iso-8859-1] Sun Oct 30 14:14:27 2016 > @@ -716,7 +716,8 @@ > Status = overflow ? STATUS_BUFFER_OVERFLOW : STATUS_SUCCESS; > break; > } > - > + > +#ifndef __REACTOS__ > #ifdef _MSC_VER // not in mingw yet > case FileFsSectorSizeInformation: > { > @@ -739,6 +740,7 @@ > break; > } > #endif > +#endif /* __REACTOS__ */ > > default: > Status = STATUS_INVALID_PARAMETER; > >

8 years, 5 months

1
0
0 0

Status Meeting (October 2016)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place today, 27th of October, 19:00 UTC. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. Alternatively we'll do it in #reactos-meeting on Freenode, depending on our admins mood. Please send agenda proposals to me before the meeting so we don't waste time trying to setup the agenda directly during the meeting. Regards, Aleksey Bragin

8 years, 5 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 73046: Fix a comment.

by Thomas Faber

On 2016-10-27 00:06, hbelusca(a)svn.reactos.org wrote: > - /* Sundry checkboxes */ > + /* Other checkboxes */ Not sure how this "fixes" anything? Those are synonyms?

8 years, 5 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [janderwald] 73016: [USBAUDIO] - implement retrieving string descriptor of product and store it in registry.

by Thomas Faber

On 2016-10-21 23:15, janderwald(a)svn.reactos.org wrote: > NTSTATUS > +NTAPI > +USBAudioGetDescriptor( > + IN PDEVICE_OBJECT DeviceObject, > + IN UCHAR DescriptorType, > + IN ULONG DescriptorLength, > + IN UCHAR DescriptorIndex, > + IN LANGID LanguageId, > + OUT PVOID *OutDescriptor) > +{ > + PURB Urb; > + NTSTATUS Status; > + PVOID Descriptor; > + > + /* sanity checks */ > + ASSERT(DeviceObject); > + ASSERT(OutDescriptor); > + ASSERT(DescriptorLength); > + > + // > + // first allocate descriptor buffer > + // > + Descriptor = AllocFunction(DescriptorLength); > + if (!Descriptor) > + { > + /* no memory */ > + return STATUS_INSUFFICIENT_RESOURCES; > + } > + > + /* allocate urb */ > + Urb = (PURB)AllocFunction(sizeof(URB)); > + if (!Urb) > + { > + /* no memory */ > + FreeFunction(Descriptor); > + return STATUS_INSUFFICIENT_RESOURCES; > + } > + > + /* initialize urb */ > + UsbBuildGetDescriptorRequest(Urb, > + sizeof(Urb->UrbControlDescriptorRequest), > + DescriptorType, > + DescriptorIndex, > + LanguageId, > + Descriptor, > + NULL, > + DescriptorLength, > + NULL); > + > + /* submit urb */ > + Status = SubmitUrbSync(DeviceObject, Urb); > + > + /* free urb */ > + FreeFunction(Urb); > + > + if (NT_SUCCESS(Status)) > + { > + /* store result */ > + *OutDescriptor = Descriptor; > + } Is Descriptor leaked in the failure case, or does something down the stack take care of that? > + > + /* done */ > + return Status; > +} > +NTSTATUS > +USBAudioRegCreateMediaCategoriesKey( > + IN PUNICODE_STRING Name, > + OUT PHANDLE OutHandle) > +{ > + NTSTATUS Status; > + OBJECT_ATTRIBUTES ObjectAttributes; > + UNICODE_STRING DestinationString; > + HANDLE Handle; > + > + /* initialize root name*/ > + RtlInitUnicodeString(&DestinationString, L"\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\MediaCategories\\"); > + > + /* initialize object attributes */ > + InitializeObjectAttributes(&ObjectAttributes, &DestinationString, OBJ_CASE_INSENSITIVE | OBJ_OPENIF, NULL, NULL); You're missing OBJ_KERNEL_HANDLE. > + > + /* create the key */ > + Status = ZwOpenKey(&Handle, KEY_ALL_ACCESS, &ObjectAttributes); > + if (NT_SUCCESS(Status)) > + { > + /* initialize object attributes */ > + InitializeObjectAttributes(&ObjectAttributes, Name, OBJ_CASE_INSENSITIVE, Handle, NULL); Here too. > + > + Status = ZwCreateKey(OutHandle, KEY_ALL_ACCESS, &ObjectAttributes, 0, NULL, 0, NULL); > + ZwClose(Handle); > + > + } > + return Status; > +} Thanks. -Thomas

8 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 72997: [KERNEL32]: Mark Get/SetEnvironmentVariableA/W as hotpatchable since it's needed for Clink 0.4.8 (<rant>btw, if GCC was able to set exported stdcall functions as hotpatchable at a...

by Timo Kreuzer

What about adding it to WINAPI? #ifdef _HOTPATCH_MODULE_ #define WINAPI __stdcall DECLSPEC_HOTPATCH #else #endif #define WINAPI __stdcall Timo Am 20.10.2016 um 00:26 schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Wed Oct 19 22:26:04 2016 > New Revision: 72997 > > URL: http://svn.reactos.org/svn/reactos?rev=72997&view=rev > Log: > [KERNEL32]: Mark Get/SetEnvironmentVariableA/W as hotpatchable since it's needed for Clink 0.4.8 (<rant>btw, if GCC was able to set exported stdcall functions as hotpatchable at a global level, as MSVC does, those "DECLSPEC_HOTPATCH" hacks would not be necessary! </rant>) > > Modified: > trunk/reactos/dll/win32/kernel32/client/environ.c > > Modified: trunk/reactos/dll/win32/kernel32/client/environ.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/client/environ.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/client/environ.c [iso-8859-1] Wed Oct 19 22:26:04 2016 > @@ -24,6 +24,7 @@ > */ > DWORD > WINAPI > +DECLSPEC_HOTPATCH > GetEnvironmentVariableA(IN LPCSTR lpName, > IN LPSTR lpBuffer, > IN DWORD nSize) > @@ -158,6 +159,7 @@ > */ > DWORD > WINAPI > +DECLSPEC_HOTPATCH > GetEnvironmentVariableW(IN LPCWSTR lpName, > IN LPWSTR lpBuffer, > IN DWORD nSize) > @@ -212,6 +214,7 @@ > */ > BOOL > WINAPI > +DECLSPEC_HOTPATCH > SetEnvironmentVariableA(IN LPCSTR lpName, > IN LPCSTR lpValue) > { > @@ -252,6 +255,7 @@ > */ > BOOL > WINAPI > +DECLSPEC_HOTPATCH > SetEnvironmentVariableW(IN LPCWSTR lpName, > IN LPCWSTR lpValue) > { > > >

8 years, 6 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 72992: [CONSRV]: Code style changes only.

by Thomas Faber

On 2016-10-19 01:45, hbelusca(a)svn.reactos.org wrote: > --- trunk/reactos/win32ss/user/winsrv/consrv/frontends/gui/conwnd.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/winsrv/consrv/frontends/gui/conwnd.c [iso-8859-1] Tue Oct 18 23:45:19 2016 > @@ -137,7 +137,7 @@ > GetSystemMetrics(SM_CXSMICON), > GetSystemMetrics(SM_CYSMICON), > LR_SHARED); > - ghDefaultCursor = LoadCursorW(NULL, IDC_ARROW); > + ghDefaultCursor = LoadCursorW(NULL, MAKEINTRESOURCEW(IDC_ARROW)); > > WndClass.cbSize = sizeof(WNDCLASSEXW); > WndClass.lpszClassName = GUI_CONWND_CLASS; Defining UNICODE or WINE_NO_UNICODE_MACROS seems preferably to this double cast. After all, the definition for IDC_ARROW is: #define IDC_ARROW MAKEINTRESOURCE(32512)

8 years, 6 months

1
0
0 0

MSVC and GCC Windows Buildslaves are back - old ISOs are not

by Colin Finck

Hi all, Thanks to Dmitry Chapyshev's generous donation of rare FB-DIMM memory modules, our Buildserver has enough RAM for the Win7 buildslave VM now. I've fired it up and while builds are much slower than before, they are at least being done again! Note that Doxygen, ISO hosting, and all three buildslaves are on a single HDD-backed server right now, so don't expect any performance miracles. I'm counting on Aleksey here to get us our remaining servers back this month :) Unfortunately, our HDDs were also lacking space, so I had to move the public "bootcd_old" folder from iso.reactos.org to another (private) place. It contained BootCD ISOs from 2009 to 2012, totalling 421GB. Any idea how to deal with them in the long run? I can basically think of 4 possibilities: * We remove ISOs older than 4 years, because nobody would really do regression-testing with them. * We buy additional HDDs every year and continue to host them ourselves just next to the newer ISOs. * We find a free file hosting service for OSS projects that can cope with these amounts of data. Not sure SF.net is the right choice here.. * We choose a paid data storage service like Amazon AWS. As always, comments are very welcome! - Colin

8 years, 6 months

4
6
0 0

ReactOS Service Login problems fixed

by Colin Finck

Hi all! For those of you who experienced Login problems with ReactOS Services such as BuildBot, Mumble or SVN, I have cleaned up and applied some fixes to our LDAP directory today. All known problems should be fixed now! If you still experience such problems, please reply to this mail. - Colin

8 years, 6 months

1
0
0 0

Retrieving the computer name of a named pipe client

by Colin Finck

Hi all, For implementing the RpcBindingServerFromClient rpcrt4.dll API function needed by my Printing Stack, I need to know how to retrieve the computer name of a named pipe client. Vista and later implement GetNamedPipeClientComputerName in kernel32.dll which does exactly this, but this is neither supported under Windows Server 2003 nor implemented in ReactOS and WINE. Determining client information is a basic feature of network communication, so it should be possible under Windows 2003 as well. Additionally, RpcBindingServerFromClient returns the proper computer name of the client, when using named pipes over the ncacn_np transport. It must have got it somehow. Hoping for some ideas from your side! Colin

8 years, 6 months

3
3
0 0

Re: [ros-dev] Retrieving the computer name of a named pipe client

by Alex Ionescu

You literally wrote " but this is neither supported under Windows Server 2003", so yes, there's your answer :) Best regards, Alex Ionescu On Tue, Oct 11, 2016 at 1:18 PM, Colin Finck <colin(a)reactos.org> wrote: > Am 10.10.2016 um 23:22 schrieb Timo Kreuzer: >> #define FSCTL_PIPE_GET_CONNECTION_ATTRIBUTE >> CTL_CODE(FILE_DEVICE_NAMED_PIPE, 12, METHOD_BUFFERED, FILE_ANY_ACCESS) >> >> static const char AttributeName[] = "ClientComputerName"; >> >> Status = NtFsControlFile(NamedPipeHandle, > > Are you sure this is the right way of doing it under Windows 2003? > While 2003's rpcrt4.dll imports NtFsControlFile, running GNU strings on > it doesn't output any "ClientComputerName" string. > > Furthermore, our NPFS driver only implements the FSCTL_PIPE_* control > codes up to FSCTL_PIPE_QUERY_CLIENT_PROCESS (#9). #10 to #16 (with > FSCTL_PIPE_GET_CONNECTION_ATTRIBUTE being #12) are not processed. Same > goes for the free ntifs.h from https://www.acc.umu.se/~bosse/ntifs.h, it > lacks all FSCTL_PIPE_* codes after #9. I'm getting the impression, #10 > to #16 were only introduced with NT 6.0. > If I had the ntifs.h from Windows 2003, I could confirm my theory, but > this file was never public and only part of the commercial IFS Kit. > > So, talking to the NPFS driver probably goes into the right direction, > but I assume we have to find an alternative to > FSCTL_PIPE_GET_CONNECTION_ATTRIBUTE. > > > - Colin > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

8 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [phater] 72948: [MSAFD] Fix some return codes and better parameter checks based on wine tests CORE-12104

by Thomas Faber

Hurray! Congrats on your first commit! On 2016-10-10 08:38, phater(a)svn.reactos.org wrote: > Author: phater > Date: Mon Oct 10 06:38:52 2016 > New Revision: 72948 > > URL: http://svn.reactos.org/svn/reactos?rev=72948&view=rev > Log: > [MSAFD] Fix some return codes and better parameter checks based on wine tests CORE-12104 > > Modified: > trunk/reactos/dll/win32/msafd/misc/dllmain.c >

8 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 72943: [PING] - Use a dynamic-allocated buffer with FormatMessageW, fixes messages disappearance (eg. ping help in russian). CORE-12108 #comment Fixed in r72943. - Remove the unneeded 1-...

by Colin Finck

hbelusca(a)svn.reactos.org wrote: > +#define RC_STRING_MAX_SIZE 4096 > + > + WCHAR Format[RC_STRING_MAX_SIZE]; > + LPWSTR lpMsgBuf = NULL; > + DWORD Len; > va_list args; > > if (!LoadStringW(GetModuleHandleW(NULL), id, Format, > _countof(Format))) Now instead of #define RC_STRING_MAX_SIZE 4096 WCHAR Format[RC_STRING_MAX_SIZE]; LoadStringW(GetModuleHandleW(NULL), id, Format, _countof(Format)); just do a LPWSTR lpFormatBuf; LoadStringW(GetModuleHandleW(NULL), id, (LPWSTR)&lpFormatBuf, 0); and you have a perfect universal solution for any resource string length without caring about buffer sizes at all. It doesn't even need any extra memory :) This should actually be changed in a lot of places! - Colin

8 years, 6 months

2
1
0 0

[ros-diffs] [spetreolle] 72905: [NtUser] Turn an ERR into a TRACE.

by James Tabor

Now we will never know what happen to the lost application!

8 years, 6 months

2
3
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 72939: Fix commit synchronization issue (that's what happens when you work on a patch that somebody else worked on in parallel!!)

by Amine Khaldi

Hi, Please think twice before committing to the ReactOS repo. The most recent example is the format/lang/uk-UA.rc changes that have absolutely nothing to do with the "Russian translation update by Sergey Stopkin." commit log. When you do that, you'll always be committing while being calm and in control of what you're sending. The svn history is a responsibility shared between the ReactOS developers. Regards, Amine.

8 years, 6 months

1
0
0 0

jira is down for me

by Alexander Rechitskiy

8 years, 6 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 72922: [KD] - When enabling or disabling the kernel debugger and setting the KdDebuggerEnabled flag, also update the corresponding user-mode flag in SharedUserData->KdDebuggerEnabled. - ...

by Pierre Schweitzer

Le 06/10/2016 à 21:01, hbelusca(a)svn.reactos.org a écrit : > Author: hbelusca > Date: Thu Oct 6 19:01:33 2016 > New Revision: 72922 > > URL: http://svn.reactos.org/svn/reactos?rev=72922&view=rev > Log: > [KD] > - When enabling or disabling the kernel debugger and setting the KdDebuggerEnabled flag, also update the corresponding user-mode flag in SharedUserData->KdDebuggerEnabled. > - Turn KdpGetMemorySizeInMBs into a INIT_FUNCTION. > - Print kernel command line & ARC paths even in debug log file mode. > > [KD64] > WinKD: Also print our nice ReactOS debug header (version, # of processors & memory MB, kernel command line and ARC paths). > > Modified: > trunk/reactos/ntoskrnl/kd/kdinit.c > trunk/reactos/ntoskrnl/kd/kdio.c > trunk/reactos/ntoskrnl/kd/kdmain.c > trunk/reactos/ntoskrnl/kd64/kdapi.c > trunk/reactos/ntoskrnl/kd64/kdinit.c > > Modified: trunk/reactos/ntoskrnl/kd/kdio.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd/kdio.c?rev=729… > ============================================================================== > --- trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] Thu Oct 6 19:01:33 2016 > @@ -240,10 +243,15 @@ > KeInitializeSpinLock(&KdpDebugLogSpinLock); > > /* Display separator + ReactOS version at start of the debug log */ > - DPRINT1("---------------------------------------------------------------\n"); > + DPRINT1("-----------------------------------------------------\n"); This specific change has likely broken any testbot running sysreg2 and vmware or vbox. Why was this change even needed? -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

8 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [akhaldi] 72908: [WS2_32_APITEST] Add tests for getnameinfo. By Peter Hater. CORE-8549

by Thomas Faber

On 2016-10-05 11:33, akhaldi(a)svn.reactos.org wrote: > --- trunk/rostests/apitests/ws2_32/getnameinfo.c (added) > +++ trunk/rostests/apitests/ws2_32/getnameinfo.c [iso-8859-1] Wed Oct 5 09:33:03 2016 > @@ -0,0 +1,99 @@ > +/* > + * PROJECT: ReactOS api tests > + * LICENSE: GPLv2+ - See COPYING in the top level directory > + * PURPOSE: Test for getaddrinfo > + * PROGRAMMER: Thomas Faber <thomas.faber(a)reactos.org> > + */ Thanks for the credit, but I don't think I deserve it ;)

8 years, 6 months

1
0
0 0

Re: [ros-dev] KD trace during ROS installation

by Love Nystrom

Good afternoon gentlemen... Seems the list server has gone on a vacation. Still waiting on the digest where Hermes added to Thomas answer.. Anyway Hermes pasted his answer to my mailbox (thank you) and so.. One more step is required in addition to the answers from Thomas and Hermes.. A small patch in 'base/setup/usetup/bootsup.c', which contains the code that writes 'freeldr.ini' to the HD during install. Without patching in the desired COM port there, trace is lost after ROS installation reboots from HD. Perhaps we should have a wiki page to cover this ? And/or perhaps we should make it easier to make this mod, by moving the hard coded strings from bootsup.c into an ini file or whatever ? Anyway, I got my install trace, and posted a clip concerning the Gecko breakage to CORE-12011. Best Regards L.

8 years, 6 months

1
0
0 0

Status Meeting (September 2016)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place this Thursday, 29th of September, 19:00 UTC. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. Or we'll do it in #reactos-meeting on Freenode, depeonds on our admins. Please send agenda proposals to me before the meeting so we don't waste time trying to setup the agenda directly during the meeting. Regards, Aleksey Bragin

8 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 72835: [NTOS:FSRTL] Rework FsRtlIsNameInExpressionPrivate for correct parsing some expressions * Fixes 1 test for kmtest:FsRtlExpression and 15 tests for kernel32:file

by Pierre Schweitzer

Don't forget to apply the changes (not reviewed, sorry, no time) to FsRtlIsDbcsInExpression. Le 28/09/2016 à 01:00, dchapyshev(a)svn.reactos.org a écrit : > Author: dchapyshev > Date: Tue Sep 27 23:00:20 2016 > New Revision: 72835 > > URL: http://svn.reactos.org/svn/reactos?rev=72835&view=rev > Log: > [NTOS:FSRTL] Rework FsRtlIsNameInExpressionPrivate for correct parsing some expressions > > * Fixes 1 test for kmtest:FsRtlExpression and 15 tests for kernel32:file > > Modified: > trunk/reactos/ntoskrnl/fsrtl/name.c > > Modified: trunk/reactos/ntoskrnl/fsrtl/name.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/fsrtl/name.c?rev=… > ============================================================================== > --- trunk/reactos/ntoskrnl/fsrtl/name.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/fsrtl/name.c [iso-8859-1] Tue Sep 27 23:00:20 2016 > @@ -23,13 +23,14 @@ > IN BOOLEAN IgnoreCase, > IN PWCHAR UpcaseTable OPTIONAL) > { > - SHORT StarFound = -1, DosStarFound = -1; > - USHORT BackTrackingBuffer[5], DosBackTrackingBuffer[5]; > - PUSHORT BackTracking = BackTrackingBuffer, DosBackTracking = DosBackTrackingBuffer; > - SHORT BackTrackingSize = RTL_NUMBER_OF(BackTrackingBuffer); > - SHORT DosBackTrackingSize = RTL_NUMBER_OF(DosBackTrackingBuffer); > + USHORT Offset, Position, BackTrackingPosition, OldBackTrackingPosition; > + USHORT BackTrackingBuffer[16], OldBackTrackingBuffer[16] = {0}; > + PUSHORT BackTrackingSwap, BackTracking = BackTrackingBuffer, OldBackTracking = OldBackTrackingBuffer; > UNICODE_STRING IntExpression; > - USHORT ExpressionPosition = 0, NamePosition = 0, MatchingChars, LastDot; > + USHORT ExpressionPosition = 0, NamePosition = 0, MatchingChars = 1; > + BOOLEAN EndOfName = FALSE; > + BOOLEAN Result = FALSE; > + BOOLEAN DontSkipDot; > WCHAR CompareChar; > PAGED_CODE(); > > @@ -37,7 +38,7 @@ > if (!Name->Length || !Expression->Length) > { > /* Return TRUE if both strings are empty, otherwise FALSE */ > - if (Name->Length == 0 && Expression->Length == 0) > + if (!Name->Length && !Expression->Length) > return TRUE; > else > return FALSE; > @@ -103,193 +104,144 @@ > } > } > > - while ((NamePosition < Name->Length / sizeof(WCHAR)) && > - (ExpressionPosition < Expression->Length / sizeof(WCHAR))) > - { > - /* Basic check to test if chars are equal */ > - CompareChar = IgnoreCase ? UpcaseTable[Name->Buffer[NamePosition]] : > - Name->Buffer[NamePosition]; > - if (Expression->Buffer[ExpressionPosition] == CompareChar) > - { > - NamePosition++; > - ExpressionPosition++; > - } > - /* Check cases that eat one char */ > - else if (Expression->Buffer[ExpressionPosition] == L'?') > - { > - NamePosition++; > - ExpressionPosition++; > - } > - /* Test star */ > - else if (Expression->Buffer[ExpressionPosition] == L'*') > - { > - /* Skip contigous stars */ > - while ((ExpressionPosition + 1 < (USHORT)(Expression->Length / sizeof(WCHAR))) && > - (Expression->Buffer[ExpressionPosition + 1] == L'*')) > - { > - ExpressionPosition++; > - } > - > - /* Save star position */ > - StarFound++; > - if (StarFound >= BackTrackingSize) > - { > - ASSERT(BackTracking == BackTrackingBuffer); > - > - BackTrackingSize = Expression->Length / sizeof(WCHAR); > - BackTracking = ExAllocatePoolWithTag(PagedPool | POOL_RAISE_IF_ALLOCATION_FAILURE, > - BackTrackingSize * sizeof(USHORT), > - 'nrSF'); > - RtlCopyMemory(BackTracking, BackTrackingBuffer, sizeof(BackTrackingBuffer)); > - > - } > - BackTracking[StarFound] = ExpressionPosition++; > - > - /* If star is at the end, then eat all rest and leave */ > - if (ExpressionPosition == Expression->Length / sizeof(WCHAR)) > - { > - NamePosition = Name->Length / sizeof(WCHAR); > + /* Name parsing loop */ > + for (; !EndOfName; MatchingChars = BackTrackingPosition, NamePosition++) > + { > + /* Reset positions */ > + OldBackTrackingPosition = BackTrackingPosition = 0; > + > + if (NamePosition >= Name->Length / sizeof(WCHAR)) > + { > + EndOfName = TRUE; > + if (OldBackTracking[MatchingChars - 1] == Expression->Length * 2) > break; > - } > - > - /* Allow null matching */ > - if (Expression->Buffer[ExpressionPosition] != L'?' && > - Expression->Buffer[ExpressionPosition] != Name->Buffer[NamePosition]) > - { > - NamePosition++; > - } > - } > - /* Check DOS_STAR */ > - else if (Expression->Buffer[ExpressionPosition] == DOS_STAR) > - { > - /* Skip contigous stars */ > - while ((ExpressionPosition + 1 < (USHORT)(Expression->Length / sizeof(WCHAR))) && > - (Expression->Buffer[ExpressionPosition + 1] == DOS_STAR)) > - { > - ExpressionPosition++; > - } > - > - /* Look for last dot */ > - MatchingChars = 0; > - LastDot = (USHORT)-1; > - while (MatchingChars < Name->Length / sizeof(WCHAR)) > - { > - if (Name->Buffer[MatchingChars] == L'.') > - { > - LastDot = MatchingChars; > - if (LastDot > NamePosition) > - break; > - } > - > - MatchingChars++; > - } > - > - /* If we don't have dots or we didn't find last yet > - * start eating everything > - */ > - if (MatchingChars != Name->Length || LastDot == (USHORT)-1) > - { > - DosStarFound++; > - if (DosStarFound >= DosBackTrackingSize) > - { > - ASSERT(DosBackTracking == DosBackTrackingBuffer); > - > - DosBackTrackingSize = Expression->Length / sizeof(WCHAR); > - DosBackTracking = ExAllocatePoolWithTag(PagedPool | POOL_RAISE_IF_ALLOCATION_FAILURE, > - DosBackTrackingSize * sizeof(USHORT), > + } > + > + while (MatchingChars > OldBackTrackingPosition) > + { > + ExpressionPosition = (OldBackTracking[OldBackTrackingPosition++] + 1) / 2; > + > + /* Expression parsing loop */ > + for (Offset = 0; ExpressionPosition < Expression->Length; Offset = sizeof(WCHAR)) > + { > + ExpressionPosition += Offset; > + > + if (ExpressionPosition == Expression->Length) > + { > + BackTracking[BackTrackingPosition++] = Expression->Length * 2; > + break; > + } > + > + /* If buffer too small */ > + if (BackTrackingPosition > RTL_NUMBER_OF(BackTrackingBuffer) - 1) > + { > + /* Allocate memory for BackTracking */ > + BackTracking = ExAllocatePoolWithTag(PagedPool | POOL_RAISE_IF_ALLOCATION_FAILURE, > + (Expression->Length + sizeof(WCHAR)) * sizeof(USHORT), > + 'nrSF'); > + /* Copy old buffer content */ > + RtlCopyMemory(BackTracking, > + BackTrackingBuffer, > + RTL_NUMBER_OF(BackTrackingBuffer) * sizeof(USHORT)); > + > + /* Allocate memory for OldBackTracking */ > + OldBackTracking = ExAllocatePoolWithTag(PagedPool | POOL_RAISE_IF_ALLOCATION_FAILURE, > + (Expression->Length + sizeof(WCHAR)) * sizeof(USHORT), > 'nrSF'); > - RtlCopyMemory(DosBackTracking, DosBackTrackingBuffer, sizeof(DosBackTrackingBuffer)); > - } > - DosBackTracking[DosStarFound] = ExpressionPosition++; > - > - /* Not the same char, start exploring */ > - if (Expression->Buffer[ExpressionPosition] != Name->Buffer[NamePosition]) > - NamePosition++; > - } > - else > - { > - /* Else, if we are at last dot, eat it - otherwise, null match */ > - if (Name->Buffer[NamePosition] == '.') > - NamePosition++; > - > - ExpressionPosition++; > - } > - } > - /* Check DOS_DOT */ > - else if (Expression->Buffer[ExpressionPosition] == DOS_DOT) > - { > - /* We only match dots */ > - if (Name->Buffer[NamePosition] == L'.') > - { > - NamePosition++; > - } > - /* Try to explore later on for null matching */ > - else if ((ExpressionPosition + 1 < (USHORT)(Expression->Length / sizeof(WCHAR))) && > - (Name->Buffer[NamePosition] == Expression->Buffer[ExpressionPosition + 1])) > - { > - NamePosition++; > - } > - ExpressionPosition++; > - } > - /* Check DOS_QM */ > - else if (Expression->Buffer[ExpressionPosition] == DOS_QM) > - { > - /* We match everything except dots */ > - if (Name->Buffer[NamePosition] != L'.') > - { > - NamePosition++; > - } > - ExpressionPosition++; > - } > - /* If nothing match, try to backtrack */ > - else if (StarFound >= 0) > - { > - ExpressionPosition = BackTracking[StarFound--]; > - } > - else if (DosStarFound >= 0) > - { > - ExpressionPosition = DosBackTracking[DosStarFound--]; > - } > - /* Otherwise, fail */ > - else > - { > - break; > - } > - > - /* Under certain circumstances, expression is over, but name isn't > - * and we can backtrack, then, backtrack */ > - if (ExpressionPosition == Expression->Length / sizeof(WCHAR) && > - NamePosition != Name->Length / sizeof(WCHAR) && > - StarFound >= 0) > - { > - ExpressionPosition = BackTracking[StarFound--]; > - } > - } > - /* If we have nullable matching wc at the end of the string, eat them */ > - if (ExpressionPosition != Expression->Length / sizeof(WCHAR) && NamePosition == Name->Length / sizeof(WCHAR)) > - { > - while (ExpressionPosition < Expression->Length / sizeof(WCHAR)) > - { > - if (Expression->Buffer[ExpressionPosition] != DOS_DOT && > - Expression->Buffer[ExpressionPosition] != L'*' && > - Expression->Buffer[ExpressionPosition] != DOS_STAR) > - { > + /* Copy old buffer content */ > + RtlCopyMemory(OldBackTracking, > + OldBackTrackingBuffer, > + RTL_NUMBER_OF(OldBackTrackingBuffer) * sizeof(USHORT)); > + } > + > + /* Basic check to test if chars are equal */ > + CompareChar = IgnoreCase ? UpcaseTable[Name->Buffer[NamePosition]] : > + Name->Buffer[NamePosition]; > + if (Expression->Buffer[ExpressionPosition / sizeof(WCHAR)] == CompareChar && !EndOfName) > + { > + BackTracking[BackTrackingPosition++] = (ExpressionPosition + sizeof(WCHAR)) * 2; > + } > + /* Check cases that eat one char */ > + else if (Expression->Buffer[ExpressionPosition / sizeof(WCHAR)] == L'?' && !EndOfName) > + { > + BackTracking[BackTrackingPosition++] = (ExpressionPosition + sizeof(WCHAR)) * 2; > + } > + /* Test star */ > + else if (Expression->Buffer[ExpressionPosition / sizeof(WCHAR)] == L'*') > + { > + BackTracking[BackTrackingPosition++] = ExpressionPosition * 2; > + BackTracking[BackTrackingPosition++] = (ExpressionPosition * 2) + 3; > + continue; > + } > + /* Check DOS_STAR */ > + else if (Expression->Buffer[ExpressionPosition / sizeof(WCHAR)] == DOS_STAR) > + { > + /* Look for last dot */ > + DontSkipDot = TRUE; > + if (!EndOfName && Name->Buffer[NamePosition] == '.') > + { > + for (Position = NamePosition - 1; Position < Name->Length; Position++) > + { > + if (Name->Buffer[Position] == L'.') > + { > + DontSkipDot = FALSE; > + break; > + } > + } > + } > + > + if (EndOfName || Name->Buffer[NamePosition] != L'.' || !DontSkipDot) > + BackTracking[BackTrackingPosition++] = ExpressionPosition * 2; > + > + BackTracking[BackTrackingPosition++] = (ExpressionPosition * 2) + 3; > + continue; > + } > + /* Check DOS_DOT */ > + else if (Expression->Buffer[ExpressionPosition / sizeof(WCHAR)] == DOS_DOT) > + { > + if (EndOfName) continue; > + > + if (Name->Buffer[NamePosition] == L'.') > + BackTracking[BackTrackingPosition++] = (ExpressionPosition + sizeof(WCHAR)) * 2; > + } > + /* Check DOS_QM */ > + else if (Expression->Buffer[ExpressionPosition / sizeof(WCHAR)] == DOS_QM) > + { > + if (EndOfName || Name->Buffer[NamePosition] == L'.') continue; > + > + BackTracking[BackTrackingPosition++] = (ExpressionPosition + sizeof(WCHAR)) * 2; > + } > + > + /* Leave from loop */ > break; > } > - ExpressionPosition++; > - } > - } > - > - if (BackTracking != BackTrackingBuffer) > - { > + > + for (Position = 0; MatchingChars > OldBackTrackingPosition && Position < BackTrackingPosition; Position++) > + { > + while (MatchingChars > OldBackTrackingPosition && > + BackTracking[Position] > OldBackTracking[OldBackTrackingPosition]) > + { > + ++OldBackTrackingPosition; > + } > + } > + } > + > + /* Swap pointers */ > + BackTrackingSwap = BackTracking; > + BackTracking = OldBackTracking; > + OldBackTracking = BackTrackingSwap; > + } > + > + /* Store result value */ > + Result = (OldBackTracking[MatchingChars - 1] == (Expression->Length * 2)); > + > + /* Frees the memory if necessary */ > + if (BackTracking != BackTrackingBuffer && BackTracking != OldBackTrackingBuffer) > ExFreePoolWithTag(BackTracking, 'nrSF'); > - } > - if (DosBackTracking != DosBackTrackingBuffer) > - { > - ExFreePoolWithTag(DosBackTracking, 'nrSF'); > - } > - > - return (ExpressionPosition == Expression->Length / sizeof(WCHAR) && NamePosition == Name->Length / sizeof(WCHAR)); > + if (OldBackTracking != BackTrackingBuffer && OldBackTracking != OldBackTrackingBuffer) > + ExFreePoolWithTag(OldBackTracking, 'nrSF'); > + > + return Result; > } > > /* PUBLIC FUNCTIONS **********************************************************/ > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

8 years, 6 months

1
0
0 0

Re: [ros-dev] KD trace during ROS installation

by Love Nystrom

Thanks Thomas, Yes and No... I added Options=/DEBUG /DEBUGPORT=COM2 /BAUDRATE=115200 /SOS / KDSERIAL which ended up on the BootCD all right, but it seems KD is never brought in, or doesn't use the settings from freeldr.ini on the BootCD, so no trace :/ (Ok, /SOS was perhaps a bit over the top, but anyway.) Do you know where the source is for what becomes 'freeldr.ini' on the HD after installation? If I can modify that, I can at least get a trace on the later phases of installation, after ROS boots from HD. Then I might get a hint on why the Wine Gecko installer is broken. (It waits forever for whatever it might be.. Lucky it can be canceled.) Speaking of which, shouldn't the Wine Gecko installer be included in the RosApps list so one can install it later? ATM it isn't. Best Regards L. On 2016-09-27 19.00, Thomas Faber <thomas.faber(a)reactos.org> wrote: > You should be able to simply add an > Options=... > line to the [Setup] section in boot/bootdata/bootcd.ini to modify > the setup's freeldr options. That file becomes freeldr.ini in the root > dir of the BootCD. > > > On 2016-09-27 12:21, Love Nystrom wrote: >> >Good afternoon gentlemen.. >> > >> >Can anyone tell me at what point during ROS installation KD becomes >> >operative? >> >And if there is a way to change the default KD COM port from COM1 to COM2 >> >in order to trace KD output during installation? >> > >> >(I run my ROS tests on VMware with a com0com connection from ReactOS COM2 >> >to my host machine, which works fine after install is complete and I can >> >edit freeldr.ini, >> >but I'd like to be able to collect KD output during installation as well.) >> > >> >(COM1 is not an option, since it's a physical port on both host and guest.) >> > >> >Do I have to patch KD itself ? >> > >> >Best Regards >> >L. -- There is one thing stronger than all the armies in the world, and that's an idea whose time has come. [Victor Hugo]

8 years, 6 months

1
0
0 0

KD trace during ROS installation

by Love Nystrom

Good afternoon gentlemen.. Can anyone tell me at what point during ROS installation KD becomes operative? And if there is a way to change the default KD COM port from COM1 to COM2 in order to trace KD output during installation? (I run my ROS tests on VMware with a com0com connection from ReactOS COM2 to my host machine, which works fine after install is complete and I can edit freeldr.ini, but I'd like to be able to collect KD output during installation as well.) (COM1 is not an option, since it's a physical port on both host and guest.) Do I have to patch KD itself ? Best Regards L.

8 years, 6 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 72787: [NTOSKRNL] Remove unneeded sanity checks

by Love Nystrom

Agreed.. When the assignment and assert are separated by a call of X distance, the assert is certainly warranted. Just not as it stands in ke_x.h Perhaps you could factorize as suggested, Dmitri? Best regards L. On 2016-09-26 10.28, ros-dev-request(a)reactos.org wrote: > Rationale is simple: > > The real headers contain a KeEnterCriticalRegionThread function, which > has this assert, and a KeEnterCriticalRegion function, which calls > that function with KeGetCurrentThread() at input. This is an > optimization such that if you already have the current thread of > interest somewhere, you can call KeEnterCriticalRegionThread and avoid > reading from FS or GS again. ReactOS combines these two functions in > one, and as such the ASSERT appears pointless. Factoring the functions > would've been the correct approach -- not removing the ASSERT. > > Best regards, > Alex Ionescu -- There is one thing stronger than all the armies in the world, and that's an idea whose time has come. [Victor Hugo]

8 years, 7 months

1
0
0 0

Re: [ros-dev] Ros-dev Digest, Vol 145, Issue 16

by Love Nystrom

Agreed.. When the assignment and assert are separated by a call of X distance, the assert is certainly warranted. Just not as it stands in ke_x.h Perhaps you could factorize as suggested, Dmitri? Best regards L. On 2016-09-26 10.28, ros-dev-request(a)reactos.org wrote: > Rationale is simple: > > The real headers contain a KeEnterCriticalRegionThread function, which > has this assert, and a KeEnterCriticalRegion function, which calls > that function with KeGetCurrentThread() at input. This is an > optimization such that if you already have the current thread of > interest somewhere, you can call KeEnterCriticalRegionThread and avoid > reading from FS or GS again. ReactOS combines these two functions in > one, and as such the ASSERT appears pointless. Factoring the functions > would've been the correct approach -- not removing the ASSERT. > > Best regards, > Alex Ionescu -- There is one thing stronger than all the armies in the world, and that's an idea whose time has come. [Victor Hugo]

8 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 72787: [NTOSKRNL] Remove unneeded sanity checks

by Alex Ionescu

Rationale is simple: The real headers contain a KeEnterCriticalRegionThread function, which has this assert, and a KeEnterCriticalRegion function, which calls that function with KeGetCurrentThread() at input. This is an optimization such that if you already have the current thread of interest somewhere, you can call KeEnterCriticalRegionThread and avoid reading from FS or GS again. ReactOS combines these two functions in one, and as such the ASSERT appears pointless. Factoring the functions would've been the correct approach -- not removing the ASSERT. Best regards, Alex Ionescu On Sun, Sep 25, 2016 at 8:13 PM, Love Nystrom <love.nystrom(a)gmail.com> wrote: > I don't want to trod on anyone's tail, but > assigning _Thread = KeGetCurrentThread(), and > then asserting _Thread == KeGetCurrentThread() > on the next line does seem excessively myopic, yes ? > > Unless you expect KeGetCurrentThread() to be fubar > and return rand(), in which case the assert should be removed > when KeGetCurrentThread() gets it's head on straight. > > As to the talent, or lack thereof, of MS programmers, > we might talk about it if we ever have a table with some > beer on it between us. > > They're not *all* wrong.. no ;) > L. > > On 2016-09-24 23.23, ros-dev-request(a)reactos.org wrote: > > Subject: > Re: [ros-dev] [ros-diffs] [dchapyshev] 72787: [NTOSKRNL] Remove unneeded > sanity checks > > From: > Alex Ionescu <ionucu(a)videotron.ca> <ionucu(a)videotron.ca> > > Date: > 2016-09-24 21.29 > > To: > ReactOS Development List <ros-dev(a)reactos.org> <ros-dev(a)reactos.org> > > CC: > Linda Wang <ros-diffs(a)reactos.org> <ros-diffs(a)reactos.org> > > Thanks for removing stuff that exists in the NT kernel as sanity > checks -- the entire MS dev team must be wrong, thanks for correcting > them all :) > > Make sure not to ask "anyone can explain these checks? they seem > useless to me" when removing stuff like this. > Best regards, > Alex Ionescu > > > On Sat, Sep 24, 2016 at 2:30 AM, <dchapyshev(a)svn.reactos.org> <dchapyshev(a)svn.reactos.org> wrote: > > > Author: dchapyshev> Date: Sat Sep 24 09:30:06 2016> New Revision: 72787>> URL: http://svn.reactos.org/svn/reactos?rev=72787&view=rev> Log:> [NTOSKRNL] Remove unneeded sanity checks>> Modified:> trunk/reactos/ntoskrnl/include/internal/ke_x.h>> Modified: trunk/reactos/ntoskrnl/include/internal/ke_x.h> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/…> ==============================================================================> --- trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] (original)> +++ trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] Sat Sep 24 09:30:06 2016> @@ -25,7 +25,6 @@> \> /* Sanity checks */ \> ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \> - ASSERT(_Thread == KeGetCurrentThread()); \> ASSERT((_Thread->SpecialApcDisable <= 0) && \> (_Thread->SpecialApcDisable != -32768)); \> \> @@ -42,7 +41,6 @@> \> /* Sanity checks */ \> ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \> - ASSERT(_Thread == KeGetCurrentThread()); \> ASSERT(_Thread->SpecialApcDisable < 0); \> \> /* Leave region and check if APCs are OK now */ \> @@ -66,7 +64,6 @@> PKTHREAD _Thread = KeGetCurrentThread(); \> \> /* Sanity checks */ \> - ASSERT(_Thread == KeGetCurrentThread()); \> ASSERT((_Thread->KernelApcDisable <= 0) && \> (_Thread->KernelApcDisable != -32768)); \> \> @@ -82,7 +79,6 @@> PKTHREAD _Thread = KeGetCurrentThread(); \> \> /* Sanity checks */ \> - ASSERT(_Thread == KeGetCurrentThread()); \> ASSERT(_Thread->KernelApcDisable < 0); \> \> /* Enable Kernel APCs */ \>> > > > -- > There is one thing stronger than all the armies in the world, > and that's an idea whose time has come. [Victor Hugo] > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > >

8 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 72787: [NTOSKRNL] Remove unneeded sanity checks

by Love Nystrom

I don't want to trod on anyone's tail, but assigning _Thread = KeGetCurrentThread(), and then asserting _Thread == KeGetCurrentThread() on the next line does seem excessively myopic, yes ? Unless you expect KeGetCurrentThread() to be fubar and return rand(), in which case the assert should be removed when KeGetCurrentThread() gets it's head on straight. As to the talent, or lack thereof, of MS programmers, we might talk about it if we ever have a table with some beer on it between us. They're not *all* wrong.. no ;) L. On 2016-09-24 23.23, ros-dev-request(a)reactos.org wrote: > Subject: > Re: [ros-dev] [ros-diffs] [dchapyshev] 72787: [NTOSKRNL] Remove > unneeded sanity checks > From: > Alex Ionescu <ionucu(a)videotron.ca> > Date: > 2016-09-24 21.29 > > To: > ReactOS Development List <ros-dev(a)reactos.org> > CC: > Linda Wang <ros-diffs(a)reactos.org> > > > Thanks for removing stuff that exists in the NT kernel as sanity > checks -- the entire MS dev team must be wrong, thanks for correcting > them all:) > > Make sure not to ask "anyone can explain these checks? they seem > useless to me" when removing stuff like this. > Best regards, > Alex Ionescu > > > On Sat, Sep 24, 2016 at 2:30 AM,<dchapyshev(a)svn.reactos.org> wrote: >> >Author: dchapyshev >> >Date: Sat Sep 24 09:30:06 2016 >> >New Revision: 72787 >> > >> >URL:http://svn.reactos.org/svn/reactos?rev=72787&view=rev >> >Log: >> >[NTOSKRNL] Remove unneeded sanity checks >> > >> >Modified: >> > trunk/reactos/ntoskrnl/include/internal/ke_x.h >> > >> >Modified: trunk/reactos/ntoskrnl/include/internal/ke_x.h >> >URL:http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/inter… >> >============================================================================== >> >--- trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] (original) >> >+++ trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] Sat Sep 24 09:30:06 2016 >> >@@ -25,7 +25,6 @@ >> > \ >> > /* Sanity checks */ \ >> > ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \ >> >- ASSERT(_Thread == KeGetCurrentThread()); \ >> > ASSERT((_Thread->SpecialApcDisable <= 0) && \ >> > (_Thread->SpecialApcDisable != -32768)); \ >> > \ >> >@@ -42,7 +41,6 @@ >> > \ >> > /* Sanity checks */ \ >> > ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \ >> >- ASSERT(_Thread == KeGetCurrentThread()); \ >> > ASSERT(_Thread->SpecialApcDisable < 0); \ >> > \ >> > /* Leave region and check if APCs are OK now */ \ >> >@@ -66,7 +64,6 @@ >> > PKTHREAD _Thread = KeGetCurrentThread(); \ >> > \ >> > /* Sanity checks */ \ >> >- ASSERT(_Thread == KeGetCurrentThread()); \ >> > ASSERT((_Thread->KernelApcDisable <= 0) && \ >> > (_Thread->KernelApcDisable != -32768)); \ >> > \ >> >@@ -82,7 +79,6 @@ >> > PKTHREAD _Thread = KeGetCurrentThread(); \ >> > \ >> > /* Sanity checks */ \ >> >- ASSERT(_Thread == KeGetCurrentThread()); \ >> > ASSERT(_Thread->KernelApcDisable < 0); \ >> > \ >> > /* Enable Kernel APCs */ \ >> > >> > -- There is one thing stronger than all the armies in the world, and that's an idea whose time has come. [Victor Hugo]

8 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 72787: [NTOSKRNL] Remove unneeded sanity checks

by Alex Ionescu

There are no disadvantages. Someone though it would be fun to remove useful assertions because they don't really understand them. Best regards, Alex Ionescu On Sat, Sep 24, 2016 at 9:23 AM, Michael Fritscher <michael(a)fritscher.net> wrote: > Hi, > > hmm, what are disadvantages of these checks? If MS uses them as well these > shouldn't break anything. > > Perfomancewise there shouldn't be a difference, and in release builds they > are disabled anyways, aren't they? > > I only want to get a better unterstanding ;-) > > Best regards, > Michael > >> Thanks for removing stuff that exists in the NT kernel as sanity >> checks -- the entire MS dev team must be wrong, thanks for correcting >> them all :) >> >> Make sure not to ask "anyone can explain these checks? they seem >> useless to me" when removing stuff like this. >> Best regards, >> Alex Ionescu >> >> >> On Sat, Sep 24, 2016 at 2:30 AM, <dchapyshev(a)svn.reactos.org> wrote: >>> Author: dchapyshev >>> Date: Sat Sep 24 09:30:06 2016 >>> New Revision: 72787 >>> >>> URL: http://svn.reactos.org/svn/reactos?rev=72787&view=rev >>> Log: >>> [NTOSKRNL] Remove unneeded sanity checks >>> >>> Modified: >>> trunk/reactos/ntoskrnl/include/internal/ke_x.h >>> >>> Modified: trunk/reactos/ntoskrnl/include/internal/ke_x.h >>> URL: >>> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… >>> ============================================================================== >>> --- trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] >>> (original) >>> +++ trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] Sat >>> Sep 24 09:30:06 2016 >>> @@ -25,7 +25,6 @@ >>> \ >>> /* Sanity checks */ >>> \ >>> ASSERT(KeGetCurrentIrql() <= APC_LEVEL); >>> \ >>> - ASSERT(_Thread == KeGetCurrentThread()); >>> \ >>> ASSERT((_Thread->SpecialApcDisable <= 0) && >>> \ >>> (_Thread->SpecialApcDisable != -32768)); >>> \ >>> \ >>> @@ -42,7 +41,6 @@ >>> \ >>> /* Sanity checks */ >>> \ >>> ASSERT(KeGetCurrentIrql() <= APC_LEVEL); >>> \ >>> - ASSERT(_Thread == KeGetCurrentThread()); >>> \ >>> ASSERT(_Thread->SpecialApcDisable < 0); >>> \ >>> \ >>> /* Leave region and check if APCs are OK now */ >>> \ >>> @@ -66,7 +64,6 @@ >>> PKTHREAD _Thread = KeGetCurrentThread(); >>> \ >>> \ >>> /* Sanity checks */ >>> \ >>> - ASSERT(_Thread == KeGetCurrentThread()); >>> \ >>> ASSERT((_Thread->KernelApcDisable <= 0) && >>> \ >>> (_Thread->KernelApcDisable != -32768)); >>> \ >>> \ >>> @@ -82,7 +79,6 @@ >>> PKTHREAD _Thread = KeGetCurrentThread(); >>> \ >>> \ >>> /* Sanity checks */ >>> \ >>> - ASSERT(_Thread == KeGetCurrentThread()); >>> \ >>> ASSERT(_Thread->KernelApcDisable < 0); >>> \ >>> \ >>> /* Enable Kernel APCs */ >>> \ >>> >>> >> >> _______________________________________________ >> 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

8 years, 7 months

2
1
0 0

Re :[ros-bugs] [jira] (CORE-12020) We're not able to perform DPH test runs anymore

by Sylvain Petreolle

Don't change code when runtime conditions evolve.Just give more RAM to the bot and it's over. Envoyé depuis Yahoo Mail pour Android Le jeu. j sept. PM à 18:01, Thomas Faber (JIRA)<noreply(a)reactos.org> a écrit : [ https://jira.reactos.org/browse/CORE-12020?page=com.atlassian.jira.plugin.s… ] Thomas Faber commented on CORE-12020: ------------------------------------- First stage is extremely heavy on memory due to inf parsing. One thing that helped in a similar situation was to separate caroots.inf from registry.inf and have it parsed separately. We should probably do that in trunk... > We're not able to perform DPH test runs anymore > ----------------------------------------------- > > Key: CORE-12020 > URL: https://jira.reactos.org/browse/CORE-12020 > Project: Core ReactOS > Issue Type: Bug > Reporter: Amine Khaldi > Assignee: Bug Zilla > Labels: REGRESSION > > https://build.reactos.org/builders/Test%20KVM/builds/15147/steps/test/logs/… > https://jira.reactos.org/secure/attachment/37125/ was used with patchbot. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira _______________________________________________ Ros-bugs mailing list Ros-bugs(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-bugs

8 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [cwittich] 72792: [CRYPTNET] disable broken code

by Thomas Faber

Could you elaborate on what makes it broken? Link to a bug perhaps? On 2016-09-24 13:39, cwittich(a)svn.reactos.org wrote: > Author: cwittich > Date: Sat Sep 24 11:39:17 2016 > New Revision: 72792 > > URL: http://svn.reactos.org/svn/reactos?rev=72792&view=rev > Log: > [CRYPTNET] disable broken code > > Modified: > trunk/reactos/dll/win32/cryptnet/cryptnet_main.c > > Modified: trunk/reactos/dll/win32/cryptnet/cryptnet_main.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/cryptnet/cryptne… > ============================================================================== > --- trunk/reactos/dll/win32/cryptnet/cryptnet_main.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/cryptnet/cryptnet_main.c [iso-8859-1] Sat Sep 24 11:39:17 2016 > @@ -1025,6 +1025,7 @@ > components.dwUrlPathLength + 1); > hFile = CreateFileW(path, GENERIC_READ, FILE_SHARE_READ, > NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > +#ifndef __REACTOS__ > if (hFile == INVALID_HANDLE_VALUE) > { > /* Try again on the current drive */ > @@ -1049,6 +1050,7 @@ > } > } > } > +#endif > if (hFile != INVALID_HANDLE_VALUE) > { > if ((ret = CRYPT_GetObjectFromFile(hFile, pObject))) > >

8 years, 7 months

3
6
0 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 72787: [NTOSKRNL] Remove unneeded sanity checks

by Alex Ionescu

Thanks for removing stuff that exists in the NT kernel as sanity checks -- the entire MS dev team must be wrong, thanks for correcting them all :) Make sure not to ask "anyone can explain these checks? they seem useless to me" when removing stuff like this. Best regards, Alex Ionescu On Sat, Sep 24, 2016 at 2:30 AM, <dchapyshev(a)svn.reactos.org> wrote: > Author: dchapyshev > Date: Sat Sep 24 09:30:06 2016 > New Revision: 72787 > > URL: http://svn.reactos.org/svn/reactos?rev=72787&view=rev > Log: > [NTOSKRNL] Remove unneeded sanity checks > > Modified: > trunk/reactos/ntoskrnl/include/internal/ke_x.h > > Modified: trunk/reactos/ntoskrnl/include/internal/ke_x.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] Sat Sep 24 09:30:06 2016 > @@ -25,7 +25,6 @@ > \ > /* Sanity checks */ \ > ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \ > - ASSERT(_Thread == KeGetCurrentThread()); \ > ASSERT((_Thread->SpecialApcDisable <= 0) && \ > (_Thread->SpecialApcDisable != -32768)); \ > \ > @@ -42,7 +41,6 @@ > \ > /* Sanity checks */ \ > ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \ > - ASSERT(_Thread == KeGetCurrentThread()); \ > ASSERT(_Thread->SpecialApcDisable < 0); \ > \ > /* Leave region and check if APCs are OK now */ \ > @@ -66,7 +64,6 @@ > PKTHREAD _Thread = KeGetCurrentThread(); \ > \ > /* Sanity checks */ \ > - ASSERT(_Thread == KeGetCurrentThread()); \ > ASSERT((_Thread->KernelApcDisable <= 0) && \ > (_Thread->KernelApcDisable != -32768)); \ > \ > @@ -82,7 +79,6 @@ > PKTHREAD _Thread = KeGetCurrentThread(); \ > \ > /* Sanity checks */ \ > - ASSERT(_Thread == KeGetCurrentThread()); \ > ASSERT(_Thread->KernelApcDisable < 0); \ > \ > /* Enable Kernel APCs */ \ > >

8 years, 7 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 72751: [SECUR32][NTOS]: Update the LSA export signatures for the functions that are implemented in the "lsalib" library. [LSALIB] - Add old-school annotations (as we currently do in our ...

by Thomas Faber

On 2016-09-21 01:43, hbelusca(a)svn.reactos.org wrote: > @@ -300,25 +268,53 @@ > * @implemented > */ > NTSTATUS > -WINAPI > -LsaRegisterLogonProcess(PLSA_STRING LsaLogonProcessName, > - PHANDLE Handle, > - PLSA_OPERATIONAL_MODE OperationalMode) > -{ > +NTAPI > +LsaRegisterLogonProcess(IN PLSA_STRING LogonProcessName, > + OUT PHANDLE LsaHandle, > + OUT PLSA_OPERATIONAL_MODE OperationalMode) > +{ > + NTSTATUS Status; > + HANDLE EventHandle; > UNICODE_STRING PortName; // = RTL_CONSTANT_STRING(L"\\LsaAuthenticationPort"); > + OBJECT_ATTRIBUTES ObjectAttributes; > SECURITY_QUALITY_OF_SERVICE SecurityQos; > LSA_CONNECTION_INFO ConnectInfo; > ULONG ConnectInfoLength = sizeof(ConnectInfo); > - NTSTATUS Status; > > DPRINT("LsaRegisterLogonProcess()\n"); > > /* Check the logon process name length */ > - if (LsaLogonProcessName->Length > LSASS_MAX_LOGON_PROCESS_NAME_LENGTH) > + if (LogonProcessName->Length > LSASS_MAX_LOGON_PROCESS_NAME_LENGTH) > return STATUS_NAME_TOO_LONG; > > - RtlInitUnicodeString(&PortName, > - L"\\LsaAuthenticationPort"); > + /* > + * First check whether the LSA server is ready: > + * open the LSA event and wait on it. > + */ > + // Note that we just reuse the 'PortName' variable here. Please don't? This is not the 80s. > + RtlInitUnicodeString(&PortName, L"\\SECURITY\\LSA_AUTHENTICATION_INITIALIZED"); > + InitializeObjectAttributes(&ObjectAttributes, > + &PortName, > + OBJ_CASE_INSENSITIVE, > + NULL, > + NULL); > + Status = NtOpenEvent(&EventHandle, SYNCHRONIZE, &ObjectAttributes); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("NtOpenEvent failed (Status 0x%08lx)\n", Status); > + return Status; > + } > + > + Status = NtWaitForSingleObject(EventHandle, TRUE, NULL); > + NtClose(EventHandle); If you want to use this in kernel mode, you also have to program for kernel mode. These should be Zw calls and you need OBJ_KERNEL_HANDLE. > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("NtWaitForSingleObject failed (Status 0x%08lx)\n", Status); > + return Status; > + } > + > + /* Now attempt the connection */ > + RtlInitUnicodeString(&PortName, L"\\LsaAuthenticationPort"); > > SecurityQos.Length = sizeof(SecurityQos); > SecurityQos.ImpersonationLevel = SecurityIdentification; > @@ -326,13 +322,13 @@ > SecurityQos.EffectiveOnly = TRUE; > > strncpy(ConnectInfo.LogonProcessNameBuffer, > - LsaLogonProcessName->Buffer, > - LsaLogonProcessName->Length); > - ConnectInfo.Length = LsaLogonProcessName->Length; > - ConnectInfo.LogonProcessNameBuffer[ConnectInfo.Length] = '\0'; > + LogonProcessName->Buffer, > + LogonProcessName->Length); > + ConnectInfo.Length = LogonProcessName->Length; > + ConnectInfo.LogonProcessNameBuffer[ConnectInfo.Length] = ANSI_NULL; > ConnectInfo.CreateContext = TRUE; > > - Status = ZwConnectPort(Handle, > + Status = ZwConnectPort(LsaHandle, > &PortName, > &SecurityQos, > NULL, > @@ -357,3 +353,42 @@ > return ConnectInfo.Status; > } > > + > +/* > + * @implemented > + */ > +NTSTATUS > +NTAPI > +LsaDeregisterLogonProcess(IN HANDLE LsaHandle) > +{ > + NTSTATUS Status; > + LSA_API_MSG ApiMessage; > + > + DPRINT("LsaDeregisterLogonProcess()\n"); > + > + ApiMessage.ApiNumber = LSASS_REQUEST_DEREGISTER_LOGON_PROCESS; > + ApiMessage.h.u1.s1.DataLength = LSA_PORT_DATA_SIZE(ApiMessage.DeregisterLogonProcess); > + ApiMessage.h.u1.s1.TotalLength = LSA_PORT_MESSAGE_SIZE; > + ApiMessage.h.u2.ZeroInit = 0; > + > + Status = ZwRequestWaitReplyPort(LsaHandle, > + (PPORT_MESSAGE)&ApiMessage, > + (PPORT_MESSAGE)&ApiMessage); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("ZwRequestWaitReplyPort() failed (Status 0x%08lx)\n", Status); > + return Status; > + } > + > + if (!NT_SUCCESS(ApiMessage.Status)) > + { > + DPRINT1("ZwRequestWaitReplyPort() failed (ApiMessage.Status 0x%08lx)\n", ApiMessage.Status); > + return ApiMessage.Status; > + } > + > + NtClose(LsaHandle); A handle opened with ZwXxx shouldn't be closed with NtClose. > + > + DPRINT("LsaDeregisterLogonProcess() done (Status 0x%08lx)\n", Status); > + > + return Status; > +}

8 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [akhaldi] 72735: [MSWSOCK] Partially implement Name Service Provider in mswsock. Brought to you by Andreas Maier aka andy-123 with small fixes by Peter Hater and formatting by me. CORE-10024 CORE-1...

by Alex Ionescu

My winsock branch already has full support for an NSP. It's 8 years old now, maybe someone should mergei t. Best regards, Alex Ionescu On Sun, Sep 18, 2016 at 2:21 PM, <akhaldi(a)svn.reactos.org> wrote: > Author: akhaldi > Date: Sun Sep 18 21:21:28 2016 > New Revision: 72735 > > URL: http://svn.reactos.org/svn/reactos?rev=72735&view=rev > Log: > [MSWSOCK] Partially implement Name Service Provider in mswsock. Brought to you by Andreas Maier aka andy-123 with small fixes by Peter Hater and formatting by me. CORE-10024 CORE-10440 > > Added: > trunk/reactos/dll/win32/mswsock/mswhelper.c (with props) > trunk/reactos/dll/win32/mswsock/mswhelper.h (with props) > trunk/reactos/dll/win32/mswsock/nsplookup.c (with props) > Modified: > trunk/reactos/dll/win32/mswsock/CMakeLists.txt > trunk/reactos/dll/win32/mswsock/stubs.c > > Modified: trunk/reactos/dll/win32/mswsock/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/mswsock/CMakeLis… > ============================================================================== > --- trunk/reactos/dll/win32/mswsock/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/mswsock/CMakeLists.txt [iso-8859-1] Sun Sep 18 21:21:28 2016 > @@ -5,6 +5,8 @@ > > list(APPEND SOURCE > extensions.c > + mswhelper.c > + nsplookup.c > stubs.c > precomp.h) > > @@ -13,7 +15,7 @@ > mswsock.rc > ${CMAKE_CURRENT_BINARY_DIR}/mswsock.def) > > -set_module_type(mswsock win32dll UNICODE) > -add_importlibs(mswsock ws2_32 msvcrt kernel32) > +set_module_type(mswsock win32dll) > +add_importlibs(mswsock ws2_32 dnsapi msvcrt kernel32) > add_pch(mswsock precomp.h SOURCE) > add_cd_file(TARGET mswsock DESTINATION reactos/system32 FOR all) > > Added: trunk/reactos/dll/win32/mswsock/mswhelper.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/mswsock/mswhelpe… > ============================================================================== > --- trunk/reactos/dll/win32/mswsock/mswhelper.c (added) > +++ trunk/reactos/dll/win32/mswsock/mswhelper.c [iso-8859-1] Sun Sep 18 21:21:28 2016 > @@ -0,0 +1,576 @@ > + > +#include "precomp.h" > + > +#include <winuser.h> > +#include <winnls.h> > +#include <wchar.h> > +#include <sal.h> > + > +#include "mswhelper.h" > + > +#define MSW_BUFSIZE 512 > +#define MAX_ARRAY_SIZE 5 > + > +void > +mswBufferInit(_Inout_ PMSW_BUFFER mswBuf, > + _In_ BYTE* buffer, > + _In_ DWORD bufferSize) > +{ > + RtlZeroMemory(mswBuf, sizeof(*mswBuf)); > + RtlZeroMemory(buffer, bufferSize); > + mswBuf->bytesMax = bufferSize; > + mswBuf->buffer = buffer; > + mswBuf->bufendptr = buffer; > + mswBuf->bufok = TRUE; > +} > + > +BOOL > +mswBufferCheck(_Inout_ PMSW_BUFFER mswBuf, > + _In_ DWORD count) > +{ > + if (mswBuf->bytesUsed + count <= mswBuf->bytesMax) > + return TRUE; > + > + mswBuf->bufok = FALSE; > + return FALSE; > +} > + > +BOOL > +mswBufferIncUsed(_Inout_ PMSW_BUFFER mswBuf, > + _In_ DWORD count) > +{ > + if (!mswBufferCheck(mswBuf, count)) > + return FALSE; > + > + mswBuf->bytesUsed += count; > + mswBuf->bufendptr += count; > + return TRUE; > +} > + > +inline > +BYTE* > +mswBufferEndPtr(_Inout_ PMSW_BUFFER mswBuf) > +{ > + return mswBuf->bufendptr; > +} > + > +BOOL > +mswBufferAppend(_Inout_ PMSW_BUFFER mswBuf, > + _In_ void *dataToAppend, > + _In_ DWORD dataSize) > +{ > + if (!mswBufferCheck(mswBuf, dataSize)) > + return FALSE; > + > + RtlCopyMemory(mswBuf->bufendptr, dataToAppend, dataSize); > + mswBuf->bytesUsed += dataSize; > + mswBuf->bufendptr += dataSize; > + > + return TRUE; > +} > + > +BOOL mswBufferAppendStrA(_Inout_ PMSW_BUFFER mswBuf, > + _In_ char* str) > +{ > + return mswBufferAppend(mswBuf, str, strlen(str) + sizeof(char)); > +} > + > +BOOL > +mswBufferAppendStrW(_Inout_ PMSW_BUFFER mswBuf, > + _In_ WCHAR* str) > +{ > + int bytelen = (wcslen(str) + 1) * sizeof(WCHAR); > + return mswBufferAppend(mswBuf, str, bytelen); > +} > + > +BOOL > +mswBufferAppendPtr(_Inout_ PMSW_BUFFER mswBuf, > + _In_ void* ptr) > +{ > + return mswBufferAppend(mswBuf, &ptr, sizeof(ptr)); > +} > + > +/* lst = pointer to pointer of items > + > + *lst[0] = 1st item > + *lst[1] = 2nd item > + ... > + lst[n] = NULL = End of List > + > + itemLength = data in Bytes for each item. > + > + ptrofs = delta relative to mswBuf.buffer > +*/ > +BOOL > +mswBufferAppendLst(_Inout_ PMSW_BUFFER mswBuf, > + _In_ void **lst, > + _In_ DWORD itemByteLength, > + _In_opt_ int ptrofs) > +{ > + DWORD lstItemCount; > + DWORD lstByteSize; > + DWORD lstDataPos; > + DWORD i1; > + UINT_PTR *ptrSrcLstPos; > + > + /* calculate size of list */ > + ptrSrcLstPos = (UINT_PTR*)lst; > + lstItemCount = 0; > + while (*ptrSrcLstPos != (UINT_PTR)NULL) > + { > + lstItemCount++; > + ptrSrcLstPos++; > + } > + > + lstByteSize = ((lstItemCount + 1) * sizeof(UINT_PTR)) + /* item-pointer + null-ptr (for end) */ > + (lstItemCount * itemByteLength); /* item-data */ > + > + if (mswBuf->bytesUsed + lstByteSize > mswBuf->bytesMax) > + return FALSE; > + > + /* calculate position for the data of the first item */ > + lstDataPos = ((lstItemCount + 1) * sizeof(UINT_PTR)) + > + (DWORD)mswBufferEndPtr(mswBuf); > + /* add ptrofs */ > + lstDataPos += ptrofs; > + > + /* write array of Pointer to data */ > + for (i1 = 0; i1 < lstItemCount; i1++) > + { > + if (!mswBufferAppendPtr(mswBuf, (void*)lstDataPos)) > + return FALSE; > + > + lstDataPos += sizeof(UINT_PTR); > + } > + > + /* end of list */ > + if (!mswBufferAppendPtr(mswBuf, NULL)) > + return FALSE; > + > + /* write data */ > + ptrSrcLstPos = (UINT_PTR*)lst; > + for (i1 = 0; i1 < lstItemCount; i1++) > + { > + mswBufferAppend(mswBuf, *(BYTE**)ptrSrcLstPos, itemByteLength); > + ptrSrcLstPos++; > + } > + return mswBuf->bufok; > +} > + > +BOOL > +mswBufferAppendStrLstA(_Inout_ PMSW_BUFFER mswBuf, > + _In_ void **lst, > + _In_opt_ int ptrofs) > +{ > + DWORD lstItemLen[MAX_ARRAY_SIZE]; > + DWORD lstItemCount; > + DWORD lstByteSize; > + DWORD lstDataPos; > + DWORD lstDataSize; > + DWORD i1; > + UINT_PTR *ptrSrcLstPos; > + > + /* calculate size of list */ > + ptrSrcLstPos = (UINT_PTR*)lst; > + lstItemCount = 0; > + lstDataSize = 0; > + > + while (*ptrSrcLstPos != (UINT_PTR)NULL) > + { > + if (lstItemCount >= MAX_ARRAY_SIZE) > + return FALSE; > + > + i1 = strlen((char*)*ptrSrcLstPos) + sizeof(char); > + lstItemLen[lstItemCount] = i1; > + lstItemCount++; > + lstDataSize += i1; > + ptrSrcLstPos++; > + } > + > + lstByteSize = ((lstItemCount + 1) * sizeof(UINT_PTR)) + /* item-pointer + null-ptr (for end) */ > + lstDataSize; /* item-data */ > + > + if (mswBuf->bytesUsed + lstByteSize > mswBuf->bytesMax) > + return FALSE; > + > + /* calculate position for the data of the first item */ > + lstDataPos = ((lstItemCount + 1) * sizeof(UINT_PTR)) + > + (DWORD)mswBufferEndPtr(mswBuf); > + > + /* add ptrofs */ > + lstDataPos += ptrofs; > + > + for (i1 = 0; i1 < lstItemCount; i1++) > + { > + if (!mswBufferAppendPtr(mswBuf, (void*)lstDataPos)) > + return FALSE; > + > + lstDataPos += lstItemLen[i1]; > + } > + > + /* end of list */ > + if (!mswBufferAppendPtr(mswBuf, NULL)) > + return FALSE; > + > + /* write data */ > + ptrSrcLstPos = (UINT_PTR*)lst; > + for (i1 = 0; i1 < lstItemCount; i1++) > + { > + if (!mswBufferAppendStrA(mswBuf, *(char**)ptrSrcLstPos)) > + return FALSE; > + > + ptrSrcLstPos++; > + } > + return mswBuf->bufok; > +} > + > +BOOL > +mswBufferAppendBlob_Hostent(_Inout_ PMSW_BUFFER mswBuf, > + _Inout_ LPWSAQUERYSETW lpRes, > + _In_ char* hostnameA, > + _In_ DWORD ip4addr) > +{ > + PHOSTENT phe; > + void* lst[2]; > + BYTE* bytesOfs; > + > + /* blob */ > + lpRes->lpBlob = (LPBLOB)mswBufferEndPtr(mswBuf); > + > + if (!mswBufferIncUsed(mswBuf, sizeof(*lpRes->lpBlob))) > + return FALSE; > + > + /* cbSize will be set later */ > + lpRes->lpBlob->cbSize = 0; > + lpRes->lpBlob->pBlobData = mswBufferEndPtr(mswBuf); > + > + /* hostent */ > + phe = (PHOSTENT)lpRes->lpBlob->pBlobData; > + bytesOfs = mswBufferEndPtr(mswBuf); > + > + if (!mswBufferIncUsed(mswBuf, sizeof(*phe))) > + return FALSE; > + > + phe->h_addrtype = AF_INET; > + phe->h_length = 4; /* 4 Byte (IPv4) */ > + > + /* aliases */ > + phe->h_aliases = (char**)(mswBufferEndPtr(mswBuf) - bytesOfs); > + > + if (!mswBufferAppendPtr(mswBuf, NULL)) > + return FALSE; > + > + /* addr_list */ > + RtlZeroMemory(lst, sizeof(lst)); > + > + if (ip4addr != 0) > + lst[0] = (void*)&ip4addr; > + > + phe->h_addr_list = (char**)(mswBufferEndPtr(mswBuf) - bytesOfs); > + > + if (!mswBufferAppendLst(mswBuf, lst, 4, -(DWORD)bytesOfs)) > + return FALSE; > + > + /* name */ > + phe->h_name = (char*)(mswBufferEndPtr(mswBuf) - bytesOfs); > + > + if (!mswBufferAppendStrA(mswBuf, hostnameA)) > + return FALSE; > + > + lpRes->lpBlob->cbSize = (DWORD)(mswBufferEndPtr(mswBuf) - bytesOfs); > + return mswBuf->bufok; > +} > + > +BOOL > +mswBufferAppendBlob_Servent(_Inout_ PMSW_BUFFER mswBuf, > + _Inout_ LPWSAQUERYSETW lpRes, > + _In_ char* serviceNameA, > + _In_ char** serviceAliasesA, > + _In_ char* protocolNameA, > + _In_ WORD port) > +{ > + PSERVENT pse; > + BYTE* bytesOfs; > + > + /* blob */ > + lpRes->lpBlob = (LPBLOB)mswBufferEndPtr(mswBuf); > + > + if (!mswBufferIncUsed(mswBuf, sizeof(*lpRes->lpBlob))) > + return FALSE; > + > + lpRes->lpBlob->cbSize = 0;//later > + lpRes->lpBlob->pBlobData = mswBufferEndPtr(mswBuf); > + > + /* servent */ > + pse = (LPSERVENT)lpRes->lpBlob->pBlobData; > + bytesOfs = mswBufferEndPtr(mswBuf); > + > + if (!mswBufferIncUsed(mswBuf, sizeof(*pse))) > + return FALSE; > + > + pse->s_aliases = (char**)(mswBufferEndPtr(mswBuf) - bytesOfs); > + > + if (!mswBufferAppendStrLstA(mswBuf, > + (void**)serviceAliasesA, > + -(DWORD)bytesOfs)) > + return FALSE; > + > + pse->s_name = (char*)(mswBufferEndPtr(mswBuf) - bytesOfs); > + > + if (!mswBufferAppendStrA(mswBuf, serviceNameA)) > + return FALSE; > + > + pse->s_port = htons(port); > + > + pse->s_proto = (char*)(mswBufferEndPtr(mswBuf) - bytesOfs); > + > + if (!mswBufferAppendStrA(mswBuf, protocolNameA)) > + return FALSE; > + > + lpRes->lpBlob->cbSize = (DWORD)(mswBufferEndPtr(mswBuf) - bytesOfs); > + return mswBuf->bufok; > +} > + > +BOOL > +mswBufferAppendAddr_AddrInfoW(_Inout_ PMSW_BUFFER mswBuf, > + _Inout_ LPWSAQUERYSETW lpRes, > + _In_ DWORD ip4addr) > +{ > + LPCSADDR_INFO paddrinfo; > + LPSOCKADDR_IN psa; > + > + lpRes->dwNumberOfCsAddrs = 1; > + lpRes->lpcsaBuffer = (LPCSADDR_INFO)mswBufferEndPtr(mswBuf); > + > + paddrinfo = lpRes->lpcsaBuffer; > + > + if (!mswBufferIncUsed(mswBuf, sizeof(*paddrinfo))) > + return FALSE; > + > + paddrinfo->LocalAddr.lpSockaddr = (LPSOCKADDR)mswBufferEndPtr(mswBuf); > + > + if (!mswBufferIncUsed(mswBuf, sizeof(*paddrinfo->LocalAddr.lpSockaddr))) > + return FALSE; > + > + paddrinfo->RemoteAddr.lpSockaddr = (LPSOCKADDR)mswBufferEndPtr(mswBuf); > + > + if (!mswBufferIncUsed(mswBuf, sizeof(*paddrinfo->RemoteAddr.lpSockaddr))) > + return FALSE; > + > + paddrinfo->iSocketType = SOCK_DGRAM; > + paddrinfo->iProtocol = IPPROTO_UDP; > + > + psa = (LPSOCKADDR_IN)paddrinfo->LocalAddr.lpSockaddr; > + paddrinfo->LocalAddr.iSockaddrLength = sizeof(*psa); > + psa->sin_family = AF_INET; > + psa->sin_port = 0; > + psa->sin_addr.s_addr = 0; > + RtlZeroMemory(psa->sin_zero, sizeof(psa->sin_zero)); > + > + psa = (LPSOCKADDR_IN)paddrinfo->RemoteAddr.lpSockaddr; > + paddrinfo->RemoteAddr.iSockaddrLength = sizeof(*psa); > + psa->sin_family = AF_INET; > + psa->sin_port = 0; > + psa->sin_addr.s_addr = ip4addr; > + RtlZeroMemory(psa->sin_zero, sizeof(psa->sin_zero)); > + > + return TRUE; > +} > + > +/* ansicode <-> unicode */ > +WCHAR* > +StrA2WHeapAlloc(_In_opt_ HANDLE hHeap, > + _In_ char* aStr) > +{ > + int aStrByteLen; > + int wStrByteLen; > + int charLen; > + int ret; > + WCHAR* wStr; > + > + if (aStr == NULL) > + return NULL; > + > + charLen = strlen(aStr) + 1; > + > + aStrByteLen = (charLen * sizeof(char)); > + wStrByteLen = (charLen * sizeof(WCHAR)); > + > + if (hHeap == 0) > + hHeap = GetProcessHeap(); > + > + wStr = HeapAlloc(hHeap, 0, wStrByteLen); > + if (wStr == NULL) > + { > + HeapFree(hHeap, 0, wStr); > + return NULL; > + } > + > + ret = MultiByteToWideChar(1252, > + 0, > + aStr, > + aStrByteLen, > + wStr, > + charLen); > + > + if (ret != charLen) > + { > + HeapFree(hHeap, 0, wStr); > + return NULL; > + } > + return wStr; > +} > + > +char* > +StrW2AHeapAlloc(_In_opt_ HANDLE hHeap, > + _In_ WCHAR* wStr) > +{ > + int charLen; > + int aStrByteLen; > + int ret; > + char* aStr; > + > + if (wStr == NULL) > + return NULL; > + > + charLen = wcslen(wStr) + 1; > + > + aStrByteLen = (charLen * sizeof(char)); > + > + if (hHeap == 0) > + hHeap = GetProcessHeap(); > + > + aStr = HeapAlloc(hHeap, 0, aStrByteLen); > + if (aStr == NULL) > + { > + HeapFree(hHeap, 0, aStr); > + return NULL; > + } > + > + ret = WideCharToMultiByte(1252, > + 0, > + wStr, > + charLen, > + aStr, > + aStrByteLen, > + NULL, > + NULL); > + if (ret != aStrByteLen) > + { > + HeapFree(hHeap, 0, aStr); > + return NULL; > + } > + return aStr; > +} > + > +WCHAR* > +StrCpyHeapAllocW(_In_opt_ HANDLE hHeap, > + _In_ WCHAR* wStr) > +{ > + int chLen; > + int bLen; > + WCHAR* resW; > + > + if (wStr == NULL) > + return NULL; > + > + if (hHeap == 0) > + hHeap = GetProcessHeap(); > + > + chLen = wcslen(wStr); > + > + bLen = (chLen + 1) * sizeof(WCHAR); > + > + resW = HeapAlloc(hHeap, 0, bLen); > + RtlCopyMemory(resW, wStr, bLen); > + return resW; > +} > + > +char* > +StrCpyHeapAllocA(_In_opt_ HANDLE hHeap, > + _In_ char* aStr) > +{ > + int chLen; > + int bLen; > + char* resA; > + > + if (aStr == NULL) > + return NULL; > + > + if (hHeap == 0) > + hHeap = GetProcessHeap(); > + > + chLen = strlen(aStr); > + > + bLen = (chLen + 1) * sizeof(char); > + > + resA = HeapAlloc(hHeap, 0, bLen); > + RtlCopyMemory(resA, aStr, bLen); > + return resA; > +} > + > +char** > +StrAryCpyHeapAllocA(_In_opt_ HANDLE hHeap, > + _In_ char** aStrAry) > +{ > + char** aSrcPtr; > + char** aDstPtr; > + char* aDstNextStr; > + DWORD aStrByteLen[MAX_ARRAY_SIZE]; > + int bLen; > + int bItmLen; > + int aCount; > + int i1; > + char** resA; > + > + if (hHeap == 0) > + hHeap = GetProcessHeap(); > + > + /* Calculating size of array ... */ > + aSrcPtr = aStrAry; > + bLen = 0; > + aCount = 0; > + > + while (*aSrcPtr != NULL) > + { > + if (aCount >= MAX_ARRAY_SIZE) > + return NULL; > + > + bItmLen = (strlen(*aSrcPtr) + 1) * sizeof(char); > + aStrByteLen[aCount] = bItmLen; > + > + bLen += sizeof(*aSrcPtr) + bItmLen; > + > + aSrcPtr++; > + aCount++; > + } > + > + /* size for NULL-terminator */ > + bLen += sizeof(*aSrcPtr); > + > + /* get memory */ > + resA = HeapAlloc(hHeap, 0, bLen); > + > + /* copy data */ > + aSrcPtr = aStrAry; > + aDstPtr = resA; > + > + /* pos for the first string */ > + aDstNextStr = (char*)(resA + aCount + 1); > + for (i1 = 0; i1 < aCount; i1++) > + { > + bItmLen = aStrByteLen[i1]; > + > + *aDstPtr = aDstNextStr; > + RtlCopyMemory(*aDstPtr, *aSrcPtr, bItmLen); > + > + aDstNextStr = (char*)((DWORD)aDstNextStr + (DWORD)bItmLen); > + aDstPtr++; > + aSrcPtr++; > + } > + > + /* terminate with NULL */ > + *aDstPtr = NULL; > + > + return resA; > +} > > Propchange: trunk/reactos/dll/win32/mswsock/mswhelper.c > ------------------------------------------------------------------------------ > svn:eol-style = native > > Added: trunk/reactos/dll/win32/mswsock/mswhelper.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/mswsock/mswhelpe… > ============================================================================== > --- trunk/reactos/dll/win32/mswsock/mswhelper.h (added) > +++ trunk/reactos/dll/win32/mswsock/mswhelper.h [iso-8859-1] Sun Sep 18 21:21:28 2016 > @@ -0,0 +1,121 @@ > +#ifndef _MSWHELPER_H > +#define _MSWHELPER_H > + > +#include <ws2spi.h> > + > +typedef struct { > + DWORD bytesUsed; > + DWORD bytesMax; > + BYTE* buffer; > + BYTE* bufendptr; // Pointer to the first "unused" byte > + BOOL bufok; // FALSE if on mswBuffer-Function fails > +} MSW_BUFFER, *PMSW_BUFFER; > + > +void > +mswBufferInit( > + _Out_ PMSW_BUFFER mswBuf, > + _In_ BYTE* buffer, > + _In_ DWORD bufferSize); > + > +inline > +BOOL > +mswBufferCheck( > + _Inout_ PMSW_BUFFER mswBuf, > + _In_ DWORD count); > + > +BOOL > +mswBufferIncUsed( > + _Inout_ PMSW_BUFFER mswBuf, > + _In_ DWORD count); > + > +inline > +BYTE* > +mswBufferEndPtr( > + _Inout_ PMSW_BUFFER mswBuf); > + > +BOOL > +mswBufferAppend( > + _Inout_ PMSW_BUFFER mswBuf, > + _In_ void *dataToAppend, > + _In_ DWORD dataSize); > + > +BOOL > +mswBufferAppendStrA( > + _Inout_ PMSW_BUFFER mswBuf, > + _In_ char* str); > + > +BOOL > +mswBufferAppendStrW( > + _Inout_ PMSW_BUFFER mswBuf, > + _In_ WCHAR* str); > + > +BOOL > +mswBufferAppendPtr( > + _Inout_ PMSW_BUFFER mswBuf, > + _In_ void* ptr); > + > +BOOL > +mswBufferAppendLst( > + _Inout_ PMSW_BUFFER mswBuf, > + _In_ void **lst, > + _In_ DWORD itemByteLength, > + _In_opt_ int deltaofs); > + > +BOOL > +mswBufferAppendStrLstA( > + _Inout_ PMSW_BUFFER mswBuf, > + _In_ void **lst, > + _In_opt_ int ptrofs); > + > +BOOL > +mswBufferAppendBlob_Hostent( > + _Inout_ PMSW_BUFFER mswBuf, > + _Inout_ LPWSAQUERYSETW lpRes, > + _In_ char* hostnameA, > + _In_ DWORD ip4addr); > + > +BOOL > +mswBufferAppendBlob_Servent( > + _Inout_ PMSW_BUFFER mswBuf, > + _Inout_ LPWSAQUERYSETW lpRes, > + _In_ char* serviceNameA, > + _In_ char** serviceAliasesA, > + _In_ char* protocolNameA, > + _In_ WORD port); > + > +BOOL > +mswBufferAppendAddr_AddrInfoW( > + _Inout_ PMSW_BUFFER mswBuf, > + _Inout_ LPWSAQUERYSETW lpRes, > + _In_ DWORD ip4addr); > + > +WCHAR* > +StrA2WHeapAlloc( > + _In_opt_ HANDLE hHeap, > + _In_ char* aStr); > + > +char* > +StrW2AHeapAlloc( > + _In_opt_ HANDLE hHeap, > + _In_ WCHAR* wStr); > + > +WCHAR* > +StrCpyHeapAllocW( > + _In_opt_ HANDLE hHeap, > + _In_ WCHAR* wStr); > + > +char* > +StrCpyHeapAllocA( > + _In_opt_ HANDLE hHeap, > + _In_ char* aStr); > + > +/* strary: > + ptr1 ... ptrn \0 > + data1 ... datan > +*/ > +char** > +StrAryCpyHeapAllocA( > + _In_opt_ HANDLE hHeap, > + _In_ char** aStrAry); > + > +#endif // _MSWHELPER_H > > Propchange: trunk/reactos/dll/win32/mswsock/mswhelper.h > ------------------------------------------------------------------------------ > svn:eol-style = native > > Added: trunk/reactos/dll/win32/mswsock/nsplookup.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/mswsock/nsplooku… > ============================================================================== > --- trunk/reactos/dll/win32/mswsock/nsplookup.c (added) > +++ trunk/reactos/dll/win32/mswsock/nsplookup.c [iso-8859-1] Sun Sep 18 21:21:28 2016 > @@ -0,0 +1,1233 @@ > +#include "precomp.h" > + > +#include <stdlib.h> > +#include <ws2spi.h> > +#include <nspapi.h> > +#include <windef.h> > +#include <winuser.h> > +#include <windns.h> > +#include <guiddef.h> > +#include <svcguid.h> > +#include <iptypes.h> > +#include <strsafe.h> > + > +#include "mswhelper.h" > + > +#define NSP_CALLID_DNS 0x0001 > +#define NSP_CALLID_HOSTNAME 0x0002 > +#define NSP_CALLID_HOSTBYNAME 0x0003 > +#define NSP_CALLID_SERVICEBYNAME 0x0004 > + > +#ifndef BUFSIZ > +#define BUFSIZ 1024 > +#endif // BUFSIZ > +#ifndef WS2_INTERNAL_MAX_ALIAS > +#define WS2_INTERNAL_MAX_ALIAS 512 > +#endif // WS2_INTERNAL_MAX_ALIAS > + > +//#define IP_LOCALHOST 0x0100007F > + > +//#define NSP_REDIRECT > + > +typedef struct { > + WCHAR* hostnameW; > + DWORD addr4; > + WCHAR* servnameW; > + WCHAR* servprotoW; > + CHAR** servaliasesA; /* array */ > + WORD servport; > +} WSHOSTINFOINTERN, *PWSHOSTINFOINTERN; > + > +typedef struct { > + GUID providerId; /* Provider-ID */ > + DWORD dwControlFlags; /* dwControlFlags (WSALookupServiceBegin) */ > + DWORD CallID; /* List for LookupServiceNext-Calls */ > + DWORD CallIDCounter; /* call-count of the current CallID. */ > + WCHAR* hostnameW; /* hostbyname */ > +#ifdef NSP_REDIRECT > + HANDLE rdrLookup; > + NSP_ROUTINE rdrproc; > +#endif > +} WSHANDLEINTERN, *PWSHANDLEINTERN; > + > +static const GUID guid_NULL = {0}; > +static const GUID guid_HOSTNAME = SVCID_HOSTNAME; > +static const GUID guid_INET_HOSTADDRBYINETSTRING = SVCID_INET_HOSTADDRBYINETSTRING; > +static const GUID guid_INET_HOSTADDRBYNAME = SVCID_INET_HOSTADDRBYNAME; > +static const GUID guid_INET_SERVICEBYNAME = SVCID_INET_SERVICEBYNAME; > + > +/* GUIDs - maybe they should be loaded from registry? */ > +/* Namespace: 32 */ > +static const GUID guid_mswsock_TcpIp = {/*Data1:*/ 0x22059D40, > + /*Data2:*/ 0x7E9E, > + /*Data3:*/ 0x11CF, > + /*Data4:*/ {0xAE, 0x5A, 0x00, 0xAA, 0x00, 0xA7, 0x11, 0x2B}}; > + > +/* {6642243A-3BA8-4AA6-BAA5-2E0BD71FDD83} */ > +/* Namespace: 15 */ > +static const GUID guid_mswsock_NLA = {/*Data1:*/ 0x6642243A, > + /*Data2:*/ 0x3BA8, > + /*Data3:*/ 0x4AA6, > + /*Data4:*/ {0xBA, 0xA5, 0x2E, 0x0B, 0xD7, 0x1F, 0xDD, 0x83}}; > + > +#ifdef NSP_REDIRECT > + > +typedef INT > +(CALLBACK *lpRdrNSPStartup)( > + LPGUID lpProviderId, > + LPNSP_ROUTINE lpRout); > + > +const rdrLib = "mswsock.dll-original"; > +lpRdrNSPStartup rdrNSPStartup; > +HANDLE hLib; > +NSP_ROUTINE rdrproc_tcpip; > +NSP_ROUTINE rdrproc_nla; > + > +#endif /* NSP_REDIRECT */ > + > +/* Forwards */ > +INT > +WINAPI > +mswNSPStartup( > + LPGUID lpProviderId, > + LPNSP_ROUTINE lpRout); > + > +INT > +NSP_LookupServiceBeginW( > + PWSHANDLEINTERN data, > + CHAR* hostnameA, > + WCHAR* hostnameW, > + DWORD CallID); > + > +INT > +NSP_LookupServiceNextW( > + _In_ PWSHANDLEINTERN data, > + _In_ DWORD CallID, > + _Inout_ LPWSAQUERYSETW lpRes, > + _Inout_ LPDWORD lpResLen); > + > +INT > +NSP_GetHostNameHeapAllocW( > + _Out_ WCHAR** hostname); > + > +INT > +NSP_GetHostByNameHeapAllocW( > + _In_ WCHAR* name, > + _In_ GUID* lpProviderId, > + _Out_ PWSHOSTINFOINTERN hostinfo); > + > +INT > +NSP_GetServiceByNameHeapAllocW( > + _In_ WCHAR* nameW, > + _In_ GUID* lpProviderId, > + _Out_ PWSHOSTINFOINTERN hostinfo); > + > +/* Implementations - Internal */ > + > +INT > +WSAAPI > +mwsNSPCleanUp(_In_ LPGUID lpProviderId) > +{ > + //WSASetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + //return ERROR_CALL_NOT_IMPLEMENTED; > + return ERROR_SUCCESS; > +} > + > +INT > +mwsNSPInit(VOID) > +{ > + return ERROR_SUCCESS; > +} > + > +INT > +WSAAPI > +mwsNSPLookupServiceBegin(_In_ LPGUID lpProviderId, > + _In_ LPWSAQUERYSETW lpqsRestrictions, > + _In_ LPWSASERVICECLASSINFOW lpServiceClassInfo, > + _In_ DWORD dwControlFlags, > + _Out_ LPHANDLE lphLookup) > +{ > + PWSHANDLEINTERN pLook; > + int wsaErr; > + > + if (IsEqualGUID(lpProviderId, &guid_mswsock_TcpIp)) > + { > + //OK > + } > + else if (IsEqualGUID(lpProviderId, &guid_mswsock_NLA)) > + { > + WSASetLastError(WSASERVICE_NOT_FOUND); > + return SOCKET_ERROR; > + } > + else > + { > + return ERROR_CALL_NOT_IMPLEMENTED; > + } > + > + /* allocate internal structure */ > + pLook = HeapAlloc(GetProcessHeap(), 0, sizeof(WSHANDLEINTERN)); > + if (!pLook) > + { > + WSASetLastError(WSAEFAULT); > + return SOCKET_ERROR; > + } > + > + *lphLookup = (HANDLE)pLook; > + > + RtlZeroMemory(pLook, sizeof(*pLook)); > + > + /* Anyway the ControlFlags "should" be needed > + in NSPLookupServiceNext. (see doku) But > + thats not the fact ATM. */ > + pLook->dwControlFlags = dwControlFlags; > + pLook->providerId = *lpProviderId; > + > +#ifdef NSP_REDIRECT > + > + if (IsEqualGUID(lpProviderId, &guid_mswsock_TcpIp)) > + { > + pLook->rdrproc = rdrproc_tcpip; > + } > + else if (IsEqualGUID(lpProviderId, &guid_mswsock_NLA)) > + { > + pLook->rdrproc = rdrproc_nla; > + } > + else > + { > + return ERROR_CALL_NOT_IMPLEMENTED; > + } > + > + if (pLook->rdrproc.NSPLookupServiceBegin(lpProviderId, > + lpqsRestrictions, > + lpServiceClassInfo, > + dwControlFlags, > + &pLook->rdrLookup) == NO_ERROR) > + { > + wsaErr = NO_ERROR; > + } > + else > + { > + wsaErr = WSAGetLastError(); > + } > + > + /* > + if (res) > + res = WSAGetLastError(); > + */ > + > +#else /* NSP_REDIRECT */ > + > + wsaErr = ERROR_CALL_NOT_IMPLEMENTED; > + if (IsEqualGUID(lpqsRestrictions->lpServiceClassId, &guid_NULL)) > + { > + wsaErr = ERROR_CALL_NOT_IMPLEMENTED; > + } > + else if (IsEqualGUID(lpqsRestrictions->lpServiceClassId, &guid_HOSTNAME)) > + { > + wsaErr = NSP_LookupServiceBeginW(pLook, > + NULL, > + NULL, > + NSP_CALLID_HOSTNAME); > + } > + else if (IsEqualGUID(lpqsRestrictions->lpServiceClassId, > + &guid_INET_HOSTADDRBYNAME)) > + { > + wsaErr = NSP_LookupServiceBeginW(pLook, > + NULL, > + lpqsRestrictions->lpszServiceInstanceName, > + NSP_CALLID_HOSTBYNAME); > + } > + else if (IsEqualGUID(lpqsRestrictions->lpServiceClassId, > + &guid_INET_SERVICEBYNAME)) > + { > + wsaErr = NSP_LookupServiceBeginW(pLook, > + NULL, > + lpqsRestrictions->lpszServiceInstanceName, > + NSP_CALLID_SERVICEBYNAME); > + } > + else if (IsEqualGUID(lpqsRestrictions->lpServiceClassId, > + &guid_INET_HOSTADDRBYINETSTRING)) > + { > + wsaErr = ERROR_CALL_NOT_IMPLEMENTED; > + } > + > +#endif /* NSP_REDIRECT */ > + > + if (wsaErr != NO_ERROR) > + { > + WSASetLastError(wsaErr); > + return SOCKET_ERROR; > + } > + return NO_ERROR; > +} > + > +INT > +WSAAPI > +mwsNSPLookupServiceNext(_In_ HANDLE hLookup, > + _In_ DWORD dwControlFlags, > + _Inout_ LPDWORD lpdwBufferLength, > + //_Out_writes_bytes_to_(*lpdwBufferLength, *lpdwBufferLength) > + LPWSAQUERYSETW lpqsResults) > +{ > + PWSHANDLEINTERN pLook = hLookup; > + int wsaErr = 0; > + > +#ifdef NSP_REDIRECT > + > + INT res = pLook->rdrproc.NSPLookupServiceNext(pLook->rdrLookup, > + dwControlFlags, > + lpdwBufferLength, > + lpqsResults); > + wsaErr = WSAGetLastError(); > + if (res != ERROR_SUCCESS) > + { > + wsaErr = WSAGetLastError(); > + > + if (wsaErr == 0) > + wsaErr = 0xFFFFFFFF; > + } > + > +#else /* NSP_REDIRECT */ > + > + if ((lpdwBufferLength == NULL) || (*lpdwBufferLength == 0)) > + { > + wsaErr = WSA_NOT_ENOUGH_MEMORY; > + goto End; > + } > + > + RtlZeroMemory(lpqsResults, *lpdwBufferLength); > + lpqsResults->dwSize = sizeof(*lpqsResults); > + > + wsaErr = NSP_LookupServiceNextW(pLook, > + pLook->CallID, > + lpqsResults, > + lpdwBufferLength); > + > + > +#endif /* NSP_REDIRECT */ > + > +End: > + if (wsaErr != 0) > + { > + WSASetLastError(wsaErr); > + return SOCKET_ERROR; > + } > + return NO_ERROR; > +} > + > +INT > +WSAAPI > +mwsNSPIoCtl(_In_ HANDLE hLookup, > + _In_ DWORD dwControlCode, > + _In_reads_bytes_(cbInBuffer) LPVOID lpvInBuffer, > + _In_ DWORD cbInBuffer, > + _Out_writes_bytes_to_(cbOutBuffer, *lpcbBytesReturned) LPVOID lpvOutBuffer, > + _In_ DWORD cbOutBuffer, > + _Out_ LPDWORD lpcbBytesReturned, > + _In_opt_ LPWSACOMPLETION lpCompletion, > + _In_ LPWSATHREADID lpThreadId) > +{ > + WSASetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} > + > +INT > +WSAAPI > +mwsNSPLookupServiceEnd(_In_ HANDLE hLookup) > +{ > + PWSHANDLEINTERN pLook; > + HANDLE hHeap; > + INT res; > + > + res = NO_ERROR; > + pLook = (PWSHANDLEINTERN)hLookup; > + hHeap = GetProcessHeap(); > + > +#ifdef NSP_REDIRECT > + res = pLook->rdrproc.NSPLookupServiceEnd(pLook->rdrLookup); > +#endif > + > + if (pLook->hostnameW != NULL) > + HeapFree(hHeap, 0, pLook->hostnameW); > + > + HeapFree(hHeap, 0, pLook); > + return res; > +} > + > +INT > +WSAAPI > +mwsNSPSetService(_In_ LPGUID lpProviderId, > + _In_ LPWSASERVICECLASSINFOW lpServiceClassInfo, > + _In_ LPWSAQUERYSETW lpqsRegInfo, > + _In_ WSAESETSERVICEOP essOperation, > + _In_ DWORD dwControlFlags) > +{ > + WSASetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} > + > +INT > +WSAAPI > +mwsNSPInstallServiceClass(_In_ LPGUID lpProviderId, > + _In_ LPWSASERVICECLASSINFOW lpServiceClassInfo) > +{ > + WSASetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} > + > +INT > +WSAAPI > +mwsNSPRemoveServiceClass(_In_ LPGUID lpProviderId, > + _In_ LPGUID lpServiceClassId) > +{ > + WSASetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} > + > +INT > +WSAAPI > +mwsNSPGetServiceClassInfo(_In_ LPGUID lpProviderId, > + _In_ LPDWORD lpdwBufSize, > + _In_ LPWSASERVICECLASSINFOW lpServiceClassInfo) > +{ > + WSASetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} > + > +/* > + hostnameA / hostnameW > + * only used by HOSTBYNAME > + * only one should be set > + > +*/ > +INT > +NSP_LookupServiceBeginW(PWSHANDLEINTERN data, > + CHAR* hostnameA, > + WCHAR* hostnameW, > + DWORD CallID) > +{ > + HANDLE hHeap; > + > + if (data->CallID != 0) > + return WSAEFAULT; > + > + data->CallID = CallID; > + > + if ((CallID == NSP_CALLID_HOSTBYNAME) || > + (CallID == NSP_CALLID_SERVICEBYNAME)) > + { > + hHeap = GetProcessHeap(); > + > + if (data->hostnameW != NULL) > + HeapFree(hHeap, 0, data->hostnameW); > + > + if (hostnameA != NULL) > + { > + data->hostnameW = StrA2WHeapAlloc(hHeap, hostnameA); > + } > + else > + { > + data->hostnameW = StrCpyHeapAllocW(hHeap, hostnameW); > + } > + } > + > + WSASetLastError(0); > + > + return ERROR_SUCCESS; > +} > + > +INT > +NSP_GetHostNameHeapAllocW(_Out_ WCHAR** hostname) > +{ > + WCHAR* name; > + HANDLE hHeap = GetProcessHeap(); > + DWORD bufCharLen = MAX_COMPUTERNAME_LENGTH + 1; > + DWORD bufByteLen = bufCharLen * sizeof(WCHAR); > + > + name = HeapAlloc(hHeap, 0, bufByteLen); > + > + if (!GetComputerNameExW(ComputerNameDnsHostname, > + name, > + &bufCharLen)) > + { > + HeapFree(hHeap, 0, name); > + WSASetLastError(WSAEFAULT); > + return SOCKET_ERROR; > + } > + > + *hostname = name; > + return ERROR_SUCCESS; > +} > + > +/* This function is far from perfect but it works enough */ > +IP4_ADDRESS > +FindEntryInHosts(IN CONST WCHAR FAR* wname) > +{ > + BOOL Found = FALSE; > + HANDLE HostsFile; > + CHAR HostsDBData[BUFSIZ] = {0}; > + PCHAR SystemDirectory = HostsDBData; > + PCHAR HostsLocation = "\\drivers\\etc\\hosts"; > + PCHAR AddressStr, DnsName = NULL, AddrTerm, NameSt, NextLine, ThisLine, Comment; > + UINT SystemDirSize = sizeof(HostsDBData) - 1, ValidData = 0; > + DWORD ReadSize; > + DWORD Address; > + CHAR name[MAX_HOSTNAME_LEN + 1]; > + > + wcstombs(name, wname, MAX_HOSTNAME_LEN); > + > + /* We assume that the parameters are valid */ > + if (!GetSystemDirectoryA(SystemDirectory, SystemDirSize)) > + { > + WSASetLastError(WSANO_RECOVERY); > + //WS_DbgPrint(MIN_TRACE, ("Could not get windows system directory.\n")); > + return 0; /* Can't get system directory */ > + } > + > + strncat(SystemDirectory, HostsLocation, SystemDirSize); > + > + HostsFile = CreateFileA(SystemDirectory, > + GENERIC_READ, > + FILE_SHARE_READ, > + NULL, > + OPEN_EXISTING, > + FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN, > + NULL); > + if (HostsFile == INVALID_HANDLE_VALUE) > + { > + WSASetLastError(WSANO_RECOVERY); > + return 0; > + } > + > + while (!Found && ReadFile(HostsFile, > + HostsDBData + ValidData, > + sizeof(HostsDBData) - ValidData, > + &ReadSize, > + NULL)) > + { > + ValidData += ReadSize; > + ReadSize = 0; > + NextLine = ThisLine = HostsDBData; > + > + /* Find the beginning of the next line */ > + while ((NextLine < HostsDBData + ValidData) && > + (*NextLine != '\r') && > + (*NextLine != '\n')) > + { > + NextLine++; > + } > + > + /* Zero and skip, so we can treat what we have as a string */ > + if (NextLine > HostsDBData + ValidData) > + break; > + > + *NextLine = 0; > + NextLine++; > + > + Comment = strchr(ThisLine, '#'); > + if (Comment) > + *Comment = 0; /* Terminate at comment start */ > + > + AddressStr = ThisLine; > + /* Find the first space separating the IP address from the DNS name */ > + AddrTerm = strchr(ThisLine, ' '); > + if (AddrTerm) > + { > + /* Terminate the address string */ > + *AddrTerm = 0; > + > + /* Find the last space before the DNS name */ > + NameSt = strrchr(ThisLine, ' '); > + > + /* If there is only one space (the one we removed above), then just use the address terminator */ > + if (!NameSt) > + NameSt = AddrTerm; > + > + /* Move from the space to the first character of the DNS name */ > + NameSt++; > + > + DnsName = NameSt; > + > + if (!strcmp(name, DnsName)) > + { > + Found = TRUE; > + break; > + } > + } > + > + /* Get rid of everything we read so far */ > + while (NextLine <= HostsDBData + ValidData && > + isspace (*NextLine)) > + { > + NextLine++; > + } > + > + if (HostsDBData + ValidData - NextLine <= 0) > + break; > + > + //WS_DbgPrint(MAX_TRACE,("About to move %d chars\n", > + // HostsDBData + ValidData - NextLine)); > + > + memmove(HostsDBData, NextLine, HostsDBData + ValidData - NextLine); > + ValidData -= NextLine - HostsDBData; > + //WS_DbgPrint(MAX_TRACE,("Valid bytes: %d\n", ValidData)); > + } > + > + CloseHandle(HostsFile); > + > + if (!Found) > + { > + //WS_DbgPrint(MAX_TRACE,("Not found\n")); > + WSASetLastError(WSANO_DATA); > + return 0; > + } > + > + if (strstr(AddressStr, ":")) > + { > + //DbgPrint("AF_INET6 NOT SUPPORTED!\n"); > + WSASetLastError(WSAEINVAL); > + return 0; > + } > + > + Address = inet_addr(AddressStr); > + if (Address == INADDR_NONE) > + { > + WSASetLastError(WSAEINVAL); > + return 0; > + } > + > + return Address; > +} > + > +INT > +NSP_GetHostByNameHeapAllocW(_In_ WCHAR* name, > + _In_ GUID* lpProviderId, > + _Out_ PWSHOSTINFOINTERN hostinfo) > +{ > + HANDLE hHeap = GetProcessHeap(); > + enum addr_type > + { > + GH_INVALID, > + GH_IPV6, > + GH_IPV4, > + GH_RFC1123_DNS > + }; > + typedef enum addr_type addr_type; > + addr_type addr; > + INT ret = 0; > + WCHAR* found = 0; > + DNS_STATUS dns_status = {0}; > + /* include/WinDNS.h -- look up DNS_RECORD on MSDN */ > + PDNS_RECORD dp; > + PDNS_RECORD curr; > + WCHAR* tmpHostnameW; > + CHAR* tmpHostnameA; > + IP4_ADDRESS address; > + INT result = ERROR_SUCCESS; > + > + /* needed to be cleaned up if != NULL */ > + tmpHostnameW = NULL; > + dp = NULL; > + > + addr = GH_INVALID; > + > + if (name == NULL) > + { > + result = ERROR_INVALID_PARAMETER; > + goto cleanup; > + } > + > + /* Hostname "" / "localhost" > + - convert to "computername" */ > + if ((wcscmp(L"", name) == 0) /*|| > + (wcsicmp(L"localhost", name) == 0)*/) > + { > + ret = NSP_GetHostNameHeapAllocW(&tmpHostnameW); > + if (ret != ERROR_SUCCESS) > + { > + result = ret; > + goto cleanup; > + } > + name = tmpHostnameW; > + } > + > + /* Is it an IPv6 address? */ > + found = wcschr(name, L':'); > + if (found != NULL) > + { > + addr = GH_IPV6; > + goto act; > + } > + > + /* Is it an IPv4 address? */ > + if (!iswalpha(name[0])) > + { > + addr = GH_IPV4; > + goto act; > + } > + > + addr = GH_RFC1123_DNS; > + > +/* Broken out in case we want to get fancy later */ > +act: > + switch (addr) > + { > + case GH_IPV6: > + WSASetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + result = ERROR_CALL_NOT_IMPLEMENTED; > + goto cleanup; > + break; > + > + case GH_INVALID: > + WSASetLastError(WSAEFAULT); > + result = ERROR_INVALID_PARAMETER; > + goto cleanup; > + break; > + > + /* Note: If passed an IP address, MSDN says that gethostbyname() > + treats it as an unknown host. > + This is different from the unix implementation. Use inet_addr() > + */ > + case GH_IPV4: > + case GH_RFC1123_DNS: > + /* DNS_TYPE_A: include/WinDNS.h */ > + /* DnsQuery -- lib/dnsapi/dnsapi/query.c */ > + > + /* Look for the DNS name in the hosts file */ > + if ((address = FindEntryInHosts(name)) != 0) > + { > + hostinfo->hostnameW = StrCpyHeapAllocW(hHeap, name); > + hostinfo->addr4 = address; > + result = ERROR_SUCCESS; > + goto cleanup; > + } > + > + tmpHostnameA = StrW2AHeapAlloc(hHeap, name); > + dns_status = DnsQuery(tmpHostnameA, > + DNS_TYPE_A, > + DNS_QUERY_STANDARD, > + /* extra dns servers */ 0, > + &dp, > + 0); > + HeapFree(hHeap, 0, tmpHostnameA); > + > + if ((dns_status != 0) || (dp == NULL)) > + { > + result = WSAHOST_NOT_FOUND; > + goto cleanup; > + } > + > + //ASSERT(dp->wType == DNS_TYPE_A); > + //ASSERT(dp->wDataLength == sizeof(DNS_A_DATA)); > + curr = dp; > + while ((curr->pNext != NULL) || (curr->wType != DNS_TYPE_A)) > + { > + curr = curr->pNext; > + } > + > + if (curr->wType != DNS_TYPE_A) > + { > + result = WSASERVICE_NOT_FOUND; > + goto cleanup; > + } > + > + //WS_DbgPrint(MID_TRACE,("populating hostent\n")); > + //WS_DbgPrint(MID_TRACE,("pName is (%s)\n", curr->pName)); > + //populate_hostent(p->Hostent, > + // (PCHAR)curr->pName, > + // curr->Data.A.IpAddress); > + hostinfo->hostnameW = StrA2WHeapAlloc(hHeap, curr->pName); > + hostinfo->addr4 = curr->Data.A.IpAddress; > + result = ERROR_SUCCESS; > + goto cleanup; > + > + //WS_DbgPrint(MID_TRACE,("Called DnsQuery, but host not found. Err: %i\n", > + // dns_status)); > + //WSASetLastError(WSAHOST_NOT_FOUND); > + //return NULL; > + > + break; > + > + default: > + result = WSANO_RECOVERY; > + goto cleanup; > + break; > + } > + > + result = WSANO_RECOVERY; > + > +cleanup: > + if (dp != NULL) > + DnsRecordListFree(dp, DnsFreeRecordList); > + > + if (tmpHostnameW != NULL) > + HeapFree(hHeap, 0, tmpHostnameW); > + > + return result; > +} > + > +#define SKIPWS(ptr, act) \ > +{while(*ptr && isspace(*ptr)) ptr++; if(!*ptr) act;} > + > +#define SKIPANDMARKSTR(ptr, act) \ > +{while(*ptr && !isspace(*ptr)) ptr++; \ > + if(!*ptr) {act;} else { *ptr = 0; ptr++; }} > + > +static > +BOOL > +DecodeServEntFromString(IN PCHAR ServiceString, > + OUT PCHAR *ServiceName, > + OUT PCHAR *PortNumberStr, > + OUT PCHAR *ProtocolStr, > + IN PCHAR *Aliases, > + IN DWORD MaxAlias) > +{ > + UINT NAliases = 0; > + > + //WS_DbgPrint(MAX_TRACE, ("Parsing service ent [%s]\n", ServiceString)); > + > + SKIPWS(ServiceString, return FALSE); > + *ServiceName = ServiceString; > + SKIPANDMARKSTR(ServiceString, return FALSE); > + SKIPWS(ServiceString, return FALSE); > + *PortNumberStr = ServiceString; > + SKIPANDMARKSTR(ServiceString, ;); > + > + while (*ServiceString && NAliases < MaxAlias - 1) > + { > + SKIPWS(ServiceString, break); > + if (*ServiceString) > + { > + SKIPWS(ServiceString, ;); > + if (strlen(ServiceString)) > + { > + //WS_DbgPrint(MAX_TRACE, ("Alias: %s\n", ServiceString)); > + *Aliases++ = ServiceString; > + NAliases++; > + } > + SKIPANDMARKSTR(ServiceString, ;); > + } > + } > + *Aliases = NULL; > + > + *ProtocolStr = strchr(*PortNumberStr, '/'); > + > + if (!*ProtocolStr) > + return FALSE; > + > + **ProtocolStr = 0; > + (*ProtocolStr)++; > + > + //WS_DbgPrint(MAX_TRACE, ("Parsing done: %s %s %s %d\n", > + // *ServiceName, *ProtocolStr, *PortNumberStr, > + // NAliases)); > + > + return TRUE; > +} > + > +INT > +NSP_GetServiceByNameHeapAllocW(_In_ WCHAR* nameW, > + _In_ GUID* lpProviderId, > + _Out_ PWSHOSTINFOINTERN hostinfo) > +{ > + BOOL Found = FALSE; > + HANDLE ServicesFile; > + CHAR ServiceDBData[BUFSIZ * sizeof(WCHAR)] = {0}; > + PWCHAR SystemDirectory = (PWCHAR)ServiceDBData; /* Reuse this stack space */ > + PWCHAR ServicesFileLocation = L"\\drivers\\etc\\services"; > + PCHAR ThisLine = 0, NextLine = 0, ServiceName = 0, PortNumberStr = 0, > + ProtocolStr = 0, Comment = 0, EndValid; > + PCHAR Aliases[WS2_INTERNAL_MAX_ALIAS] = {0}; > + PCHAR* AliasPtr; > + UINT i = 0, > + SystemDirSize = (sizeof(ServiceDBData) / sizeof(WCHAR)) - 1; > + DWORD ReadSize = 0; > + HANDLE hHeap; > + PCHAR nameA = NULL; > + PCHAR nameServiceA = NULL; > + PCHAR nameProtoA = NULL; > + INT res = WSANO_RECOVERY; > + > + if (!nameW) > + { > + res = WSANO_RECOVERY; > + goto End; > + } > + > + hHeap = GetProcessHeap(); > + nameA = StrW2AHeapAlloc(hHeap, nameW); > + > + /* nameA has the form <service-name>/<protocol> > + we split these now */ > + nameProtoA = strchr(nameA, '/'); > + if (nameProtoA == NULL) > + { > + res = WSANO_RECOVERY; > + goto End; > + } > + > + nameProtoA++; > + i = (DWORD)(nameProtoA - nameA - 1); > + nameServiceA = (PCHAR)HeapAlloc(hHeap, 0, i + 1); > + StringCbCopyA(nameServiceA, i + 1, nameA); > + nameServiceA[i] = '\0'; > + > + if (!GetSystemDirectoryW(SystemDirectory, SystemDirSize)) > + { > + /* Can't get system directory */ > + res = WSANO_RECOVERY; > + goto End; > + } > + > + wcsncat(SystemDirectory, ServicesFileLocation, SystemDirSize); > + > + ServicesFile = CreateFileW(SystemDirectory, > + GENERIC_READ, > + FILE_SHARE_READ, > + NULL, > + OPEN_EXISTING, > + FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN, > + NULL); > + > + if (ServicesFile == INVALID_HANDLE_VALUE) > + { > + return WSANO_RECOVERY; > + } > + > + /* Scan the services file ... > + * > + * We will be share the buffer on the lines. If the line does not fit in > + * the buffer, then moving it to the beginning of the buffer and read > + * the remnants of line from file. > + */ > + > + /* Initial Read */ > + ReadFile(ServicesFile, > + ServiceDBData, > + sizeof( ServiceDBData ) - 1, > + &ReadSize, > + NULL); > + > + ThisLine = NextLine = ServiceDBData; > + EndValid = ServiceDBData + ReadSize; > + ServiceDBData[sizeof(ServiceDBData) - 1] = '\0'; > + > + while (ReadSize) > + { > + for (; *NextLine != '\r' && *NextLine != '\n'; NextLine++) > + { > + if (NextLine == EndValid) > + { > + int LineLen = NextLine - ThisLine; > + > + if (ThisLine == ServiceDBData) > + { > + //WS_DbgPrint(MIN_TRACE,("Line too long")); > + return WSANO_RECOVERY; > + } > + > + memmove(ServiceDBData, ThisLine, LineLen); > + > + ReadFile(ServicesFile, > + ServiceDBData + LineLen, > + sizeof( ServiceDBData )-1 - LineLen, > + &ReadSize, > + NULL); > + > + EndValid = ServiceDBData + LineLen + ReadSize; > + NextLine = ServiceDBData + LineLen; > + ThisLine = ServiceDBData; > + > + if (!ReadSize) break; > + } > + } > + > + *NextLine = '\0'; > + Comment = strchr(ThisLine, '#'); > + > + if (Comment) > + *Comment = '\0'; /* Terminate at comment start */ > + > + if (DecodeServEntFromString(ThisLine, > + &ServiceName, > + &PortNumberStr, > + &ProtocolStr, > + Aliases, > + WS2_INTERNAL_MAX_ALIAS) && > + (strlen(nameProtoA) == 0 || strcmp(ProtocolStr, nameProtoA) == 0)) > + { > + Found = (strcmp(ServiceName, nameServiceA) == 0 || strcmp(PortNumberStr, nameServiceA) == 0); > + AliasPtr = Aliases; > + while ((!Found) && (*AliasPtr != NULL)) > + { > + Found = (strcmp(*AliasPtr, nameServiceA) == 0); > + AliasPtr++; > + } > + if (Found) > + break; > + } > + NextLine++; > + ThisLine = NextLine; > + } > + > + /* This we'll do no matter what */ > + CloseHandle(ServicesFile); > + > + if (!Found) > + { > + return WSANO_DATA; > + } > + > + hostinfo->addr4 = 0; > + hostinfo->servnameW = StrA2WHeapAlloc(hHeap, ServiceName); > + hostinfo->servprotoW = StrA2WHeapAlloc(hHeap, ProtocolStr); > + hostinfo->servaliasesA = StrAryCpyHeapAllocA(hHeap, (char**)&Aliases); > + hostinfo->servport = atoi(PortNumberStr); > + > + res = NO_ERROR; > + > +End: > + if (nameA != NULL) > + HeapFree(hHeap, 0, nameA); > + > + if (nameServiceA != NULL) > + HeapFree(hHeap, 0, nameServiceA); > + > + return res; > +} > + > +INT > +NSP_LookupServiceNextW(_In_ PWSHANDLEINTERN data, > + _In_ DWORD CallID, > + _Inout_ LPWSAQUERYSETW lpRes, > + _Inout_ LPDWORD lpResLen) > +{ > + MSW_BUFFER buf; > + WSHOSTINFOINTERN hostinfo; > + INT result; > + HANDLE hHeap = GetProcessHeap(); > + WCHAR* ServiceInstanceNameW = NULL; > + /* cleanup-vars */ > + CHAR* ServiceInstanceNameA = NULL; > + CHAR* ServiceProtocolNameA = NULL; > + > + RtlZeroMemory(&hostinfo, sizeof(hostinfo)); > + > + /* init and build result-buffer */ > + mswBufferInit(&buf, (BYTE*)lpRes, *lpResLen); > + mswBufferIncUsed(&buf, sizeof(*lpRes)); > + > + /* QueryDataSet-Size without "blob-data"-size! */ > + lpRes->dwSize = sizeof(*lpRes); > + lpRes->dwNameSpace = NS_DNS; > + > + if ((CallID == NSP_CALLID_HOSTNAME) || > + (CallID == NSP_CALLID_HOSTBYNAME) || > + (CallID == NSP_CALLID_SERVICEBYNAME)) > + { > + if (data->CallIDCounter >= 1) > + { > + result = WSAENOMORE; > + goto End; > + } > + } > + else > + { > + result = WSANO_RECOVERY; > + goto End; > + } > + data->CallIDCounter++; > + > + if (CallID == NSP_CALLID_HOSTNAME) > + { > + result = NSP_GetHostNameHeapAllocW(&hostinfo.hostnameW); > + > + if (result != ERROR_SUCCESS) > + goto End; > + > + hostinfo.addr4 = 0; > + } > + else if (CallID == NSP_CALLID_HOSTBYNAME) > + { > + result = NSP_GetHostByNameHeapAllocW(data->hostnameW, > + &data->providerId, > + &hostinfo); > + if (result != ERROR_SUCCESS) > + goto End; > + } > + else if (CallID == NSP_CALLID_SERVICEBYNAME) > + { > + result = NSP_GetServiceByNameHeapAllocW(data->hostnameW, > + &data->providerId, > + &hostinfo); > + if (result != ERROR_SUCCESS) > + goto End; > + } > + else > + { > + result = WSANO_RECOVERY; // Internal error! > + goto End; > + } > + > + if (((LUP_RETURN_BLOB & data->dwControlFlags) != 0) || > + ((LUP_RETURN_NAME & data->dwControlFlags) != 0)) > + { > + if (CallID == NSP_CALLID_HOSTNAME || CallID == NSP_CALLID_HOSTBYNAME) > + { > + ServiceInstanceNameW = hostinfo.hostnameW; > + ServiceInstanceNameA = StrW2AHeapAlloc(hHeap, ServiceInstanceNameW); > + if (ServiceInstanceNameA == NULL) > + { > + result = WSAEFAULT; > + goto End; > + > + } > + } > + if (CallID == NSP_CALLID_SERVICEBYNAME) > + { > + ServiceInstanceNameW = hostinfo.servnameW; > + ServiceInstanceNameA = StrW2AHeapAlloc(hHeap, ServiceInstanceNameW); > + if (ServiceInstanceNameA == NULL) > + { > + result = WSAEFAULT; > + goto End; > + > + } > + ServiceProtocolNameA = StrW2AHeapAlloc(hHeap, hostinfo.servprotoW); > + if (ServiceProtocolNameA == NULL) > + { > + result = WSAEFAULT; > + goto End; > + > + } > + } > + } > + > + if ((LUP_RETURN_ADDR & data->dwControlFlags) != 0) > + { > + if (!mswBufferAppendAddr_AddrInfoW(&buf, lpRes, hostinfo.addr4)) > + { > + *lpResLen = buf.bytesUsed; > + result = WSAEFAULT; > + goto End; > + } > + } > + > + if ((LUP_RETURN_BLOB & data->dwControlFlags) != 0) > + { > + if (CallID == NSP_CALLID_HOSTBYNAME) > + { > + /* Write data for PBLOB (hostent) */ > + if (!mswBufferAppendBlob_Hostent(&buf, > + lpRes, > + ServiceInstanceNameA, > + hostinfo.addr4)) > + { > + *lpResLen = buf.bytesUsed; > + result = WSAEFAULT; > + goto End; > + } > + } > + else if (CallID == NSP_CALLID_SERVICEBYNAME) > + { > + /* Write data for PBLOB (servent) */ > + if (!mswBufferAppendBlob_Servent(&buf, > + lpRes, > + ServiceInstanceNameA,/* ServiceName */ > + hostinfo.servaliasesA, > + ServiceProtocolNameA, > + hostinfo.servport)) > + { > + *lpResLen = buf.bytesUsed; > + result = WSAEFAULT; > + goto End; > + } > + } > + else > + { > + result = WSANO_RECOVERY; > + goto End; > + } > + } > + > + if ((LUP_RETURN_NAME & data->dwControlFlags) != 0) > + { > + /* HostByName sets the ServiceInstanceName to a > + (UNICODE)copy of hostent.h_name */ > + lpRes->lpszServiceInstanceName = (LPWSTR)mswBufferEndPtr(&buf); > + if (!mswBufferAppendStrW(&buf, ServiceInstanceNameW)) > + { > + lpRes->lpszServiceInstanceName = NULL; > + *lpResLen = buf.bytesUsed; > + result = WSAEFAULT; > + goto End; > + } > + } > + > + *lpResLen = buf.bytesUsed; > + > + result = ERROR_SUCCESS; > +End: > + /* cleanup */ > + if (ServiceInstanceNameA != NULL) > + HeapFree(hHeap, 0, ServiceInstanceNameA); > + > + if (ServiceProtocolNameA != NULL) > + HeapFree(hHeap, 0, ServiceProtocolNameA); > + > + if (hostinfo.hostnameW != NULL) > + HeapFree(hHeap, 0, hostinfo.hostnameW); > + > + if (hostinfo.servnameW != NULL) > + HeapFree(hHeap, 0, hostinfo.servnameW); > + > + if (hostinfo.servprotoW != NULL) > + HeapFree(hHeap, 0, hostinfo.servprotoW); > + > + return result; > +} > + > +/* Implementations - Exports */ > +/* > + * @implemented > + */ > +int > +WINAPI > +NSPStartup(_In_ LPGUID lpProviderId, > + _Out_ LPNSP_ROUTINE lpRout) > +{ > + INT ret; > + > + if ((lpRout == NULL) || > + (lpRout->cbSize != sizeof(NSP_ROUTINE))) > + { > + WSASetLastError(ERROR_INVALID_PARAMETER); > + return ERROR_INVALID_PARAMETER; > + } > + > + mwsNSPInit(); > + > + /* set own Provider GUID - maybe we need > + here to set the original mswsock-GUID?! */ > + > + /* Win2k3 returns > + - Version 1.1 > + - no NSPIoctl > + - sets cbSize to 44! */ > + lpRout->dwMajorVersion = 1; > + lpRout->dwMinorVersion = 1; > + lpRout->cbSize = sizeof(*lpRout) - sizeof(lpRout->NSPIoctl); > + lpRout->NSPCleanup = &mwsNSPCleanUp; > + lpRout->NSPLookupServiceBegin = &mwsNSPLookupServiceBegin; > + lpRout->NSPLookupServiceNext = &mwsNSPLookupServiceNext; > + lpRout->NSPLookupServiceEnd = &mwsNSPLookupServiceEnd; > + lpRout->NSPSetService = &mwsNSPSetService; > + lpRout->NSPInstallServiceClass = &mwsNSPInstallServiceClass; > + lpRout->NSPRemoveServiceClass = &mwsNSPRemoveServiceClass; > + lpRout->NSPGetServiceClassInfo = &mwsNSPGetServiceClassInfo; > + lpRout->NSPIoctl = NULL;// &mwsNSPIoCtl; > + > + ret = NO_ERROR; > + > + return ret; > +} > > Propchange: trunk/reactos/dll/win32/mswsock/nsplookup.c > ------------------------------------------------------------------------------ > svn:eol-style = native > > Modified: trunk/reactos/dll/win32/mswsock/stubs.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/mswsock/stubs.c?… > ============================================================================== > --- trunk/reactos/dll/win32/mswsock/stubs.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/mswsock/stubs.c [iso-8859-1] Sun Sep 18 21:21:28 2016 > @@ -9,6 +9,7 @@ > > #include "precomp.h" > > +#include <windef.h> > #include <ws2spi.h> > #include <nspapi.h> > > @@ -417,21 +418,6 @@ > return TRUE; > } > > - > -/* > - * @unimplemented > - */ > -INT > -WINAPI > -NSPStartup( > - LPGUID lpProviderId, > - LPNSP_ROUTINE lpnspRoutines > - ) > -{ > - return TRUE; > -} > - > - > /* > * @unimplemented > */ > >

8 years, 7 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [janderwald] 72725: [USBAUDIO] - start implementing init routines - not yet added to build

by Thomas Faber

On 2016-09-18 16:24, janderwald(a)svn.reactos.org wrote: > +NTSTATUS > +SubmitUrbSync( > + IN PKSDEVICE Device, > + IN PURB Urb) > +{ > + PIRP Irp; > + KEVENT Event; > + PDEVICE_EXTENSION DeviceExtension; > + IO_STATUS_BLOCK IoStatus; > + PIO_STACK_LOCATION IoStack; > + NTSTATUS Status; > + > + // init event > + KeInitializeEvent(&Event, NotificationEvent, FALSE); > + > + // get device extension > + DeviceExtension = (PDEVICE_EXTENSION)Device->Context; > + > + // build irp > + Irp = IoBuildDeviceIoControlRequest(IOCTL_INTERNAL_USB_SUBMIT_URB, > + DeviceExtension->LowerDevice, > + NULL, > + 0, > + NULL, > + 0, > + TRUE, > + &Event, > + &IoStatus); > + > + if (!Irp) > + { > + // > + // no memory > + // > + return STATUS_INSUFFICIENT_RESOURCES; > + } > + > + // get next stack location > + IoStack = IoGetNextIrpStackLocation(Irp); > + > + // store urb > + IoStack->Parameters.Others.Argument1 = Urb; > + > + // set completion routine > + IoSetCompletionRoutine(Irp, USBAudioCancelCompleteSynch, &Event, TRUE, TRUE, TRUE); You don't need a completion routine here, completing the IRP will set the event specified in IoBuildDeviceIoControlRequest. See https://support.microsoft.com/en-us/kb/326315#bookmark-2

8 years, 7 months

1
0
0 0

Information about the ReactOS project

by B Krishnan Iyer

Namah Shivaya, I am honoured to be added in the mailing list. Can you please help me with some links to start the project. B Krishnan Iyer Amrita University <http://www.amrita.edu> Github <https://github.com/zombie-krish> | blog <https://thedilemmaweb.wordpress.com/> *Life gets exciting when its about '0' and '1' *

8 years, 7 months

1
0
0 0

"Test WHS" Builder is back!

by Colin Finck

Hi all, Back in April, our server farm used for building had to leave its hosting site (cf. https://reactos.org/archives/public/ros-dev/2016-April/017775.html). A single server was set up at the new site and I estimated to have our old server farm back up by May or June. Unfortunately, this still hasn't happened. Our server farm is still at its old location and I cannot give a timeframe when it will finally be shipped to the new location. As we cannot wait forever for this to happen, I put up the old Windows Home Server VM on our single new server and reintegrated it into BuildBot ("Test WHS" builder). Its performance won't match the former one for sure. Instead of 4GB of RAM, it's currently at mere 1GB and it builds on HDD instead of RAM-Disk. Nevertheless, it should be fully operational at least. If this works out well, I'll see if I can also get our Win7 builder up again. This would give us "Build GCCWin_x86", "Build MSVC_x64" and "Build MSVC_x86". I cannot resurrect the VMware and VBox testers right now though. This will definitely need another machine. Will look after this in October. Maybe we can also get a RAM upgrade for the existing machine to enable building on RAM Disks again. Cheers, Colin

8 years, 7 months

3
6
0 0

Re: [ros-dev] [ros-diffs] [gadamopoulos] 72398: [SHELL32] - Fail to delete any file if one is invalid. - Patch by andy-123 CORE-9959

by Love Nystrom

On 2016-08-28 19.00, ros-dev-request(a)reactos.org wrote: > Subject: > Re: [ros-dev] [ros-diffs] [gadamopoulos] 72398: [SHELL32] - Fail to > delete any file if one is invalid. - Patch by andy-123 CORE-9959 > From: > Thomas Faber <thomas.faber(a)reactos.org> > Date: > 2016-08-28 15.42 > > To: > ros-dev(a)reactos.org > > > On 2016-08-20 11:43,gadamopoulos@svn.reactos.org wrote: >> >--- trunk/reactos/dll/win32/shell32/shlfileop.cpp [iso-8859-1] (original) >> >+++ trunk/reactos/dll/win32/shell32/shlfileop.cpp [iso-8859-1] Sat Aug 20 09:43:09 2016 >> >@@ -1480,6 +1480,19 @@ >> > return 0; >> > } >> > >> >+ /* Check files. Do not delete one if one file does not exists */ >> >+ for (i = 0; i < flFrom->dwNumFiles; i++) >> >+ { >> >+ fileEntry = &flFrom->feFiles[i]; >> >+ >> >+ if ((HANDLE)fileEntry->attributes == INVALID_HANDLE_VALUE) > What's wrong with INVALID_FILE_ATTRIBUTES? Fully agree with Thomas.. That is wrong.. Attributes are not handles. Further, this replicates the unacceptable behavior of the Windows shell, whereby an entire list of files is dropped when just one fail. I've argued, some years ago, that such lists should be continued, ideally adding failed files to a "failed" list to be presented to the user. You can *not* make any valid assumption of whether other files in the list will fail just because one of them doesn't exist, or cant be moved because it's locked, or whatever. That you are currently writing on this code gives you a good opportunity to make our shell better than Microsoft's in this regard. Best Regards // Neo > >> >+ { >> >+ // This is a windows 2003 server specific value which has been removed. >> >+ // Later versions of windows return ERROR_FILE_NOT_FOUND. >> >+ return ERROR_SHELL_INTERNAL_FILE_NOT_FOUND; >> >+ } >> >+ } >> >+ >> > for (i = 0; i < flFrom->dwNumFiles; i++) >> > { >> > bPathExists = TRUE; -- There is one thing stronger than all the armies in the world, and that's an idea whose time has come. [Victor Hugo]

8 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 72655: [NtUser] Try to fix tests for user32:EnumDisplaySettings

by Thomas Faber

I've seen like 4 people change this stuff recently and not one of them got it 100% right. So here are the rules for how to use probes and SEH: * Probe pointers before accessing them. This ensures you're not reading kernel mode memory (and does pretty much nothing else) * Never access user mode pointers outside of SEH. The application controls its address space, so protection, physical memory mapping and contents can change out from under you at any point. For most purposes, MmProbeAndLockPages is the only way to get around this. * Sometimes there is no alternative to copying data to kernel memory. If there is a pointer stored in user mode memory, you need a copy of it because you can't rely on it not changing after your probe (even if you lock down the memory). * In case of an exception you usually want to return the exception code. There are exceptions (heh) to this rule, but if you think you've found one, better be sure and show it with a test. * If you make a pool allocation whose size is directly influenced by user mode input, there's a good chance you'll want to use ExAllocatePoolWithQuotaTag In particular this means: * Probing something or accessing it once does not save you from using SEH every single time you access the user mode memory * Probing UserModePointer->StructMemberPointer is never correct, you need to make a copy of the struct or that particular member, since the memory can change * The ProbeForReadUnicodeString function is not useful unless you use its return value Hope this helps. Thanks for hanging in there. -T On 2016-09-11 18:13, dchapyshev(a)svn.reactos.org wrote: > Author: dchapyshev > Date: Sun Sep 11 16:13:46 2016 > New Revision: 72655 > > URL: http://svn.reactos.org/svn/reactos?rev=72655&view=rev > Log: > [NtUser] Try to fix tests for user32:EnumDisplaySettings > > Modified: > trunk/reactos/win32ss/user/ntuser/display.c > > Modified: trunk/reactos/win32ss/user/ntuser/display.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/displa… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/display.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/display.c [iso-8859-1] Sun Sep 11 16:13:46 2016 > @@ -443,7 +443,7 @@ > { > /* No device found */ > ERR("No PDEV found!\n"); > - return STATUS_UNSUCCESSFUL; > + return STATUS_INVALID_PARAMETER_1; > } > > *ppdm = ppdev->pdmwDev; > @@ -474,7 +474,7 @@ > { > /* No device found */ > ERR("No device found!\n"); > - return STATUS_UNSUCCESSFUL; > + return STATUS_INVALID_PARAMETER_1; > } > > iFoundMode = 0; > @@ -571,13 +571,18 @@ > > _SEH2_TRY > { > - ProbeForWrite(lpDevMode, sizeof(DEVMODEW), 1); > + ProbeForRead(lpDevMode, sizeof(DEVMODEW), 1); > + > + cbSize = lpDevMode->dmSize; > + cbExtra = lpDevMode->dmDriverExtra; > + > + ProbeForWrite(lpDevMode, cbSize + cbExtra, 1); > } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > { > _SEH2_YIELD(return _SEH2_GetExceptionCode()); > } > - _SEH2_END > + _SEH2_END; > > if (lpDevMode->dmSize != sizeof(DEVMODEW)) > { > @@ -586,31 +591,30 @@ > > if (pustrDevice) > { > - if (pustrDevice->Buffer == NULL || pustrDevice->Length == 0) > - { > - Status = STATUS_INVALID_PARAMETER_1; > - } > - > /* Initialize destination string */ > RtlInitEmptyUnicodeString(&ustrDevice, awcDevice, sizeof(awcDevice)); > > _SEH2_TRY > { > /* Probe the UNICODE_STRING and the buffer */ > - ProbeForRead(pustrDevice, sizeof(UNICODE_STRING), 1); > - ProbeForRead(pustrDevice->Buffer, pustrDevice->Length, 1); > + ProbeForReadUnicodeString(pustrDevice); > + > + if (!pustrDevice->Length || !pustrDevice->Buffer) > + ExRaiseStatus(STATUS_NO_MEMORY); > + > + ProbeForRead(pustrDevice->Buffer, pustrDevice->Length, sizeof(UCHAR)); > > /* Copy the string */ > RtlCopyUnicodeString(&ustrDevice, pustrDevice); > } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > { > - _SEH2_YIELD(return _SEH2_GetExceptionCode()); > - } > - _SEH2_END > + _SEH2_YIELD(return STATUS_INVALID_PARAMETER_1); > + } > + _SEH2_END; > > pustrDevice = &ustrDevice; > - } > + } > > /* Acquire global USER lock */ > UserEnterShared(); > @@ -642,11 +646,6 @@ > /* Copy some information back */ > _SEH2_TRY > { > - ProbeForRead(lpDevMode, sizeof(DEVMODEW), 1); > - cbSize = lpDevMode->dmSize; > - cbExtra = lpDevMode->dmDriverExtra; > - > - ProbeForWrite(lpDevMode, cbSize + cbExtra, 1); > /* Output what we got */ > RtlCopyMemory(lpDevMode, pdm, min(cbSize, pdm->dmSize)); > > @@ -663,13 +662,6 @@ > Status = _SEH2_GetExceptionCode(); > } > _SEH2_END; > - } > - else > - { > - if (Status == STATUS_UNSUCCESSFUL) > - { > - Status = STATUS_INVALID_PARAMETER_1; > - } > } > > return Status; > >

8 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 72594: [FLTMGR] - Implement FltLoadFilter and stub FltUnloadFilter - Register contexts if the caller requests (coming later) - Stubpliment FltStartFiltering

by Thomas Faber

On 2016-09-06 18:47, gedmurphy(a)svn.reactos.org wrote: > @@ -116,12 +150,21 @@ > InitializeListHead(&Filter->PortList.mList); > Filter->PortList.mCount = 0; > > + /* We got this far, assume success from here */ > + Status = STATUS_SUCCESS; > + > /* Check if the caller requested any context data */ > if (Registration->ContextRegistration) > { > - // register the context information > - } > - > + /* Register the contexts for this filter */ > + Status = FltpRegisterContexts(Filter, Registration->ContextRegistration); > + if (NT_SUCCESS(Status)) I think you mean !NT_SUCCESS? > + { > + goto Quit; > + } > + } > + > + /* Check if the caller is registering any callbacks */ > if (Registration->OperationRegistration) > { > /* The callback data comes after the fixed struct */ > @@ -162,7 +205,7 @@ > // - More stuff?? > // > > -//Quit: > +Quit: > if (!NT_SUCCESS(Status)) > { > // Add cleanup for context resources

8 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 72595: [FLTMGR] - Add stubs for context registration - Add dispatch and device control handlers - Implement the load IOCTL. We can now load minifilters with 'fltmc load <myfilter>'

by Thomas Faber

On 2016-09-06 18:59, gedmurphy(a)svn.reactos.org wrote: > +NTSTATUS > +HandleLoadUnloadIoctl(_In_ PDEVICE_OBJECT DeviceObject, > + _Inout_ PIRP Irp) > +{ > + PIO_STACK_LOCATION StackPtr; > + UNICODE_STRING Name; > + PFILTER_NAME FilterName; > + ULONG BufferLength; > + ULONG ControlCode; > + > + /* Get the IOCTL data from the stack pointer */ > + StackPtr = IoGetCurrentIrpStackLocation(Irp); > + BufferLength = StackPtr->Parameters.DeviceIoControl.InputBufferLength; > + ControlCode = StackPtr->Parameters.DeviceIoControl.IoControlCode; > + > + FLT_ASSERT(ControlCode == IOCTL_LOAD_FILTER || ControlCode == IOCTL_UNLOAD_FILTER); > + > + /* Make sure the buffer is valid */ > + if (BufferLength < sizeof(FILTER_NAME)) > + return STATUS_INVALID_PARAMETER; > + > + /* Convert the file name buffer into a string */ > + FilterName = (PFILTER_NAME)Irp->AssociatedIrp.SystemBuffer; > + Name.Length = FilterName->Length; > + Name.MaximumLength = FilterName->Length; > + Name.Buffer = (PWCH)((PCHAR)FilterName + FIELD_OFFSET(FILTER_NAME, FilterName[0])); You're missing a check for BufferLength < FIELD_OFFSET(FILTER_NAME, FilterName[FilterName->Length / sizeof(WCHAR)]) > + > + /* Forward the request to our Flt routines */ > + if (ControlCode == IOCTL_LOAD_FILTER) > + { > + return FltLoadFilter(&Name); > + } > + else > + { > + return FltUnloadFilter(&Name); > + } > +}

8 years, 7 months

1
0
0 0

Re: [ros-dev] where is the final report for AHCI GSoC?

by Alex Ionescu

Hi Alexander, All the check-ins were mirrored in our SVN repository branch, and the official GSOC page has a link to the Wiki. Best regards, Alex Ionescu On Sun, Sep 4, 2016 at 2:57 AM, Alexander Rechitskiy <art1st-tm(a)yandex.ru> wrote: > Thank you for prompt answer. > Me and some other ppl have worried about getting not so much news about > progress of this project as we expected. I did not know that you have > decided to use github for final report. > > 04.09.2016, 12:47, "Aman Priyadarshi" <aman.eureka(a)gmail.com>: > > Hi, > > Please read the wiki page > https://github.com/amaneureka/reactos/wiki/Storahci > > Link is also available of GSoC website. > ᐧ > > > Regards > *Aman Priyadarshi* > *www.atomixos.com <http://www.atomixos.com/>* > > On Sun, Sep 4, 2016 at 3:07 PM, Alexander Rechitskiy <art1st-tm(a)yandex.ru> > wrote: > > > > 04.09.2016, 12:09, "Alexander Rechitskiy" art1st-tm(a)yandex.ru: > > > > Have we failed this project? > > > > > As I know, project was NOT failed! I just wanted to read the final report. > > -- > Best regards, > > > _______________________________________________ > 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 > > > > -- > Best regards, > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > >

8 years, 7 months

1
0
0 0

where is the final report for AHCI GSoC?

by Alexander Rechitskiy

8 years, 7 months

2
3
0 0

Infrastructure team application - Resending after subscribing

by Vyronas Tsingaras

Dear all, My name is Vyron Tsingaras a 23 year old currently employed as a Systems and Network Administrator at AMD Telecom S.A. My work duties involve maintainance and installation of Linux servers, XenSerevr hypervisors, networking equipment (Cisco ISR, Cisco ITP, Cisco ASA, Fortigate firewalls, Mikrotik routers, pfSense firewalls) and basic MySQL administration. I love using Ops automation tools (pref. Ansible) and have experience scripting and developing in Python. I have followed ReactOS for quite some time and me being an unqualified programmer for systems programming for contributing code to such a complex project I feel that this is a position I am better qualified for. I am from Greece (UTC+2) and my work hours are 9-5.30. I will be available after work hours and on weekends always providing notifcation if I will be unavailable. I feel excited at the prospect of contributing to an open source project of this scale and look forward to working with all of you should I be accepted. Best Regards, Vyron Tsingaras.

8 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [gadamopoulos] 72398: [SHELL32] - Fail to delete any file if one is invalid. - Patch by andy-123 CORE-9959

by Thomas Faber

On 2016-08-20 11:43, gadamopoulos(a)svn.reactos.org wrote: > --- trunk/reactos/dll/win32/shell32/shlfileop.cpp [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/shell32/shlfileop.cpp [iso-8859-1] Sat Aug 20 09:43:09 2016 > @@ -1480,6 +1480,19 @@ > return 0; > } > > + /* Check files. Do not delete one if one file does not exists */ > + for (i = 0; i < flFrom->dwNumFiles; i++) > + { > + fileEntry = &flFrom->feFiles[i]; > + > + if ((HANDLE)fileEntry->attributes == INVALID_HANDLE_VALUE) What's wrong with INVALID_FILE_ATTRIBUTES? > + { > + // This is a windows 2003 server specific value which has been removed. > + // Later versions of windows return ERROR_FILE_NOT_FOUND. > + return ERROR_SHELL_INTERNAL_FILE_NOT_FOUND; > + } > + } > + > for (i = 0; i < flFrom->dwNumFiles; i++) > { > bPathExists = TRUE;

8 years, 7 months

1
0
0 0

Status Meeting (August 2016)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place this Thursday, 25th of August, 19:00 UTC. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. The backup place to conduct meetings is #reactos-meeting channel on Freenode. Please send agenda proposals to me before the meeting so we don't waste time trying to setup the agenda directly during the meeting. Regards, Aleksey Bragin

8 years, 7 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [jgardou] 72435: [KDGDB] - Implement setting and removing breakpoints - Implement single-stepping - Only get past the breakpoint instruction when it comes from RtlpBreakWithStatus - Implement writi...

by Pierre Schweitzer

Sorry, I had forgotten this: Le 23/08/2016 à 00:24, jgardou(a)svn.reactos.org a écrit : > Author: jgardou > Date: Mon Aug 22 22:24:30 2016 > New Revision: 72435 > > URL: http://svn.reactos.org/svn/reactos?rev=72435&view=rev > Log: > [KDGDB] > - Implement setting and removing breakpoints > - Implement single-stepping > - Only get past the breakpoint instruction when it comes from RtlpBreakWithStatus > - Implement writing to memory > - Always send the thread raising the exception to GDB to avoid confusing it > - Let GDB find the program counter alone by querying the registers (support was already there before.) > - Properly escape special characters on input > Ladies and gentlemen : the almost-fully functional GDB stub. (still no real multi-process support :-( ) > To enable , in CMakeCache.txt : > - Set GDB:BOOL=TRUE > - Set _WINKD_:BOOL=TRUE > - Set KDBG:BOOL=FALSE > To do : give GDB the list of loaded drivers. Loading ntoskrnl.exe symbols at 0x80801000 already does a good enough job. > Default output is on COM1. Can be configure to any othe COM port with usual kernel options. > Hope you'll like it as much as I do ;-) > > Modified: > trunk/reactos/drivers/base/kdgdb/gdb_input.c > trunk/reactos/drivers/base/kdgdb/gdb_receive.c > trunk/reactos/drivers/base/kdgdb/gdb_send.c > trunk/reactos/drivers/base/kdgdb/i386_sup.c > trunk/reactos/drivers/base/kdgdb/kdcom.c > trunk/reactos/drivers/base/kdgdb/kdgdb.h > trunk/reactos/drivers/base/kdgdb/kdpacket.c > > Modified: trunk/reactos/drivers/base/kdgdb/gdb_input.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/kdgdb/gdb_inp… > ============================================================================== > --- trunk/reactos/drivers/base/kdgdb/gdb_input.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/base/kdgdb/gdb_input.c [iso-8859-1] Mon Aug 22 22:24:30 2016 > @@ -9,6 +9,11 @@ > > /* LOCALS *********************************************************************/ > static ULONG_PTR gdb_run_tid; > +static struct > +{ > + ULONG_PTR Address; > + ULONG Handle; > +} BreakPointHandles[32]; > > > /* GLOBALS ********************************************************************/ > @@ -203,16 +208,15 @@ > > if (!Resuming) > { > + /* Report the idle thread */ > +#if MONOPROCESS > + ptr += sprintf(ptr, "1"); > +#else > + ptr += sprintf(gdb, "p1.1"); > +#endif That looks highly suspicious? Shouldn't it be ptr += sprintf(ptr, "p1.1"); -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

8 years, 8 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [jgardou] 72435: [KDGDB] - Implement setting and removing breakpoints - Implement single-stepping - Only get past the breakpoint instruction when it comes from RtlpBreakWithStatus - Implement writi...

by Pierre Schweitzer

Hi Jérome, First of all, amazing work. Thanks for it! Is this page still relevant regarding debugging with GDB? https://www.reactos.org/wiki/GDB Or is there a new way to configure ReactOS/client side (Linux, ideally :-p). Cheers, Pierre Le 23/08/2016 à 00:24, jgardou(a)svn.reactos.org a écrit : > Author: jgardou > Date: Mon Aug 22 22:24:30 2016 > New Revision: 72435 > > URL: http://svn.reactos.org/svn/reactos?rev=72435&view=rev > Log: > [KDGDB] > - Implement setting and removing breakpoints > - Implement single-stepping > - Only get past the breakpoint instruction when it comes from RtlpBreakWithStatus > - Implement writing to memory > - Always send the thread raising the exception to GDB to avoid confusing it > - Let GDB find the program counter alone by querying the registers (support was already there before.) > - Properly escape special characters on input > Ladies and gentlemen : the almost-fully functional GDB stub. (still no real multi-process support :-( ) > To enable , in CMakeCache.txt : > - Set GDB:BOOL=TRUE > - Set _WINKD_:BOOL=TRUE > - Set KDBG:BOOL=FALSE > To do : give GDB the list of loaded drivers. Loading ntoskrnl.exe symbols at 0x80801000 already does a good enough job. > Default output is on COM1. Can be configure to any othe COM port with usual kernel options. > Hope you'll like it as much as I do ;-) > > Modified: > trunk/reactos/drivers/base/kdgdb/gdb_input.c > trunk/reactos/drivers/base/kdgdb/gdb_receive.c > trunk/reactos/drivers/base/kdgdb/gdb_send.c > trunk/reactos/drivers/base/kdgdb/i386_sup.c > trunk/reactos/drivers/base/kdgdb/kdcom.c > trunk/reactos/drivers/base/kdgdb/kdgdb.h > trunk/reactos/drivers/base/kdgdb/kdpacket.c > > Modified: trunk/reactos/drivers/base/kdgdb/gdb_input.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/kdgdb/gdb_inp… > ============================================================================== > --- trunk/reactos/drivers/base/kdgdb/gdb_input.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/base/kdgdb/gdb_input.c [iso-8859-1] Mon Aug 22 22:24:30 2016 > @@ -9,6 +9,11 @@ > > /* LOCALS *********************************************************************/ > static ULONG_PTR gdb_run_tid; > +static struct > +{ > + ULONG_PTR Address; > + ULONG Handle; > +} BreakPointHandles[32]; > > > /* GLOBALS ********************************************************************/ > @@ -203,16 +208,15 @@ > > if (!Resuming) > { > + /* Report the idle thread */ > +#if MONOPROCESS > + ptr += sprintf(ptr, "1"); > +#else > + ptr += sprintf(gdb, "p1.1"); > +#endif > /* Initialize the entries */ > CurrentProcessEntry = ProcessListHead->Flink; > CurrentThreadEntry = NULL; > - > - /* Start with idle thread */ > -#if MONOPROCESS > - ptr = gdb_out + sprintf(gdb_out, "m1"); > -#else > - ptr = gdb_out + sprintf(gdb_out, "mp1.1"); > -#endif > FirstThread = FALSE; > } > > @@ -306,8 +310,8 @@ > Thread = find_thread(Pid, Tid); > Process = CONTAINING_RECORD(Thread->Tcb.Process, EPROCESS, Pcb); > #else > - Pid = hex_to_pid(&gdb_input[2]); > - Tid = hex_to_tid(strstr(gdb_input, ".") + 1); > + Pid = hex_to_pid(&gdb_input[18]); > + Tid = hex_to_tid(strstr(&gdb_input[18], ".") + 1); > > /* We cannot use PsLookupProcessThreadByCid as we could be running at any IRQL. > * So loop. */ > @@ -394,21 +398,23 @@ > KDDBGPRINT("Wrong API number (%lu) after DbgKdReadVirtualMemoryApi request.\n", State->ApiNumber); > } > > - /* Check status */ > - if (!NT_SUCCESS(State->ReturnStatus)) > + /* Check status. Allow to send partial data. */ > + if (!MessageData->Length && !NT_SUCCESS(State->ReturnStatus)) > send_gdb_ntstatus(State->ReturnStatus); > else > send_gdb_memory(MessageData->Buffer, MessageData->Length); > KdpSendPacketHandler = NULL; > KdpManipulateStateHandler = NULL; > > -#if !MONOPROCESS > +#if MONOPROCESS > + if (gdb_dbg_tid != 0) > /* Reset the TLB */ > +#else > if ((gdb_dbg_pid != 0) && gdb_pid_to_handle(gdb_dbg_pid) != PsGetCurrentProcessId()) > +#endif > { > __writecr3(PsGetCurrentProcess()->Pcb.DirectoryTableBase[0]); > } > -#endif > } > > static > @@ -427,8 +433,29 @@ > MessageData->Length = 0; > *MessageLength = 0; > > -#if !MONOPROCESS > /* Set the TLB according to the process being read. Pid 0 means any process. */ > +#if MONOPROCESS > + if ((gdb_dbg_tid != 0) && gdb_tid_to_handle(gdb_dbg_tid) != PsGetCurrentThreadId()) > + { > + PETHREAD AttachedThread = find_thread(0, gdb_dbg_tid); > + PKPROCESS AttachedProcess; > + if (AttachedThread == NULL) > + { > + KDDBGPRINT("The current GDB debug thread is invalid!"); > + send_gdb_packet("E03"); > + return (KDSTATUS)-1; > + } > + > + AttachedProcess = AttachedThread->Tcb.Process; > + if (AttachedProcess == NULL) > + { > + KDDBGPRINT("The current GDB debug thread is invalid!"); > + send_gdb_packet("E03"); > + return (KDSTATUS)-1; > + } > + __writecr3(AttachedProcess->DirectoryTableBase[0]); > + } > +#else > if ((gdb_dbg_pid != 0) && gdb_pid_to_handle(gdb_dbg_pid) != PsGetCurrentProcessId()) > { > PEPROCESS AttachedProcess = find_process(gdb_dbg_pid); > @@ -436,7 +463,7 @@ > { > KDDBGPRINT("The current GDB debug thread is invalid!"); > send_gdb_packet("E03"); > - return gdb_receive_and_interpret_packet(State, MessageData, MessageLength, KdContext); > + return (KDSTATUS)-1; > } > __writecr3(AttachedProcess->Pcb.DirectoryTableBase[0]); > } > @@ -448,6 +475,388 @@ > /* KD will reply with KdSendPacket. Catch it */ > KdpSendPacketHandler = ReadMemorySendHandler; > > + return KdPacketReceived; > +} > + > +static > +void > +WriteMemorySendHandler( > + _In_ ULONG PacketType, > + _In_ PSTRING MessageHeader, > + _In_ PSTRING MessageData) > +{ > + DBGKD_MANIPULATE_STATE64* State = (DBGKD_MANIPULATE_STATE64*)MessageHeader->Buffer; > + > + if (PacketType != PACKET_TYPE_KD_STATE_MANIPULATE) > + { > + // KdAssert > + KDDBGPRINT("Wrong packet type (%lu) received after DbgKdWriteVirtualMemoryApi request.\n", PacketType); > + while (1); > + } > + > + if (State->ApiNumber != DbgKdWriteVirtualMemoryApi) > + { > + KDDBGPRINT("Wrong API number (%lu) after DbgKdWriteVirtualMemoryApi request.\n", State->ApiNumber); > + } > + > + /* Check status */ > + if (!NT_SUCCESS(State->ReturnStatus)) > + send_gdb_ntstatus(State->ReturnStatus); > + else > + send_gdb_packet("OK"); > + KdpSendPacketHandler = NULL; > + KdpManipulateStateHandler = NULL; > + > +#if MONOPROCESS > + if (gdb_dbg_tid != 0) > + /* Reset the TLB */ > +#else > + if ((gdb_dbg_pid != 0) && gdb_pid_to_handle(gdb_dbg_pid) != PsGetCurrentProcessId()) > +#endif > + { > + __writecr3(PsGetCurrentProcess()->Pcb.DirectoryTableBase[0]); > + } > +} > + > +static > +KDSTATUS > +handle_gdb_write_mem( > + _Out_ DBGKD_MANIPULATE_STATE64* State, > + _Out_ PSTRING MessageData, > + _Out_ PULONG MessageLength, > + _Inout_ PKD_CONTEXT KdContext) > +{ > + /* Maximal input buffer is 0x1000. Each byte is encoded on two bytes by GDB */ > + static UCHAR OutBuffer[0x800]; > + ULONG BufferLength; > + char* blob_ptr; > + UCHAR* OutPtr; > + > + State->ApiNumber = DbgKdWriteVirtualMemoryApi; > + State->ReturnStatus = STATUS_SUCCESS; /* ? */ > + State->Processor = CurrentStateChange.Processor; > + State->ProcessorLevel = CurrentStateChange.ProcessorLevel; > + > + /* Set the TLB according to the process being read. Pid 0 means any process. */ > +#if MONOPROCESS > + if ((gdb_dbg_tid != 0) && gdb_tid_to_handle(gdb_dbg_tid) != PsGetCurrentThreadId()) > + { > + PETHREAD AttachedThread = find_thread(0, gdb_dbg_tid); > + PKPROCESS AttachedProcess; > + if (AttachedThread == NULL) > + { > + KDDBGPRINT("The current GDB debug thread is invalid!"); > + send_gdb_packet("E03"); > + return (KDSTATUS)-1; > + } > + > + AttachedProcess = AttachedThread->Tcb.Process; > + if (AttachedProcess == NULL) > + { > + KDDBGPRINT("The current GDB debug thread is invalid!"); > + send_gdb_packet("E03"); > + return (KDSTATUS)-1; > + } > + __writecr3(AttachedProcess->DirectoryTableBase[0]); > + } > +#else > + if ((gdb_dbg_pid != 0) && gdb_pid_to_handle(gdb_dbg_pid) != PsGetCurrentProcessId()) > + { > + PEPROCESS AttachedProcess = find_process(gdb_dbg_pid); > + if (AttachedProcess == NULL) > + { > + KDDBGPRINT("The current GDB debug thread is invalid!"); > + send_gdb_packet("E03"); > + return (KDSTATUS)-1; > + } > + __writecr3(AttachedProcess->Pcb.DirectoryTableBase[0]); > + } > +#endif > + > + State->u.WriteMemory.TargetBaseAddress = hex_to_address(&gdb_input[1]); > + BufferLength = hex_to_address(strstr(&gdb_input[1], ",") + 1); > + if (BufferLength == 0) > + { > + /* Nothing to do */ > + send_gdb_packet("OK"); > + return (KDSTATUS)-1; > + } > + > + State->u.WriteMemory.TransferCount = BufferLength; > + MessageData->Length = BufferLength; > + MessageData->Buffer = (CHAR*)OutBuffer; > + > + OutPtr = OutBuffer; > + blob_ptr = strstr(strstr(&gdb_input[1], ",") + 1, ":") + 1; > + while (BufferLength) > + { > + if (BufferLength >= 4) > + { > + *((ULONG*)OutPtr) = *((ULONG*)blob_ptr); > + OutPtr += 4; > + blob_ptr += 4; > + BufferLength -= 4; > + } > + else if (BufferLength >= 2) > + { > + *((USHORT*)OutPtr) = *((USHORT*)blob_ptr); > + OutPtr += 2; > + blob_ptr += 2; > + BufferLength -= 2; > + } > + else > + { > + *OutPtr++ = *blob_ptr++; > + BufferLength--; > + } > + } > + > + /* KD will reply with KdSendPacket. Catch it */ > + KdpSendPacketHandler = WriteMemorySendHandler; > + > + return KdPacketReceived; > +} > + > +static > +void > +WriteBreakPointSendHandler( > + _In_ ULONG PacketType, > + _In_ PSTRING MessageHeader, > + _In_ PSTRING MessageData) > +{ > + DBGKD_MANIPULATE_STATE64* State = (DBGKD_MANIPULATE_STATE64*)MessageHeader->Buffer; > + > + if (PacketType != PACKET_TYPE_KD_STATE_MANIPULATE) > + { > + // KdAssert > + KDDBGPRINT("Wrong packet type (%lu) received after DbgKdWriteBreakPointApi request.\n", PacketType); > + while (1); > + } > + > + if (State->ApiNumber != DbgKdWriteBreakPointApi) > + { > + KDDBGPRINT("Wrong API number (%lu) after DbgKdWriteBreakPointApi request.\n", State->ApiNumber); > + } > + > + /* Check status */ > + if (!NT_SUCCESS(State->ReturnStatus)) > + { > + KDDBGPRINT("Inserting breakpoint failed!\n"); > + send_gdb_ntstatus(State->ReturnStatus); > + } > + else > + { > + /* Keep track of the address+handle couple */ > + ULONG i; > + for (i = 0; i < (sizeof(BreakPointHandles) / sizeof(BreakPointHandles[0])); i++) > + { > + if (BreakPointHandles[i].Address == 0) > + { > + BreakPointHandles[i].Address = (ULONG_PTR)State->u.WriteBreakPoint.BreakPointAddress; > + BreakPointHandles[i].Handle = State->u.WriteBreakPoint.BreakPointHandle; > + break; > + } > + } > + send_gdb_packet("OK"); > + } > + KdpSendPacketHandler = NULL; > + KdpManipulateStateHandler = NULL; > +} > + > +static > +KDSTATUS > +handle_gdb_insert_breakpoint( > + _Out_ DBGKD_MANIPULATE_STATE64* State, > + _Out_ PSTRING MessageData, > + _Out_ PULONG MessageLength, > + _Inout_ PKD_CONTEXT KdContext) > +{ > + State->ReturnStatus = STATUS_SUCCESS; /* ? */ > + State->Processor = CurrentStateChange.Processor; > + State->ProcessorLevel = CurrentStateChange.ProcessorLevel; > + if (MessageData) > + MessageData->Length = 0; > + *MessageLength = 0; > + > + switch (gdb_input[1]) > + { > + case '0': > + { > + ULONG_PTR Address = hex_to_address(&gdb_input[3]); > + ULONG i; > + BOOLEAN HasFreeSlot = FALSE; > + > + KDDBGPRINT("Inserting breakpoint at %p.\n", (void*)Address); > + > + for (i = 0; i < (sizeof(BreakPointHandles) / sizeof(BreakPointHandles[0])); i++) > + { > + if (BreakPointHandles[i].Address == 0) > + HasFreeSlot = TRUE; > + } > + > + if (!HasFreeSlot) > + { > + /* We don't have a way to keep track of this break point. Fail. */ > + KDDBGPRINT("No breakpoint slot available!\n"); > + send_gdb_packet("E01"); > + return (KDSTATUS)-1; > + } > + > + State->ApiNumber = DbgKdWriteBreakPointApi; > + State->u.WriteBreakPoint.BreakPointAddress = Address; > + /* FIXME : ignoring all other Z0 arguments */ > + > + /* KD will reply with KdSendPacket. Catch it */ > + KdpSendPacketHandler = WriteBreakPointSendHandler; > + return KdPacketReceived; > + } > + } > + > + KDDBGPRINT("Unhandled 'Z' packet: %s\n", gdb_input); > + send_gdb_packet("E01"); > + return (KDSTATUS)-1; > +} > + > +static > +void > +RestoreBreakPointSendHandler( > + _In_ ULONG PacketType, > + _In_ PSTRING MessageHeader, > + _In_ PSTRING MessageData) > +{ > + DBGKD_MANIPULATE_STATE64* State = (DBGKD_MANIPULATE_STATE64*)MessageHeader->Buffer; > + ULONG i; > + > + if (PacketType != PACKET_TYPE_KD_STATE_MANIPULATE) > + { > + // KdAssert > + KDDBGPRINT("Wrong packet type (%lu) received after DbgKdRestoreBreakPointApi request.\n", PacketType); > + while (1); > + } > + > + if (State->ApiNumber != DbgKdRestoreBreakPointApi) > + { > + KDDBGPRINT("Wrong API number (%lu) after DbgKdRestoreBreakPointApi request.\n", State->ApiNumber); > + } > + > + /* We ignore failure here. If DbgKdRestoreBreakPointApi fails, > + * this means that the breakpoint was already invalid for KD. So clean it up on our side. */ > + for (i = 0; i < (sizeof(BreakPointHandles) / sizeof(BreakPointHandles[0])); i++) > + { > + if (BreakPointHandles[i].Handle == State->u.RestoreBreakPoint.BreakPointHandle) > + { > + BreakPointHandles[i].Address = 0; > + BreakPointHandles[i].Handle = 0; > + break; > + } > + } > + > + send_gdb_packet("OK"); > + > + KdpSendPacketHandler = NULL; > + KdpManipulateStateHandler = NULL; > +} > + > +static > +KDSTATUS > +handle_gdb_remove_breakpoint( > + _Out_ DBGKD_MANIPULATE_STATE64* State, > + _Out_ PSTRING MessageData, > + _Out_ PULONG MessageLength, > + _Inout_ PKD_CONTEXT KdContext) > +{ > + State->ReturnStatus = STATUS_SUCCESS; /* ? */ > + State->Processor = CurrentStateChange.Processor; > + State->ProcessorLevel = CurrentStateChange.ProcessorLevel; > + if (MessageData) > + MessageData->Length = 0; > + *MessageLength = 0; > + > + switch (gdb_input[1]) > + { > + case '0': > + { > + ULONG_PTR Address = hex_to_address(&gdb_input[3]); > + ULONG i, Handle = 0; > + > + KDDBGPRINT("Removing breakpoint on %p.\n", (void*)Address); > + > + for (i = 0; i < (sizeof(BreakPointHandles) / sizeof(BreakPointHandles[0])); i++) > + { > + if (BreakPointHandles[i].Address == Address) > + { > + Handle = BreakPointHandles[i].Handle; > + break; > + } > + } > + > + if (Handle == 0) > + { > + KDDBGPRINT("Received %s, but breakpoint was never inserted ?!\n", gdb_input); > + send_gdb_packet("E01"); > + return (KDSTATUS)-1; > + } > + > + State->ApiNumber = DbgKdRestoreBreakPointApi; > + State->u.RestoreBreakPoint.BreakPointHandle = Handle; > + /* FIXME : ignoring all other z0 arguments */ > + > + /* KD will reply with KdSendPacket. Catch it */ > + KdpSendPacketHandler = RestoreBreakPointSendHandler; > + return KdPacketReceived; > + } > + } > + > + KDDBGPRINT("Unhandled 'Z' packet: %s\n", gdb_input); > + send_gdb_packet("E01"); > + return (KDSTATUS)-1; > +} > + > +static > +KDSTATUS > +handle_gdb_c( > + _Out_ DBGKD_MANIPULATE_STATE64* State, > + _Out_ PSTRING MessageData, > + _Out_ PULONG MessageLength, > + _Inout_ PKD_CONTEXT KdContext) > +{ > + /* Tell GDB everything is fine, we will handle it */ > + send_gdb_packet("OK"); > + > + if (CurrentStateChange.NewState == DbgKdExceptionStateChange) > + { > + DBGKM_EXCEPTION64* Exception = &CurrentStateChange.u.Exception; > + ULONG_PTR ProgramCounter = KdpGetContextPc(&CurrentContext); > + > + /* See if we should update the program counter */ > + if (Exception && (Exception->ExceptionRecord.ExceptionCode == STATUS_BREAKPOINT) > + && ProgramCounter == KdDebuggerDataBlock->BreakpointWithStatus.Pointer) > + { > + /* We must get past the breakpoint instruction */ > + KdpSetContextPc(&CurrentContext, ProgramCounter + KD_BREAKPOINT_SIZE); > + > + SetContextManipulateHandler(State, MessageData, MessageLength, KdContext); > + KdpManipulateStateHandler = ContinueManipulateStateHandler; > + return KdPacketReceived; > + } > + } > + > + return ContinueManipulateStateHandler(State, MessageData, MessageLength, KdContext); > +} > + > +static > +KDSTATUS > +handle_gdb_s( > + _Out_ DBGKD_MANIPULATE_STATE64* State, > + _Out_ PSTRING MessageData, > + _Out_ PULONG MessageLength, > + _Inout_ PKD_CONTEXT KdContext) > +{ > + KDDBGPRINT("Single stepping.\n"); > + /* Set CPU single step mode and continue */ > + KdpSetSingleStep(&CurrentContext); > + SetContextManipulateHandler(State, MessageData, MessageLength, KdContext); > + KdpManipulateStateHandler = ContinueManipulateStateHandler; > return KdPacketReceived; > } > > @@ -464,36 +873,19 @@ > if (gdb_input[5] == '?') > { > /* Report what we support */ > - send_gdb_packet("vCont;c;C;s;S"); > + send_gdb_packet("vCont;c;s"); > return (KDSTATUS)-1; > } > > if (strncmp(gdb_input, "vCont;c", 7) == 0) > { > - DBGKM_EXCEPTION64* Exception = NULL; > - > - /* Tell GDB everything is fine, we will handle it */ > - send_gdb_packet("OK"); > - > - if (CurrentStateChange.NewState == DbgKdExceptionStateChange) > - Exception = &CurrentStateChange.u.Exception; > - > - /* See if we should update the program counter (unlike windbg, gdb doesn't do it for us) */ > - if (Exception && (Exception->ExceptionRecord.ExceptionCode == STATUS_BREAKPOINT) > - && (Exception->ExceptionRecord.ExceptionInformation[0] == 0)) > - { > - ULONG_PTR ProgramCounter; > - > - /* So we must get past the breakpoint instruction */ > - ProgramCounter = KdpGetContextPc(&CurrentContext); > - KdpSetContextPc(&CurrentContext, ProgramCounter + KD_BREAKPOINT_SIZE); > - > - SetContextManipulateHandler(State, MessageData, MessageLength, KdContext); > - KdpManipulateStateHandler = ContinueManipulateStateHandler; > - return KdPacketReceived; > - } > - > - return ContinueManipulateStateHandler(State, MessageData, MessageLength, KdContext); > + return handle_gdb_c(State, MessageData, MessageLength, KdContext); > + } > + > + if (strncmp(gdb_input, "vCont;s", 7) == 0) > + { > + > + return handle_gdb_s(State, MessageData, MessageLength, KdContext); > } > } > > @@ -524,11 +916,14 @@ > { > case '?': > /* Send the Status */ > - gdb_send_exception(TRUE); > + gdb_send_exception(); > break; > case '!': > send_gdb_packet("OK"); > break; > + case 'c': > + Status = handle_gdb_c(State, MessageData, MessageLength, KdContext); > + break; > case 'g': > gdb_send_registers(); > break; > @@ -544,17 +939,28 @@ > case 'q': > handle_gdb_query(); > break; > + case 's': > + Status = handle_gdb_s(State, MessageData, MessageLength, KdContext); > + break; > case 'T': > handle_gdb_thread_alive(); > break; > case 'v': > Status = handle_gdb_v(State, MessageData, MessageLength, KdContext); > break; > + case 'X': > + Status = handle_gdb_write_mem(State, MessageData, MessageLength, KdContext); > + break; > + case 'z': > + Status = handle_gdb_remove_breakpoint(State, MessageData, MessageLength, KdContext); > + break; > + case 'Z': > + Status = handle_gdb_insert_breakpoint(State, MessageData, MessageLength, KdContext); > + break; > default: > - /* We don't know how to handle this request. Maybe this is something for KD */ > - State->ReturnStatus = STATUS_NOT_SUPPORTED; > + /* We don't know how to handle this request. */ > KDDBGPRINT("Unsupported GDB command: %s.\n", gdb_input); > - return KdPacketReceived; > + send_gdb_packet(""); > } > } while (Status == (KDSTATUS)-1); > > > Modified: trunk/reactos/drivers/base/kdgdb/gdb_receive.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/kdgdb/gdb_rec… > ============================================================================== > --- trunk/reactos/drivers/base/kdgdb/gdb_receive.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/base/kdgdb/gdb_receive.c [iso-8859-1] Mon Aug 22 22:24:30 2016 > @@ -30,7 +30,7 @@ > NTAPI > gdb_receive_packet(_Inout_ PKD_CONTEXT KdContext) > { > - char* ByteBuffer = gdb_input; > + UCHAR* ByteBuffer = (UCHAR*)gdb_input; > UCHAR Byte; > KDSTATUS Status; > CHAR CheckSum = 0, ReceivedCheckSum; > @@ -60,9 +60,18 @@ > *ByteBuffer = '\0'; > break; > } > - > + CheckSum += (CHAR)Byte; > + > + /* See if we should escape */ > + if (Byte == 0x7d) > + { > + Status = KdpReceiveByte(&Byte); > + if (Status != KdPacketReceived) > + return Status; > + CheckSum += (CHAR)Byte; > + Byte ^= 0x20; > + } > *ByteBuffer++ = Byte; > - CheckSum += (CHAR)Byte; > } > > /* Get Check sum (two bytes) */ > @@ -80,6 +89,7 @@ > if (ReceivedCheckSum != CheckSum) > { > /* Do not acknowledge to GDB */ > + KDDBGPRINT("Check sums don't match!"); > KdpSendByte('-'); > return KdPacketNeedsResend; > } > > Modified: trunk/reactos/drivers/base/kdgdb/gdb_send.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/kdgdb/gdb_sen… > ============================================================================== > --- trunk/reactos/drivers/base/kdgdb/gdb_send.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/base/kdgdb/gdb_send.c [iso-8859-1] Mon Aug 22 22:24:30 2016 > @@ -168,7 +168,7 @@ > } > > void > -gdb_send_exception(BOOLEAN WithThread) > +gdb_send_exception() > { > char gdb_out[1024]; > char* ptr = gdb_out; > @@ -184,20 +184,16 @@ > } > else > ptr += sprintf(ptr, "05"); > - if (WithThread) > - { > + > #if MONOPROCESS > - ptr += sprintf(ptr, "thread:%" PRIxPTR ";", > - handle_to_gdb_tid(PsGetThreadId(Thread))); > + ptr += sprintf(ptr, "thread:%" PRIxPTR ";", > + handle_to_gdb_tid(PsGetThreadId(Thread))); > #else > - ptr += sprintf(ptr, "thread:p%" PRIxPTR ".%" PRIxPTR ";", > - handle_to_gdb_pid(PsGetThreadProcessId(Thread)), > - handle_to_gdb_tid(PsGetThreadId(Thread))); > + ptr += sprintf(ptr, "thread:p%" PRIxPTR ".%" PRIxPTR ";", > + handle_to_gdb_pid(PsGetThreadProcessId(Thread)), > + handle_to_gdb_tid(PsGetThreadId(Thread))); > #endif > - } > ptr += sprintf(ptr, "core:%x;", CurrentStateChange.Processor); > - /* Add program counter */ > - gdb_append_pc_to_exception(Thread, ptr); > send_gdb_packet(gdb_out); > } > > > Modified: trunk/reactos/drivers/base/kdgdb/i386_sup.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/kdgdb/i386_su… > ============================================================================== > --- trunk/reactos/drivers/base/kdgdb/i386_sup.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/base/kdgdb/i386_sup.c [iso-8859-1] Mon Aug 22 22:24:30 2016 > @@ -251,28 +251,4 @@ > } > } > > -char* > -gdb_append_pc_to_exception( > - _In_ PETHREAD Thread, > - _Inout_ char* ptr) > -{ > - /* Get EIP */ > - unsigned short ptrSize; > - unsigned char* EipPtr = thread_to_reg(Thread, EIP, &ptrSize); > - > - /* Print it */ > - ptr += sprintf(ptr, "08:"); > - *ptr++ = hex_chars[EipPtr[0] >> 4]; > - *ptr++ = hex_chars[EipPtr[0] & 0xF]; > - *ptr++ = hex_chars[EipPtr[1] >> 4]; > - *ptr++ = hex_chars[EipPtr[1] & 0xF]; > - *ptr++ = hex_chars[EipPtr[2] >> 4]; > - *ptr++ = hex_chars[EipPtr[2] & 0xF]; > - *ptr++ = hex_chars[EipPtr[3] >> 4]; > - *ptr++ = hex_chars[EipPtr[3] & 0xF]; > - *ptr++ = ';'; > - *ptr++ = '\0'; > - > - return ptr; > -} > - > + > > Modified: trunk/reactos/drivers/base/kdgdb/kdcom.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/kdgdb/kdcom.c… > ============================================================================== > --- trunk/reactos/drivers/base/kdgdb/kdcom.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/base/kdgdb/kdcom.c [iso-8859-1] Mon Aug 22 22:24:30 2016 > @@ -303,7 +303,6 @@ > return KdPacketReceived; > } > > - KDDBGPRINT("CpGetByte returned %u.\n", CpStatus); > return KdPacketTimedOut; > } > > > Modified: trunk/reactos/drivers/base/kdgdb/kdgdb.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/kdgdb/kdgdb.h… > ============================================================================== > --- trunk/reactos/drivers/base/kdgdb/kdgdb.h [iso-8859-1] (original) > +++ trunk/reactos/drivers/base/kdgdb/kdgdb.h [iso-8859-1] Mon Aug 22 22:24:30 2016 > @@ -19,7 +19,7 @@ > > #include <pstypes.h> > > -#define KDDEBUG /* uncomment to enable debugging this dll */ > +//#define KDDEBUG /* uncomment to enable debugging this dll */ > > /* To undefine once https://sourceware.org/bugzilla/show_bug.cgi?id=17397 is resolved */ > #define MONOPROCESS 1 > @@ -83,7 +83,7 @@ > void send_gdb_packet(_In_ CHAR* Buffer); > void send_gdb_memory(_In_ VOID* Buffer, size_t Length); > void gdb_send_debug_io(_In_ PSTRING String, _In_ BOOLEAN WithPrefix); > -void gdb_send_exception(BOOLEAN WithThread); > +void gdb_send_exception(void); > void send_gdb_ntstatus(_In_ NTSTATUS Status); > extern const char hex_chars[]; > > @@ -113,15 +113,18 @@ > /* arch_sup.c */ > extern void gdb_send_register(void); > extern void gdb_send_registers(void); > -extern char* gdb_append_pc_to_exception(_In_ PETHREAD Thread, _Inout_ char* ptr); > > /* Architecture specific defines. See ntoskrnl/include/internal/arch/ke.h */ > #ifdef _M_IX86 > +/* Handling passing over the breakpoint instruction */ > # define KdpGetContextPc(Context) \ > ((Context)->Eip) > # define KdpSetContextPc(Context, ProgramCounter) \ > ((Context)->Eip = (ProgramCounter)) > # define KD_BREAKPOINT_SIZE sizeof(UCHAR) > +/* Single step mode */ > +# define KdpSetSingleStep(Context) \ > + ((Context)->EFlags |= EFLAGS_TF) > #else > # error "Please define relevant macros for your architecture" > #endif > > Modified: trunk/reactos/drivers/base/kdgdb/kdpacket.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/kdgdb/kdpacke… > ============================================================================== > --- trunk/reactos/drivers/base/kdgdb/kdpacket.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/base/kdgdb/kdpacket.c [iso-8859-1] Mon Aug 22 22:24:30 2016 > @@ -160,7 +160,7 @@ > #else > gdb_dbg_pid = handle_to_gdb_pid(PsGetThreadProcessId(Thread)); > #endif > - gdb_send_exception(FALSE); > + gdb_send_exception(); > /* Next receive call will ask for the context */ > KdpManipulateStateHandler = GetContextManipulateHandler; > break; > @@ -394,6 +394,13 @@ > IN PSTRING MessageData, > IN OUT PKD_CONTEXT KdContext) > { > + /* Override if we have some debug print from KD. */ > + if (PacketType == PACKET_TYPE_KD_DEBUG_IO) > + { > + send_kd_debug_io((DBGKD_DEBUG_IO*)MessageHeader->Buffer, MessageData); > + return; > + } > + > /* Maybe we are in a send <-> receive loop that GDB doesn't need to know about */ > if (KdpSendPacketHandler) > { > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

8 years, 8 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [vmikayelyan] 72388: usb: HUB: Add PnP state tracking Added PDO/FDO PnP state tracking, which is done according MSDN's "State Transitions for PnP Devices" topic.

by Hervé Poussineau

Hi, Le 19/08/2016 à 18:46, vmikayelyan(a)svn.reactos.org a écrit : > Author: vmikayelyan > Date: Fri Aug 19 16:46:18 2016 > New Revision: 72388 > > URL: http://svn.reactos.org/svn/reactos?rev=72388&view=rev > Log: > usb: HUB: Add PnP state tracking > > Added PDO/FDO PnP state tracking, which is done according MSDN's > "State Transitions for PnP Devices" topic. > [...] > +#define INITIALIZE_PNP_STATE(Data) \ > +(Data).PnPState = NotStarted;\ > +(Data).PreviousPnPState = NotStarted; > + > +#define SET_NEW_PNP_STATE(Data, state) \ > +(Data).PnPState = (Data).PnPState;\ You probably meant PreviousPnPState here... > +(Data).PnPState = (state); > + > +#define RESTORE_PREVIOUS_PNP_STATE(Data) \ > +(Data).PnPState = (Data).PreviousPnPState; > + Hervé

8 years, 8 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 72178: [FLTLIB] - Stub out fltlib.dll. - Add basic implementations for FilterLoad and FilterUnload - Remove the wine code, this lib talks directly to fltmgr.sys and is therefore a react...

by Thomas Faber

On 2016-08-10 00:10, gedmurphy(a)svn.reactos.org wrote: > + /* Calc and allocate a buffer to hold our filter name */ > + BufferLength = wcslen(lpFilterName) * sizeof(WCHAR); > + FilterName = RtlAllocateHeap(GetProcessHeap(), > + 0, > + BufferLength + sizeof(UNICODE_STRING)); > + if (FilterName == NULL) > + { > + CloseHandle(hFltMgr); > + return HRESULT_FROM_WIN32(ERROR_OUTOFMEMORY); > + } > + > + /* Build up the filter name into a real life string */ > + FilterName->Buffer = (PWCH)(FilterName + 1); > + FilterName->Length = BufferLength; > + FilterName->MaximumLength = BufferLength; > + RtlCopyMemory(FilterName->Buffer, lpFilterName, BufferLength); > + > + /* Tell the filter manager to load the filter for us */ > + dwError = SendIoctl(hFltMgr, > + Load ? IOCTL_LOAD_FILTER : IOCTL_UNLOAD_FILTER, > + FilterName, > + BufferLength + sizeof(UNICODE_STRING)); > + > + /* Cleaup and bail*/ > + CloseHandle(hFltMgr); > + return HRESULT_FROM_WIN32(dwError); > } You're leaking this allocation. > +// Hack - our SDK reports NTDDI_VERSION as 0x05020100 (from _WIN32_WINNT 0x502) > +// which doesn't pass the FLT_MGR_BASELINE check in fltkernel.h > +#define NTDDI_VERSION NTDDI_WS03SP1 We typically set this kind of thing in CMakeLists.txt.. however maybe we should define it this way by default

8 years, 8 months

2
1
0 0

Status Meeting (June 2016)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place this Thursday, 28th of June, 19:00 UTC. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. The backup place to conduct meetings is #reactos-meeting channel on Freenode. Please send agenda proposals to me before the meeting so we don't waste time trying to setup the agenda directly during the meeting. Regards, Aleksey Bragin

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tthompson] 71945: [NTFS] *AddRun() - Don't leak RunBuffer when encountering errors. Handle exception from FsRtlAddLargeMcbEntry().

by Pierre Schweitzer

Comment inline Le 15/07/2016 à 17:27, tthompson(a)svn.reactos.org a écrit : > Author: tthompson > Date: Fri Jul 15 15:27:04 2016 > New Revision: 71945 > > URL: http://svn.reactos.org/svn/reactos?rev=71945&view=rev > Log: > [NTFS] > *AddRun() - Don't leak RunBuffer when encountering errors. > Handle exception from FsRtlAddLargeMcbEntry(). > > Modified: > branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c > > Modified: branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c > URL: http://svn.reactos.org/svn/reactos/branches/GSoC_2016/NTFS/drivers/filesyst… > ============================================================================== > --- branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c [iso-8859-1] (original) > +++ branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c [iso-8859-1] Fri Jul 15 15:27:04 2016 > @@ -88,25 +88,40 @@ > ULONGLONG NextVBN = AttrContext->Record.NonResident.LowestVCN; > > // Allocate some memory for the RunBuffer > - PUCHAR RunBuffer = ExAllocatePoolWithTag(NonPagedPool, Vcb->NtfsInfo.BytesPerFileRecord, TAG_NTFS); > + PUCHAR RunBuffer; > int RunBufferOffset = 0; > > if (!AttrContext->Record.IsNonResident) > return STATUS_INVALID_PARAMETER; > + > + RunBuffer = ExAllocatePoolWithTag(NonPagedPool, Vcb->NtfsInfo.BytesPerFileRecord, TAG_NTFS); > > // Convert the data runs to a map control block > Status = ConvertDataRunsToLargeMCB(DataRun, &DataRunsMCB, &NextVBN); > if (!NT_SUCCESS(Status)) > { > DPRINT1("Unable to convert data runs to MCB (probably ran out of memory)!\n"); > + ExFreePoolWithTag(RunBuffer, TAG_NTFS); > return Status; > } > > // Add newly-assigned clusters to mcb > - FsRtlAddLargeMcbEntry(&DataRunsMCB, > - NextVBN, > - NextAssignedCluster, > - RunLength); > + _SEH2_TRY{ > + if (!FsRtlAddLargeMcbEntry(&DataRunsMCB, > + NextVBN, > + NextAssignedCluster, > + RunLength)) > + { > + FsRtlUninitializeLargeMcb(&DataRunsMCB); > + ExFreePoolWithTag(RunBuffer, TAG_NTFS); > + return STATUS_INSUFFICIENT_RESOURCES; > + } > + } _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) { > + FsRtlUninitializeLargeMcb(&DataRunsMCB); > + ExFreePoolWithTag(RunBuffer, TAG_NTFS); > + _SEH2_YIELD(return STATUS_INSUFFICIENT_RESOURCES); > + } _SEH2_END; Purely cosmetic one here. You should, in your try block, call ExRaiseStatus with the appropriate status and do the cleanup in the exception handler. That avoids code duplication. This also implies you don't want to force the status code, but rather use _SEH2_GetExceptionCode(). Also note that FsRtlAddLargeMcbEntry may fail for various reasons. I don't really know which status code to use as you have no way to know why it failed. -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tthompson] 71957: [NTFS] Address some minor issues with attrib.c: Fix gcc build. Fix formatting.

by Pierre Schweitzer

Comment inline. Le 17/07/2016 à 16:04, tthompson(a)svn.reactos.org a écrit : > Author: tthompson > Date: Sun Jul 17 14:04:01 2016 > New Revision: 71957 > > URL: http://svn.reactos.org/svn/reactos?rev=71957&view=rev > Log: > [NTFS] > Address some minor issues with attrib.c: Fix gcc build. Fix formatting. > > Modified: > branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c > > Modified: branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c > URL: http://svn.reactos.org/svn/reactos/branches/GSoC_2016/NTFS/drivers/filesyst… > ============================================================================== > --- branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c [iso-8859-1] (original) > +++ branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c [iso-8859-1] Sun Jul 17 14:04:01 2016 > @@ -295,14 +291,14 @@ > ULONG RunBufferOffset = 0; > LONGLONG DataRunOffset; > ULONGLONG LastLCN = 0; > - > LONGLONG Vbn, Lbn, Count; > + int i; Use MS portable type, please (ULONG looks good :-)) -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tthompson] 71968: [NTFS] +FreeClusters(). Fix a DPRINT.

by Pierre Schweitzer

Comment inline. Le 19/07/2016 à 17:31, tthompson(a)svn.reactos.org a écrit : > Author: tthompson > Date: Tue Jul 19 15:31:22 2016 > New Revision: 71968 > > URL: http://svn.reactos.org/svn/reactos?rev=71968&view=rev > Log: > [NTFS] > +FreeClusters(). Fix a DPRINT. > > Modified: > branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c > branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c > branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/ntfs.h > > Modified: branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c > URL: http://svn.reactos.org/svn/reactos/branches/GSoC_2016/NTFS/drivers/filesyst… > ============================================================================== > --- branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c [iso-8859-1] (original) > +++ branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c [iso-8859-1] Tue Jul 19 15:31:22 2016 > @@ -409,6 +409,208 @@ > return TRUE; > } > > +/** > +* @name FreeClusters > +* @implemented > +* > +* Shrinks the allocation size of a non-resident attribute by a given number of clusters. > +* Frees the clusters from the volume's $BITMAP file as well as the attribute's data runs. > +* > +* @param Vcb > +* Pointer to an NTFS_VCB for the destination volume. > +* > +* @param AttrContext > +* Pointer to an NTFS_ATTR_CONTEXT describing the attribute from which the clusters will be freed. > +* > +* @param AttrOffset > +* Byte offset of the destination attribute relative to its file record. > +* > +* @param FileRecord > +* Pointer to a complete copy of the file record containing the attribute. Must be at least > +* Vcb->NtfsInfo.BytesPerFileRecord bytes long. > +* > +* @param ClustersToFree > +* Number of clusters that should be freed from the end of the data stream. Must be no more > +* Than the number of clusters assigned to the attribute (HighestVCN + 1). > +* > +* @return > +* STATUS_SUCCESS on success. STATUS_INVALID_PARAMETER if AttrContext describes a resident attribute, > +* or if the caller requested more clusters be freed than the attribute has been allocated. > +* STATUS_INSUFFICIENT_RESOURCES if ConvertDataRunsToLargeMCB() fails. > +* STATUS_BUFFER_TOO_SMALL if ConvertLargeMCBToDataRuns() fails. > +* > +* > +*/ > +NTSTATUS > +FreeClusters(PNTFS_VCB Vcb, > + PNTFS_ATTR_CONTEXT AttrContext, > + ULONG AttrOffset, > + PFILE_RECORD_HEADER FileRecord, > + ULONG ClustersToFree) > +{ > + NTSTATUS Status = STATUS_SUCCESS; > + ULONG ClustersLeftToFree = ClustersToFree; > + > + // convert data runs to mcb > + PUCHAR DataRun = (PUCHAR)&AttrContext->Record + AttrContext->Record.NonResident.MappingPairsOffset; > + PNTFS_ATTR_RECORD DestinationAttribute = (PNTFS_ATTR_RECORD)((ULONG_PTR)FileRecord + AttrOffset); > + LARGE_MCB DataRunsMCB; > + ULONG NextAttributeOffset = AttrOffset + AttrContext->Record.Length; > + PNTFS_ATTR_RECORD NextAttribute = (PNTFS_ATTR_RECORD)((ULONG_PTR)FileRecord + NextAttributeOffset); > + ULONGLONG NextVBN = AttrContext->Record.NonResident.LowestVCN; > + > + // Allocate some memory for the RunBuffer > + PUCHAR RunBuffer = ExAllocatePoolWithTag(NonPagedPool, Vcb->NtfsInfo.BytesPerFileRecord, TAG_NTFS); > + ULONG RunBufferOffset = 0; Two notes regarding this allocation: - You should check allocation worked (obviously ;-)); - You should start memory work only after checking the record is not resident. -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [zhu] 71865: Structural, style, correctness fixes.

by Thomas Faber

On 2016-07-08 19:52, zhu(a)svn.reactos.org wrote: > --- branches/GSoC_2016/lwIP-tcpip/drivers/network/tcpip/address.c [iso-8859-1] (original) > +++ branches/GSoC_2016/lwIP-tcpip/drivers/network/tcpip/address.c [iso-8859-1] Fri Jul 8 17:52:42 2016 > @@ -33,6 +33,8 @@ > static LIST_ENTRY AddressListHead; > > /* implementation in testing */ > +/* Must already hold the Context->RequestListLock */ > +/* Context should be in ->FileObject->FsContext */ You know there is a way to actually tell that to MSVC's static analyzer, right? ;) You want something like _IRQL_requires_(DISPATCH_LEVEL) _IRQL_requires_same_ _Requires_lock_held_(((PTCP_CONTEXT)IrpSp->FileObject->FsContext)->RequestListLock) The last one might be a little too complicated to actually include, but the IRQL ones are easy to help indicate things like this. > NTSTATUS > PrepareIrpForCancel( > PIRP Irp,

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 71862: [NTOS] - Implement IoCreateFileSpecifyDeviceObjectHint - will be needed for fltmgr - Rename IoCreateFile to IopCreateFile and forward both IoCreateFile and IoCreateFileSpecifyDev...

by Alex Ionescu

On Fri, Jul 8, 2016 at 6:18 AM, <gedmurphy(a)svn.reactos.org> wrote: > > + if (OpenPacket->InternalFlags & IOP_USE_TOP_LEVEL_DEVICE_HINT) > + { > + // FIXME: Verify our device object is good to use > + ASSERT(DirectOpen == FALSE); > } You probably want to take a look at IopCheckTopDeviceHint Best regards, Alex Ionescu

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 71819: [RTL]: Follow what I guess might be Alex' coding standards.

by Alex Ionescu

I agree with one-line ifs FWIW... As for the previous code, I think if the file is using separate braces, you shouldn't go around and write new code that follows the no-braces style -- which yes, we do accept. Best regards, Alex Ionescu On Thu, Jul 7, 2016 at 5:25 PM, Timo Kreuzer <timo.kreuzer(a)web.de> wrote: > > According to the "official" ReactOS coding standards, the previous code > was perfectly fine. > Code like "If (Value == 0) Value = FOO;" (in one line) does not match our > coding style rules. (And it's also annoying, when stepping through it with > WinDbg.) > 3 line comments also don't match our coding style :-P > > For reference: https://reactos.org/wiki/Coding_Style > > Timo > > > > Am 05.07.2016 um 16:30 schrieb Alex Ionescu: > > Coding Style - ReactOS Wiki > <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEw…> > > Stop calling them "mine". > > Best regards, > Alex Ionescu > > On Mon, Jul 4, 2016 at 5:38 PM, <hbelusca(a)svn.reactos.org> wrote: > >> Author: hbelusca >> Date: Tue Jul 5 00:38:28 2016 >> New Revision: 71819 >> >> URL: http://svn.reactos.org/svn/reactos?rev=71819&view=rev >> Log: >> [RTL]: Follow what I guess might be Alex' coding standards. >> >> Modified: >> trunk/reactos/sdk/lib/rtl/process.c >> >> Modified: trunk/reactos/sdk/lib/rtl/process.c >> URL: >> http://svn.reactos.org/svn/reactos/trunk/reactos/sdk/lib/rtl/process.c?rev=… >> >> ============================================================================== >> --- trunk/reactos/sdk/lib/rtl/process.c [iso-8859-1] (original) >> +++ trunk/reactos/sdk/lib/rtl/process.c [iso-8859-1] Tue Jul 5 00:38:28 >> 2016 >> @@ -75,7 +75,7 @@ >> PVOID BaseAddress = NULL; >> SIZE_T EnviroSize; >> SIZE_T Size; >> - PWCHAR Environment = 0; >> + PWCHAR Environment = NULL; >> DPRINT("RtlpInitEnvironment(ProcessHandle: %p, Peb: %p Params: >> %p)\n", >> ProcessHandle, Peb, ProcessParameters); >> >> @@ -301,7 +301,9 @@ >> DUPLICATE_SAME_ACCESS | >> DUPLICATE_SAME_ATTRIBUTES); >> if (!NT_SUCCESS(Status)) >> + { >> _SEH2_LEAVE; >> + } >> } >> >> if (ProcessParameters->StandardOutput) >> @@ -315,7 +317,9 @@ >> DUPLICATE_SAME_ACCESS | >> DUPLICATE_SAME_ATTRIBUTES); >> if (!NT_SUCCESS(Status)) >> + { >> _SEH2_LEAVE; >> + } >> } >> >> if (ProcessParameters->StandardError) >> @@ -329,7 +333,9 @@ >> DUPLICATE_SAME_ACCESS | >> DUPLICATE_SAME_ATTRIBUTES); >> if (!NT_SUCCESS(Status)) >> + { >> _SEH2_LEAVE; >> + } >> } >> } >> _SEH2_FINALLY >> >> >> > > > _______________________________________________ > Ros-dev mailing listRos-dev@reactos.orghttp://www.reactos.org/mailman/listinfo/ros-dev > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > >

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 71864: [FLTMGR]: Remove a MSVC warning: FltObjectDereference, whose prototype is publicly defined in fltkernel.h, doesn't return any value.

by Ged Murphy

This change in incorrect, FltObectDereference does return a value. It's the public definition that's does match the function. -----Original Message----- From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of hbelusca(a)svn.reactos.org Sent: 08 July 2016 18:45 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [hbelusca] 71864: [FLTMGR]: Remove a MSVC warning: FltObjectDereference, whose prototype is publicly defined in fltkernel.h, doesn't return any value. Author: hbelusca Date: Fri Jul 8 17:44:59 2016 New Revision: 71864 URL: http://svn.reactos.org/svn/reactos?rev=71864&view=rev Log: [FLTMGR]: Remove a MSVC warning: FltObjectDereference, whose prototype is publicly defined in fltkernel.h, doesn't return any value.

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 71819: [RTL]: Follow what I guess might be Alex' coding standards.

by Alex Ionescu

Coding Style - ReactOS Wiki <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEw…> Stop calling them "mine". Best regards, Alex Ionescu On Mon, Jul 4, 2016 at 5:38 PM, <hbelusca(a)svn.reactos.org> wrote: > Author: hbelusca > Date: Tue Jul 5 00:38:28 2016 > New Revision: 71819 > > URL: http://svn.reactos.org/svn/reactos?rev=71819&view=rev > Log: > [RTL]: Follow what I guess might be Alex' coding standards. > > Modified: > trunk/reactos/sdk/lib/rtl/process.c > > Modified: trunk/reactos/sdk/lib/rtl/process.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/sdk/lib/rtl/process.c?rev=… > > ============================================================================== > --- trunk/reactos/sdk/lib/rtl/process.c [iso-8859-1] (original) > +++ trunk/reactos/sdk/lib/rtl/process.c [iso-8859-1] Tue Jul 5 00:38:28 > 2016 > @@ -75,7 +75,7 @@ > PVOID BaseAddress = NULL; > SIZE_T EnviroSize; > SIZE_T Size; > - PWCHAR Environment = 0; > + PWCHAR Environment = NULL; > DPRINT("RtlpInitEnvironment(ProcessHandle: %p, Peb: %p Params: %p)\n", > ProcessHandle, Peb, ProcessParameters); > > @@ -301,7 +301,9 @@ > DUPLICATE_SAME_ACCESS | > DUPLICATE_SAME_ATTRIBUTES); > if (!NT_SUCCESS(Status)) > + { > _SEH2_LEAVE; > + } > } > > if (ProcessParameters->StandardOutput) > @@ -315,7 +317,9 @@ > DUPLICATE_SAME_ACCESS | > DUPLICATE_SAME_ATTRIBUTES); > if (!NT_SUCCESS(Status)) > + { > _SEH2_LEAVE; > + } > } > > if (ProcessParameters->StandardError) > @@ -329,7 +333,9 @@ > DUPLICATE_SAME_ACCESS | > DUPLICATE_SAME_ATTRIBUTES); > if (!NT_SUCCESS(Status)) > + { > _SEH2_LEAVE; > + } > } > } > _SEH2_FINALLY > > >

8 years, 9 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [tthompson] 71807: [NTFS][FREELDR] Fix ReadAttribute() and NtfsReadAttribute() in the case when an attribute contains two data runs; Remove extra if statement that prevents second data run from bei...

by Pierre Schweitzer

Actually, this (duplicated) function looks quite poorly designed (not your fault, obviously :-p). The more you fix it, the more it seems natural that the first specific case should be integrated in the while loop for real. That would make the function more robust, with less duplicated code (and thus, less bugs :-p). GSoC note: this is not a "todo" task. This is just an open discussion about a possible improvement if some day someone's bored. Le 04/07/2016 19:02, tthompson(a)svn.reactos.org a écrit : > Author: tthompson > Date: Mon Jul 4 17:02:10 2016 > New Revision: 71807 > > URL: http://svn.reactos.org/svn/reactos?rev=71807&view=rev > Log: > [NTFS][FREELDR] > Fix ReadAttribute() and NtfsReadAttribute() in the case when an attribute contains two data runs; Remove extra if statement that prevents second data run from being read after it's decoded. > > Modified: > branches/GSoC_2016/NTFS/boot/freeldr/freeldr/lib/fs/ntfs.c > branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c > > Modified: branches/GSoC_2016/NTFS/boot/freeldr/freeldr/lib/fs/ntfs.c > URL: http://svn.reactos.org/svn/reactos/branches/GSoC_2016/NTFS/boot/freeldr/fre… > ============================================================================== > --- branches/GSoC_2016/NTFS/boot/freeldr/freeldr/lib/fs/ntfs.c [iso-8859-1] (original) > +++ branches/GSoC_2016/NTFS/boot/freeldr/freeldr/lib/fs/ntfs.c [iso-8859-1] Mon Jul 4 17:02:10 2016 > @@ -320,9 +320,6 @@ > } > else > DataRunStartLCN = -1; > - > - if (*DataRun == 0) > - return AlreadyRead; > } > > while (Length > 0) > > Modified: branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c > URL: http://svn.reactos.org/svn/reactos/branches/GSoC_2016/NTFS/drivers/filesyst… > ============================================================================== > --- branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c [iso-8859-1] (original) > +++ branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c [iso-8859-1] Mon Jul 4 17:02:10 2016 > @@ -384,9 +384,6 @@ > } > else > DataRunStartLCN = -1; > - > - if (*DataRun == 0) > - return AlreadyRead; > } > > while (Length > 0) > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tthompson] 71820: [NTFS] Add ability to write to resident attributes. SetAttributeDataLength() - Check if the file is memory mapped before truncating +InternalSetResidentAttributeLength() - Used b...

by Pierre Schweitzer

Hi, Comments inline. Le 05/07/2016 09:00, tthompson(a)svn.reactos.org a écrit : > Modified: branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c > URL: http://svn.reactos.org/svn/reactos/branches/GSoC_2016/NTFS/drivers/filesyst… > ============================================================================== > --- branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c [iso-8859-1] (original) > +++ branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c [iso-8859-1] Tue Jul 5 07:00:43 2016 > @@ -170,6 +172,50 @@ > return AttrRecord->Resident.ValueLength; > } > > +void > +InternalSetResidentAttributeLength(PNTFS_ATTR_CONTEXT AttrContext, > + PFILE_RECORD_HEADER FileRecord, > + ULONG AttrOffset, > + ULONG DataSize) > +{ > + ULONG EndMarker = AttributeEnd; > + ULONG FinalMarker = FILE_RECORD_END; > + ULONG NextAttributeOffset; > + ULONG Offset; > + USHORT Padding; > + > + DPRINT("InternalSetResidentAttributeLength( %p, %p, %lu, %lu )\n", AttrContext, FileRecord, AttrOffset, DataSize); > + > + // update ValueLength Field > + AttrContext->Record.Resident.ValueLength = DataSize; > + Offset = AttrOffset + FIELD_OFFSET(NTFS_ATTR_RECORD, Resident.ValueLength); > + RtlCopyMemory((PCHAR)FileRecord + Offset, &DataSize, sizeof(ULONG)); That part looks a bit over-engineered to me and might be simplified (like not using an intermediate var, nor RtlCopyMemory). Cosmetic, I'd replace PCHAR by ULONG_PTR. Same comment goes to code below doing basically the same thing. > + > + // calculate the record length and end marker offset > + AttrContext->Record.Length = DataSize + AttrContext->Record.Resident.ValueOffset; > + NextAttributeOffset = AttrOffset + AttrContext->Record.Length; > + > + // Ensure NextAttributeOffset is aligned to an 8-byte boundary > + if (NextAttributeOffset % 8 != 0) > + { > + Padding = 8 - (NextAttributeOffset % 8); > + NextAttributeOffset += Padding; > + AttrContext->Record.Length += Padding; > + } > + > + // update the record length > + Offset = AttrOffset + FIELD_OFFSET(NTFS_ATTR_RECORD, Length); > + RtlCopyMemory((PCHAR)FileRecord + Offset, &AttrContext->Record.Length, sizeof(ULONG)); > + > + // write the end marker > + RtlCopyMemory((PCHAR)FileRecord + NextAttributeOffset, &EndMarker, sizeof(ULONG)); > + > + // write the final marker > + Offset = NextAttributeOffset + sizeof(ULONG); > + RtlCopyMemory((PCHAR)FileRecord + Offset, &FinalMarker, sizeof(ULONG)); > + > + FileRecord->BytesInUse = Offset + sizeof(ULONG); > +} > > NTSTATUS > SetAttributeDataLength(PFILE_OBJECT FileObject, > @@ -179,6 +225,18 @@ > PFILE_RECORD_HEADER FileRecord, > PLARGE_INTEGER DataSize) > { > + NTSTATUS Status = STATUS_SUCCESS; > + > + // are we truncating the file? > + if (DataSize->QuadPart < AttributeDataLength(&AttrContext->Record) Unless I'm blind, I'm not sure it builds. > + { > + if (!MmCanFileBeTruncated(FileObject->SectionObjectPointer, (PLARGE_INTEGER)&AllocationSize)) > + { > + DPRINT1("Can't truncate a memory-mapped file!\n"); > + return STATUS_USER_MAPPED_FILE; > + } > + } > + > if (AttrContext->Record.IsNonResident) > { > ULONG BytesPerCluster = Fcb->Vcb->NtfsInfo.BytesPerCluster; > Modified: branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/volinfo.c > URL: http://svn.reactos.org/svn/reactos/branches/GSoC_2016/NTFS/drivers/filesyst… > ============================================================================== > --- branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/volinfo.c [iso-8859-1] (original) > +++ branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/volinfo.c [iso-8859-1] Tue Jul 5 07:00:43 2016 > @@ -158,7 +157,7 @@ > DPRINT1("Total clusters in bitmap: %I64x\n", BitmapDataSize * 8); > DPRINT1("Diff in size: %I64d B\n", ((BitmapDataSize * 8) - DeviceExt->NtfsInfo.ClusterCount) * DeviceExt->NtfsInfo.SectorsPerCluster * DeviceExt->NtfsInfo.BytesPerSector); > > - ReadAttribute(DeviceExt, DataContext, Read, (PCHAR)((ULONG_PTR)BitmapData + Read), (ULONG)BitmapDataSize); > + ReadAttribute(DeviceExt, DataContext, 0, (PCHAR)BitmapData, (ULONG)BitmapDataSize); What's this change? > > RtlInitializeBitMap(&Bitmap, (PULONG)BitmapData, DeviceExt->NtfsInfo.ClusterCount); > FreeClusters = RtlNumberOfClearBits(&Bitmap); > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

8 years, 9 months

2
2
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 71829: [CLIPBRD]: Use NULL for null pointer. [EVENTVWR]: Add folder icons (needed for later).

by Thomas Faber

Can't event viewer load those icons from shell32 (much like regedit should)? On 2016-07-06 01:42, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Tue Jul 5 23:42:40 2016 > New Revision: 71829 > > URL: http://svn.reactos.org/svn/reactos?rev=71829&view=rev > Log: > [CLIPBRD]: Use NULL for null pointer. > [EVENTVWR]: Add folder icons (needed for later). > > Added: > trunk/reactos/base/applications/mscutils/eventvwr/res/folder.ico > - copied unchanged from r71828, trunk/reactos/base/applications/regedit/res/folder.ico > trunk/reactos/base/applications/mscutils/eventvwr/res/folderopen.ico > - copied unchanged from r71828, trunk/reactos/base/applications/regedit/res/folderopen.ico > Modified: > trunk/reactos/base/applications/clipbrd/clipbrd.c > > Modified: trunk/reactos/base/applications/clipbrd/clipbrd.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/clipbrd/… > ============================================================================== > --- trunk/reactos/base/applications/clipbrd/clipbrd.c [iso-8859-1] (original) > +++ trunk/reactos/base/applications/clipbrd/clipbrd.c [iso-8859-1] Tue Jul 5 23:42:40 2016 > @@ -256,12 +256,12 @@ > > case CMD_ABOUT: > { > + HICON hIcon; > WCHAR szTitle[MAX_STRING_LEN]; > - HICON hIcon; > > hIcon = LoadIconW(Globals.hInstance, MAKEINTRESOURCE(CLIPBRD_ICON)); > LoadStringW(Globals.hInstance, STRING_CLIPBOARD, szTitle, ARRAYSIZE(szTitle)); > - ShellAboutW(Globals.hMainWnd, szTitle, 0, hIcon); > + ShellAboutW(Globals.hMainWnd, szTitle, NULL, hIcon); > DeleteObject(hIcon); > break; > } > >

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [zhu] 71823: Fixed crash on client and server exit: Corrected some NULL data marking and checking. Moved some cleanup code so they actually execute on function failure (incomplete). Removed redunda...

by Thomas Faber

Comments inline. On 2016-07-05 20:35, zhu(a)svn.reactos.org wrote: > --- branches/GSoC_2016/lwIP-tcpip/drivers/network/tcpip/address.c [iso-8859-1] (original) > +++ branches/GSoC_2016/lwIP-tcpip/drivers/network/tcpip/address.c [iso-8859-1] Tue Jul 5 18:35:17 2016 > @@ -357,15 +356,15 @@ > > KeReleaseSpinLockFromDpcLevel(&Context->RequestListLock); > > - if (Context->lwip_tcp_pcb != Context->AddressFile->lwip_tcp_pcb) > + if (Context->lwip_tcp_pcb == Context->AddressFile->lwip_tcp_pcb); You really don't want a semicolon here ;) > { > - tcp_close(Context->lwip_tcp_pcb); > + Context->AddressFile->lwip_tcp_pcb = NULL; > } > + if (!p) > + { > + CopiedLength = 0; > + Status = STATUS_ADDRESS_CLOSED; > + goto BAD; > + } > > if (RemainingDestBytes <= p->len) > { > RtlCopyMemory(CurrentDestLocation, p->payload, RemainingDestBytes); > CopiedLength = RemainingDestBytes; > + Status = STATUS_SUCCESS; > goto RETURN; We normally call labels things like "Exit" and "Failure". > @@ -826,23 +846,24 @@ > > tcp_recved(tpcb, CopiedLength); > I find it confusing not to have Entry = Head->Flink right here. I'm not sure where it is, but unless there's a good reason for it to be somewhere else I'd recommend putting it right in front of the loop. > + while (Entry != Head) > + { > + Request = CONTAINING_RECORD(Entry, TCP_REQUEST, ListEntry); Entry = Entry->Flink? ;) > + if (Request->PendingMode == TCP_REQUEST_PENDING_RECEIVE) > + { > + tcp_recv(tpcb, lwip_tcp_receive_callback); > + break; > + } > + } > @@ -1666,6 +1690,21 @@ > if (!(IsListEmpty(&Context->RequestListHead))) > { > DPRINT1("Disassociating context with outstanding requests\n"); > + Head = &Context->RequestListHead; > + Entry = Head->Flink; > + while (Entry != Head) > + { > + Request = CONTAINING_RECORD(Entry, TCP_REQUEST, ListEntry); Entry = Entry->Flink; > + if (Request->PendingIrp) > + { > + IrpSp = IoGetCurrentIrpStackLocation(Request->PendingIrp); > + DPRINT1("Pending IRP Control Code: %08x\n", IrpSp->MinorFunction); > + } > + else > + { > + DPRINT1("IRP is NULL\n"); > + } > + } > } > KeReleaseSpinLockFromDpcLevel(&Context->RequestListLock); > Thanks. -Thomas

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 71811: [RTL] - Duplicate the standard (input/output/error) handles from the parent process, when creating a new one. - Properly fail RtlCreateUserProcess if any of the ZwWriteVirtualMemo...

by Alex Ionescu

On Mon, Jul 4, 2016 at 1:28 PM, <hbelusca(a)svn.reactos.org> wrote: > + if (!NT_SUCCESS(Status)) > + _SEH2_LEAVE; > + } > For the love of God can you please follow our coding standards. Also, I'm pretty familiar with this code path -- are you sure that this is the correct place to do this duplication? Best regards, Alex Ionescu

8 years, 9 months

1
0
0 0

Tr: Re: Ros-diffs Digest, Vol 150, Issue 29

by Hermès BÉLUSCA - MAÏTO

Hi Eric, are you sure this will not break compatibility with WIn2k3 applications? For example by quickly googling I've noticed some people rely on this Index value for their Time Zone stuff. Example: https://www.experts-exchange.com/questions/24948382/How-to-get-Time-Zone-in… Also, since http://microsoft.public.win32.programmer.ui.narkive.com/SOU9r3ef/time-zones… clearly says that the "IndexMapping" reg_multi_sz is for doing the mapping with the "Index" values of each time zone, you could have also deleted it! (note that this mapping value is indeed absent on Windows 7 for example). Cheers, Hermès ======================================== Message du : 03/07/2016 20:42 De : ros-diffs-request(a)reactos.org A : ros-diffs(a)reactos.org Copie à : Sujet : Ros-diffs Digest, Vol 150, Issue 29 [...] Today's Topics: [...] 3. [ekohl] 71801: [BOOTDATA] Remove the Index value from the time zone entries. We do not need it any more and it has been removed from Windows Vista. (ekohl(a)svn.reactos.org) ---------------------------------------------------------------------- Message: 3 Date: Sun, 03 Jul 2016 18:40:27 -0000 From: ekohl(a)svn.reactos.org To: ros-diffs(a)reactos.org Subject: [ros-diffs] [ekohl] 71801: [BOOTDATA] Remove the Index value from the time zone entries. We do not need it any more and it has been removed from Windows Vista. Message-ID: Content-Type: text/plain; charset="utf-8" Author: ekohl Date: Sun Jul 3 18:40:27 2016 New Revision: 71801 URL: http://svn.reactos.org/svn/reactos?rev=71801&view=rev Log: [BOOTDATA] Remove the Index value from the time zone entries. We do not need it any more and it has been removed from Windows Vista. Modified: trunk/reactos/boot/bootdata/hivesft.inf Modified: trunk/reactos/boot/bootdata/hivesft.inf URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesft.inf?… ============================================================================== --- trunk/reactos/boot/bootdata/hivesft.inf [iso-8859-1] (original) +++ trunk/reactos/boot/bootdata/hivesft.inf [iso-8859-1] Sun Jul 3 18:40:27 2016 @@ -406,7 +406,6 @@ HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Dateline Standard Time","Display",0x00000000,"(GMT-12:00) International Date Line West" HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Dateline Standard Time","Dlt",0x00000000,"Dateline Daylight Time" HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Dateline Standard Time","Std",0x00000000,"Dateline Standard Time" -HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Dateline Standard Time","Index",0x00010001,0 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Dateline Standard Time","TZI",0x00000001,\ 0xd0,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0xc4,0xff,0xff,0xff,\ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,\ (skipping........) @@ -1125,7 +1046,6 @@ HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Tonga Standard Time","Display",0x00000000,"(GMT+13:00) Nuku'alofa" HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Tonga Standard Time","Dlt",0x00000000,"Tonga Daylight Time" HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Tonga Standard Time","Std",0x00000000,"Tonga Standard Time" -HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Tonga Standard Time","Index",0x00010001,300 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Tonga Standard Time","TZI",0x00000001,\ 0xf4,0xfc,0xff,0xff,0x00,0x00,0x00,0x00,0xc4,0xff,0xff,0xff,\ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,\ ------------------------------ Subject: Digest Footer _______________________________________________ Ros-diffs mailing list Ros-diffs(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-diffs ------------------------------ End of Ros-diffs Digest, Vol 150, Issue 29 ******************************************

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 71695: [SUBST] - Update the resource program description. - Convert to full UNICODE. - Use Win32 functions where possible. - Factor-out the usage of QueryDosDevice into a QuerySubstedDri...

by Ged Murphy

This should probably be moved to \base\applications\cmdutils -----Original Message----- From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of hbelusca(a)svn.reactos.org Sent: 29 June 2016 01:39 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [hbelusca] 71695: [SUBST] - Update the resource program description. - Convert to full UNICODE. - Use Win32 functions where possible. - Factor-out the usage of QueryDosDevice into a QuerySubstedDri... Author: hbelusca Date: Wed Jun 29 00:38:51 2016 New Revision: 71695 URL: http://svn.reactos.org/svn/reactos?rev=71695&view=rev Log: [SUBST] - Update the resource program description. - Convert to full UNICODE. - Use Win32 functions where possible. - Factor-out the usage of QueryDosDevice into a QuerySubstedDrive function, that returns error codes according to whether the specified drive is a mapped (substed) drive, or is just an existing drive that is not a mapping, or if the drive does not exist. This allows us to detect attempts to use a drive letter that is not a mapped drive, to define a new mapping, and if so we reject such attempt. This fixes CORE-10681 #resolve #comment Fixed with another patch according to my last remark.

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 71695: [SUBST] - Update the resource program description. - Convert to full UNICODE. - Use Win32 functions where possible. - Factor-out the usage of QueryDosDevice into a QuerySubstedDri...

by Thomas Faber

On 2016-06-29 02:38, hbelusca(a)svn.reactos.org wrote: > + if (!CharCount && (Result == ERROR_INSUFFICIENT_BUFFER)) > + { > + /* Reallocate the buffer with double size */ > + dwSize *= 2; > + tmp = (PWSTR)HeapReAlloc(GetProcessHeap(), 0, lpTargetPath, dwSize * sizeof(WCHAR)); Oops, this fixes my previous concern, thanks. The casts are still weird though. > + if (!tmp) > + { > + /* Memory problem, bail out */ > + CharCount = 0; > + Result = ERROR_NOT_ENOUGH_MEMORY; > + } > + else > + { > + /* Retry again */ > + lpTargetPath = tmp; > + goto Retry; > + } > + } > + > + if (CharCount) > + { > + if ( wcsncmp(lpTargetPath, L"\\??\\", 4) == 0 && > + ( (lpTargetPath[4] >= L'A' && lpTargetPath[4] <= L'Z') || > + (lpTargetPath[4] >= L'a' && lpTargetPath[4] <= L'z') ) ) > + { > + /* The drive exists and is SUBSTed */ > + Result = ERROR_IS_SUBSTED; > + } > +#if 0 > + else > + { > + /* The drive exists but is not SUBSTed */ > + Result = ERROR_INVALID_DRIVE; > + } > +#endif > + } > + > + if (!TargetPath) > + { > + /* Free the local buffer */ > + HeapFree(GetProcessHeap(), 0, lpTargetPath); > + } > + else > + { > + /* Update the user-given pointers */ > + *TargetPath = lpTargetPath; > + *Size = dwSize; If the HeapReAlloc above fails you might still get into this code path which is not advisable. It should probably always take the if-branch in that case. > + } > + > + return Result; Thanks. -Thomas

8 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 71692: [SUBST]: CORE-10681 #comment Apply part of Peter Hater's patch proposed in CORE-10681, that is, fixing the usage of QueryDosDevice API, but without the new IsDriveUsed functionali...

by Thomas Faber

On 2016-06-28 21:21, hbelusca(a)svn.reactos.org wrote: > --- trunk/reactos/base/system/subst/subst.c [iso-8859-1] (original) > +++ trunk/reactos/base/system/subst/subst.c [iso-8859-1] Tue Jun 28 19:21:08 2016 > @@ -75,81 +75,71 @@ > if (_tcslen(Drive) > 2) > return FALSE; > > - dwSize = sizeof(TCHAR) * MAX_PATH; > - lpTargetPath = (LPTSTR) malloc(sizeof(TCHAR) * MAX_PATH); > - if ( lpTargetPath) > - { > + dwSize = MAX_PATH; > + lpTargetPath = (LPTSTR)malloc(sizeof(TCHAR) * dwSize); > + if (!lpTargetPath) > + return FALSE; > + > + CharCount = QueryDosDevice(Drive, > + lpTargetPath, > + dwSize); > + while (!CharCount && > + GetLastError() == ERROR_INSUFFICIENT_BUFFER) > + { > + lpTargetPath = (LPTSTR)realloc(lpTargetPath, sizeof(TCHAR) * dwSize); This is not how you use realloc, this causes a memory leak in case of failure. Also, why is there a cast here (also, for malloc above)? Thanks. -Thomas > + if (lpTargetPath) > + { > + CharCount = QueryDosDevice(Drive, > + lpTargetPath, > + dwSize); > + } > + } > + > + if (CharCount) > + { > + Result = _tcsncmp(lpTargetPath, _T("\\??\\"), 4) == 0 && > + ( (lpTargetPath[4] >= _T('A') && > + lpTargetPath[4] <= _T('Z')) || > + (lpTargetPath[4] >= _T('a') && > + lpTargetPath[4] <= _T('z')) ); > + } > + > + free(lpTargetPath); > + > + return Result; > +}

8 years, 9 months

1
0
0 0

Status Meeting (June 2016)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place this Thursday, 30rd of June, 19:00 UTC. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. Alternative place for the meeting is #reactos-meeting on Freenode. Please send agenda proposals to me before the meeting. My proposal is to discuss 0.4.2 release plans. Regards, Aleksey Bragin

8 years, 9 months

1
0
0 0

Re: [ros-dev] Pale Moon drops ReactOS support

by Love Nystrom

Correct me if I'm wrong (Alex?), but isn't the biggest difference between kernel 5.2 and 6.x that 6.x is *paging the kernel* ? (A huge design mistake if you ask me. One I bet will bite MS on the a**. If the kernel gets too fat it needs liposuction, not paging.) IMHO, adding new APIs, while keeping the (non-paging) kernel seems ideal. Best Regards // Neo On 2016-05-19 05.43, ros-dev-request(a)reactos.org wrote: > Subject: > Re: [ros-dev] Pale Moon drops ReactOS support > From: > Alex Ionescu <ionucu(a)videotron.ca> > Date: > 2016-05-19 02.33 > > To: > ReactOS Development List <ros-dev(a)reactos.org> > > > I don't believe I said 'let's add random exports to our DLLs'. In > fact, in your old thread, I was totally FOR your idea, I even wrote > that the only sane way of doing it is with the app compat work. > > On Wed, May 18, 2016 at 9:27 PM, Timo Kreuzer<timo.kreuzer(a)web.de> wrote: >> >We have been discussing this before and I wonder that Alex is not heavily >> >opposing the idea of randomly adding new exports to our user mode DLLs. It >> >is a well known fact that applications check for existance of exports to >> >decide how to behave, so ... not going to go over this again. >> > >> >To addess this issue I suggested to implement a compatibility layer. And >> >there was a detailed discussion about that on this mailing list. >> >https://www.reactos.org/pipermail/ros-dev/2015-March/017216.html >> > >> >Please take your time to read the whole thread again so we can avoid wasting >> >time, talking about the same things again. >> > >> >Timo -- There is one thing stronger than all the armies in the world, and that's an idea whose time has come. [Victor Hugo]

8 years, 10 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [zhu] 71644: Implemented IRQ cancelling for listen() and connect() calls.

by Thomas Faber

On 2016-06-15 12:10, zhu(a)svn.reactos.org wrote: > --- branches/GSoC_2016/lwIP/drivers/network/tcpip/main.c [iso-8859-1] (original) > +++ branches/GSoC_2016/lwIP/drivers/network/tcpip/main.c [iso-8859-1] Wed Jun 15 19:10:40 2016 > @@ -384,7 +384,9 @@ > Quickie: > Irp->IoStatus.Status = Status; > > - return Irp->IoStatus.Status; > + IoCompleteRequest(Irp, IO_NETWORK_INCREMENT); > + > + return Irp->IoStatus.Status; > } > > static This is illegal. IoCompleteRequest frees the IRP so you must not access it afterwards, and use the local variable instead.

8 years, 10 months

1
0
0 0

I can't debug CoInitialize function

by Yonggang Chen

Hello developers, After building ReactOS and Rostests successfully, I can't debug CoInitialize function through Visual Studio 2015. It seems Visual Studio thinks I'm using their CoInitialize of Windows kernel. Anybody can help me? Here is the steps I used to compile ReactOS and Rostests: 1. install Build Environment https://reactos.org/wiki/ReactOS_Build_Environment 2. download code to the folder specified when by RosBE during installing code: svn://svn.reactos.org/reactos/trunk/reactos http://svn.reactos.org/reactos/trunk/rostests/ reactOS directory -> E:\Work\reactos rostests directory -> E:\Work\reactos\modules\rostests 3. generate reactos.sln for Visual Stdio (a). Open a Windows DDK/WDK/Visual Studio 2015 command prompt. (b). run the following command in the code root: configure.cmd VSSolution 4. build the huge solutions msbuild reactos.sln /m 5. open the 'ole32_winetest.vcxproj' (E:\Work\reactos\output-VS-i386\modules\rostests\winetests\ole32) Set the command arguments 'ole2', set breakpoint at CoInitialize line, and start beginning by pressing F5, but Visual Studio can't get into CoInitialize funtion Best regards Yonggang Chen

8 years, 10 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [apriyadarshi] 71530: Added INF File for driver installation with minimal configuration. Device Detection and Initialization working -- tested on VMware. StorPortAllocatePool not working, so asked ...

by Alex Ionescu

Hi, Implementing MSAHCI would be "more correct" for the system, however MSAHCI also doesn't use STORPORT, it uses ATAPORT, which requires changing our PCIIDEX model to support that. Which I think would put Aman's work out of scope. Now, MSAHCI would be ported to use STORPORT instead, but then we'd essentially be implementing a legacy component on top of a legacy port driver. At least, by implementing STORAHCI on top of STORPORT, we can implement a 'modern' component on top of the legacy port driver. And for this, I would either recommend doing things like implementing StorPortExtendedFunction if Aman can do it -- or if someone can help him, or, avoiding its use with temporary work/arounds, etc. _as long as those workarounds still work in Windows_. Best regards, Alex Ionescu On Sun, Jun 5, 2016 at 9:10 PM, Thomas Faber <thomas.faber(a)reactos.org> wrote: > I'm not an expert so I'm not sure what way is best. But I see at least > 4 solutions: > * There seems to be a way to get the extended function table through > StorPortNotification/GetExtendedFunctionTable. This would provide > some of the newer functionality even with older storport, but is > potentially an undocumented hack > * Avoid using the modern functionality and implement an old-storport > compatible storahci, which implies using only memory from the adapter > extension, and probably a few more things > * Rely on a "modern" storport and do the testing in a newer Windows > version. Then when ROS gets storport it simply needs to be a "modern" > version > * Do not use storport and implement msahci rather than storahci > > Option 2 would give the greatest compatibility but I can't pretend to > understand what limitations it will imply. > > > On 2016-06-05 21:43, Aman Priyadarshi wrote: > > Yeah msahci is ataport miniport driver. > > Then what would be the best idea? Leave it with the implementation I made > > there. "Allocated memory for all port extension within device extension?" > > ᐧ > > > > > > Regards > > *Aman Priyadarshi* > > *www.atomixos.com <http://www.atomixos.com>* > > > > > > On Mon, Jun 6, 2016 at 1:02 AM, Thomas Faber <thomas.faber(a)reactos.org> > > wrote: > > > >> On 2016-06-05 14:40, apriyadarshi(a)svn.reactos.org wrote: > >>> Author: apriyadarshi > >>> Date: Sun Jun 5 12:40:49 2016 > >>> New Revision: 71530 > >>> > >>> URL: http://svn.reactos.org/svn/reactos?rev=71530&view=rev > >>> Log: > >>> Added INF File for driver installation with minimal configuration. > >>> Device Detection and Initialization working -- tested on VMware. > >>> StorPortAllocatePool not working, so asked Storport to allocate all > >> memory just after loading up the driver -- Bad idea (will change it > later). > >> > >> StorPortAllocatePool uses StorPortExtendedFunction, which indeed is not > >> implemented in Win2003. As you can see in WDK samples, 2003's msahci is > >> not a storport miniport driver. Maybe storport wasn't advanced enough > >> for complex drivers back then? > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

8 years, 10 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [apriyadarshi] 71530: Added INF File for driver installation with minimal configuration. Device Detection and Initialization working -- tested on VMware. StorPortAllocatePool not working, so asked ...

by Thomas Faber

On 2016-06-05 14:40, apriyadarshi(a)svn.reactos.org wrote: > Author: apriyadarshi > Date: Sun Jun 5 12:40:49 2016 > New Revision: 71530 > > URL: http://svn.reactos.org/svn/reactos?rev=71530&view=rev > Log: > Added INF File for driver installation with minimal configuration. > Device Detection and Initialization working -- tested on VMware. > StorPortAllocatePool not working, so asked Storport to allocate all memory just after loading up the driver -- Bad idea (will change it later). StorPortAllocatePool uses StorPortExtendedFunction, which indeed is not implemented in Win2003. As you can see in WDK samples, 2003's msahci is not a storport miniport driver. Maybe storport wasn't advanced enough for complex drivers back then?

8 years, 10 months

2
2
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 71524: [SHELL32] - Minor stylistic whitespace changes. - Use 'IDA_DESKBROWSER' instead of hardcoding its value. - The shell progman window uses the COLOR_DESKTOP as its hbrBackground: pa...

by Thomas Faber

On 2016-06-05 01:29, hbelusca(a)svn.reactos.org wrote: > - rcDesk.left = GetSystemMetrics(SM_XVIRTUALSCREEN); > - rcDesk.top = GetSystemMetrics(SM_YVIRTUALSCREEN); > - rcDesk.right = rcDesk.left + GetSystemMetrics(SM_CXVIRTUALSCREEN); > - rcDesk.bottom = rcDesk.top + GetSystemMetrics(SM_CYVIRTUALSCREEN); > + rcDesk.left = GetSystemMetrics(SM_XVIRTUALSCREEN); > + rcDesk.top = GetSystemMetrics(SM_YVIRTUALSCREEN); > + rcDesk.right = GetSystemMetrics(SM_CXVIRTUALSCREEN); > + rcDesk.bottom = GetSystemMetrics(SM_CYVIRTUALSCREEN); Are you sure about this? "CX" normally means width, so right = left + cx seems more logical. And SM_XVIRUTALSCREEN is probably 0 most of the time so it would be hard to notice.

8 years, 10 months

2
3
0 0

https://code.reactos.org/ does not show recent revisions

by Alexander Rechitskiy

8 years, 10 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 71486: [WIN32K] Display a nice ReactOS version desktop watermark (with different fonts) when the corresponding registry values are set. See http://winaero.com/blog/a-new-way-to-display-t...

by Ged Murphy

There's another one of these when the OS is running in test mode. "Bcdedit -set TESTSIGNING ON" will display the following: Test Mode Windows (n) Build (n) Maybe you can add that one when Alex finishes his UEFI/BCD stuff :) -----Original Message----- From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of hbelusca(a)svn.reactos.org Sent: 01 June 2016 16:25 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [hbelusca] 71486: [WIN32K] Display a nice ReactOS version desktop watermark (with different fonts) when the corresponding registry values are set. See http://winaero.com/blog/a-new-way-to-display-t... Author: hbelusca Date: Wed Jun 1 15:24:38 2016 New Revision: 71486 URL: http://svn.reactos.org/svn/reactos?rev=71486&view=rev Log: [WIN32K] Display a nice ReactOS version desktop watermark (with different fonts) when the corresponding registry values are set. See http://winaero.com/blog/a-new-way-to-display-the-windows-version-on-your-de… for more details (which works on Windows 2003 too). CORE-11349 #resolve

8 years, 10 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [mjansen] 71439: [APPHELP] Begin shimlib implementation. CORE-11329 Implement some macro's and functions that help when registering shims. These are all written in C, so that wine can use the shim ...

by Ged Murphy

Would it not be better to do all this in C++ and let wine write a C interface around it? When we're trying to move to C++, it seems like a step backwards in order to support wine's insistence on using C -----Original Message----- From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mjansen(a)svn.reactos.org Sent: 28 May 2016 17:43 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [mjansen] 71439: [APPHELP] Begin shimlib implementation. CORE-11329 Implement some macro's and functions that help when registering shims. These are all written in C, so that wine can use the shim ... Author: mjansen Date: Sat May 28 16:42:57 2016 New Revision: 71439 URL: http://svn.reactos.org/svn/reactos?rev=71439&view=rev Log: [APPHELP] Begin shimlib implementation. CORE-11329 Implement some macro's and functions that help when registering shims. These are all written in C, so that wine can use the shim libraries as well.

8 years, 10 months

4
4
0 0

Semi-protection of our Wikipedia page

by Jared Smudde

Hello all, It seems that our Wikipedia page seems to have somewhat incorrect information in some sections on the page. Some of it seems to come from IP address which means that they are unregistered. Some of the information could be correct but some of the other information added could be incorrect. I propose that we can see if the wiki page could be Semi-Protected. If the page is Semi-Protected, that means that non-registered users (People logged as IPs in the log) and newly registered users (people that have less than 10 edits and that have been only registered for 4 days). This would mean that people that have been registered for a while and have made edits could edit the page. I hope that this would help with some of the incorrect information on the web page. Not sure what your thoughts are on this but I think it would be nice to have. Jared

8 years, 10 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 71412: [REISERFSLIB] Stub the ReiserFS lib CORE-11005

by Timo Kreuzer

I thought the idea of the folder reorganization was to get some sense into it. But that doesn't work if people keep adding stuff to the sdk/lib folder, just because it is a lib! I don't see why a file system library would have any reason to go into the SDK. Thanks, Timo Am 26.05.2016 um 20:08 schrieb pschweitzer(a)svn.reactos.org: > Author: pschweitzer > Date: Thu May 26 18:08:42 2016 > New Revision: 71412 > > URL: http://svn.reactos.org/svn/reactos?rev=71412&view=rev > Log: > [REISERFSLIB] > Stub the ReiserFS lib > > CORE-11005 > > Added: > trunk/reactos/sdk/lib/fslib/reiserfslib/ > trunk/reactos/sdk/lib/fslib/reiserfslib/CMakeLists.txt (with props) > trunk/reactos/sdk/lib/fslib/reiserfslib/reiserfslib.c (with props) > trunk/reactos/sdk/lib/fslib/reiserfslib/reiserfslib.h (with props) > Modified: > trunk/reactos/sdk/lib/fslib/CMakeLists.txt > > Modified: trunk/reactos/sdk/lib/fslib/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/sdk/lib/fslib/CMakeLists.t… > ============================================================================== > --- trunk/reactos/sdk/lib/fslib/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/sdk/lib/fslib/CMakeLists.txt [iso-8859-1] Thu May 26 18:08:42 2016 > @@ -2,5 +2,6 @@ > add_subdirectory(btrfslib) > add_subdirectory(ext2lib) > add_subdirectory(ntfslib) > +add_subdirectory(reiserfslib) > add_subdirectory(vfatlib) > add_subdirectory(vfatxlib) > > Added: trunk/reactos/sdk/lib/fslib/reiserfslib/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/sdk/lib/fslib/reiserfslib/… > ============================================================================== > --- trunk/reactos/sdk/lib/fslib/reiserfslib/CMakeLists.txt (added) > +++ trunk/reactos/sdk/lib/fslib/reiserfslib/CMakeLists.txt [iso-8859-1] Thu May 26 18:08:42 2016 > @@ -0,0 +1,3 @@ > + > +add_library(reiserfslib reiserfslib.c) > +add_dependencies(reiserfslib psdk) > > Propchange: trunk/reactos/sdk/lib/fslib/reiserfslib/CMakeLists.txt > ------------------------------------------------------------------------------ > svn:eol-style = native > > Added: trunk/reactos/sdk/lib/fslib/reiserfslib/reiserfslib.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/sdk/lib/fslib/reiserfslib/… > ============================================================================== > --- trunk/reactos/sdk/lib/fslib/reiserfslib/reiserfslib.c (added) > +++ trunk/reactos/sdk/lib/fslib/reiserfslib/reiserfslib.c [iso-8859-1] Thu May 26 18:08:42 2016 > @@ -0,0 +1,36 @@ > +/* > + * COPYRIGHT: See COPYING in the top level directory > + * PROJECT: ReactOS ReiserFS library > + * FILE: lib/fslib/reiserfslib/reiserfslib.c > + * PURPOSE: ReiserFS lib > + * PROGRAMMERS: Pierre Schweitzer > + */ > +#include "reiserfslib.h" > + > +#define NDEBUG > +#include <debug.h> > + > +NTSTATUS NTAPI > +ReiserfsFormat(IN PUNICODE_STRING DriveRoot, > + IN FMIFS_MEDIA_FLAG MediaFlag, > + IN PUNICODE_STRING Label, > + IN BOOLEAN QuickFormat, > + IN ULONG ClusterSize, > + IN PFMIFSCALLBACK Callback) > +{ > + UNIMPLEMENTED; > + return STATUS_SUCCESS; > +} > + > + > +NTSTATUS WINAPI > +ReiserfsChkdsk(IN PUNICODE_STRING DriveRoot, > + IN BOOLEAN FixErrors, > + IN BOOLEAN Verbose, > + IN BOOLEAN CheckOnlyIfDirty, > + IN BOOLEAN ScanDrive, > + IN PFMIFSCALLBACK Callback) > +{ > + UNIMPLEMENTED; > + return STATUS_SUCCESS; > +} > > Propchange: trunk/reactos/sdk/lib/fslib/reiserfslib/reiserfslib.c > ------------------------------------------------------------------------------ > svn:eol-style = native > > Added: trunk/reactos/sdk/lib/fslib/reiserfslib/reiserfslib.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/sdk/lib/fslib/reiserfslib/… > ============================================================================== > --- trunk/reactos/sdk/lib/fslib/reiserfslib/reiserfslib.h (added) > +++ trunk/reactos/sdk/lib/fslib/reiserfslib/reiserfslib.h [iso-8859-1] Thu May 26 18:08:42 2016 > @@ -0,0 +1,8 @@ > +/* > + * COPYRIGHT: See COPYING in the top level directory > + * PROJECT: ReactOS ReiserFS library > + * FILE: lib/fslib/reiserfslib/reiserfslib.h > + */ > +#define NTOS_MODE_USER > +#include <ndk/umtypes.h> > +#include <fmifs/fmifs.h> > > Propchange: trunk/reactos/sdk/lib/fslib/reiserfslib/reiserfslib.h > ------------------------------------------------------------------------------ > svn:eol-style = native > > >

8 years, 10 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 71419: [NETSHELL]: Fix french orthograph.

by Pierre Schweitzer

Le 27/05/2016 00:37, hbelusca(a)svn.reactos.org a écrit : > @@ -95,7 +95,7 @@ > FONT 8, "MS Shell Dlg" > BEGIN > LTEXT "Pour le pÃ©riphÃ©rique :", IDC_STATIC, 33, 2, 100, 50 > - LTEXT "s. o.", IDC_NETWORK_DEVICE, 105, 2, 253, 20 > + LTEXT "n/a", IDC_NETWORK_DEVICE, 105, 2, 253, 20 > LTEXT "Les composants sÃ©lectionnÃ©s sont utilisÃ©s par cette connexion :", IDC_STATIC, 33, 12, 253, 20 > CONTROL "", IDC_COMPONENT_LIST, "SysListView32", LVS_REPORT | LVS_SINGLESEL | LVS_SHOWSELALWAYS | LVS_NOCOLUMNHEADER | LVS_NOSORTHEADER | WS_BORDER | WS_TABSTOP, 33, 22, 250, 50 > PUSHBUTTON "&Installer...", IDC_NETWORK_INSTALL, 122, 75, 50, 14, WS_DISABLED | WS_TABSTOP For the record, "n/a" isn't French. n/a means "Not available". "s. o." means "Sans objet" which is the closest. -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

8 years, 11 months

1
0
0 0

Wiki is under spam attack again

by Alexander Rechitskiy

8 years, 11 months

2
1
0 0

Status Meeting (May 2016)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place next Thursday, 2nd of June, 19:00 UTC, as I was busy before and general consensuss on the IRC channel was to move it one week further. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. Please send agenda proposals to me before the meeting. Regards, Aleksey Bragin

8 years, 11 months

1
0
0 0

Re: [ros-dev] [CORE-11291] Create Windows 7 spec files for core DLLs

by Love Nystrom

On 2016-05-25 19.00, I wrote: > Unfortunately, ntdll.pdb only exports 'SymTagPublicSymbol', no > 'SymTagFunction' symbols, If any of you is rich or fortunate enough to have a full MSDN subscription you ought to be able to use a checked build of Win7SP1 to generate the whole '.spec' enchilada.. I would if I was, but alas I'm not :/ If you could *lend me* ISO's of checked W7SP1 x86/x64, I'll build checked virtual machines and generate the whole shebang (provided SymSrv will fetch checked symbols (which I don't know)). Best Regards // Neo

8 years, 11 months

1
0
0 0

Re: [ros-dev] rosapps CreateSpec (Fw: ReactOS versioning)

by Love Nystrom

Forget this issue... It remains, but I've moved on. Thanks anyway. // Neo On 2016-05-24 19.00, Love Nystrom <love.nystrom(a)gmail.com> wrote: > SymSrvIsStore keeps failing with error 0x7E no matter what I do :-/ -- There is one thing stronger than all the armies in the world, and that's an idea whose time has come. [Victor Hugo]

8 years, 11 months

1
0
0 0

[CORE-11291] Create Windows 7 spec files for core DLLs

by Love Nystrom

@Timo, I uploaded an ntdll.spec for Win7SP1. Unfortunately, ntdll.pdb only exports 'SymTagPublicSymbol', no 'SymTagFunction' symbols, so it's not possible to generate the parameter lists. If they're needed they'll have to be inserted manually or I'll have to write a tool that gets them from "wInternl.h" :/ ++ At least I was able to resolve the names of the 8 ordinal functions. I won't go into all the skull dredging details of getting thus far.. Suffice to say it involved uttering various sulphur reeking curses in nine different languages and threatening the entire human race with extinction, writing a dummy program and running it in WinDbg to make SymSrv fetch ntdll.pdb, and hacking CreateSpec beyond recognition with various hardcoded path names. Best Regards // Neo

8 years, 11 months

1
0
0 0

Weirdness on QEMU

by Zachary Gorden

So I've been trying to get ReactOS installed on the Windows QEMU build from https://qemu.weilnetz.de/ and during the file copy part of the first stage installer the thing, slows down. Substantially. And then silently comes to a standstill. I'm not sure whether this is an I/O issue in ReactOS or what, the old qemu that we used for the older 0.3.x releases didn't have this problem. Anyone have any ideas?

8 years, 11 months

2
2
0 0

Re: [ros-dev] 4th scenario

by Love Nystrom

On 2016-05-24 19.00, "David Quintana (gigaherz)" <gigaherz(a)gmail.com> wrote: > Wouldn't that make people MORE interested in using reactos if it > becomes a way for them to have NT6, without pirating or buying Windows? Yes it would, of course.. I understand there is, f.ex, a keen interest in India. India has a long history of mathematics, philosophy, et c, but has been quite poor for as long as I remember. A free windows compatible OS would be most welcome, I'm sure. Sidenote: They have good programmers too (even though they have a tendency to "do as they're told" and say nothing even if they see a better way to go. (A cultural thing.)) Here in Southeast Asia computer literacy is still in it's infancy, and the people a far from wealthy, so I'm sure a working ReactOS would be most welcome if people knew about it. Best Regards // Neo > > On 23 May 2016 at 14:21, Love Nystrom <love.nystrom(a)gmail.com > <mailto:love.nystrom@gmail.com>> wrote: > > Ok, I can understand if it has become uncommon in rich parts of > the world like Europe and US, > f.ex in Italy, but the rest of the world would probably seem > arcane computerwise to you. > > Here in Southeast Asia where I live, many still run WinXP on their > office workstations. > Likewise, they run Server 2oo3, if they indeed have legitimate > licenses at all. > In the computer shops you'll only see Win10 OEM though, cause MS > dictates it, > while the black market for cracked software of every kind is huge. > -- There is one thing stronger than all the armies in the world, and that's an idea whose time has come. [Victor Hugo]

8 years, 11 months

1
0
0 0

rosapps CreateSpec (Fw: ReactOS versioning)

by Love Nystrom

@Timo, @Anyone, I can't get a connection to the public symbol server, and my local ntdll.pdb et.al don't match the ones in my system, so the spec files I generate are half-baked.. No parameters. I can't figure out why SymSrv won't connect to http://msdl.microsoft.com/download/symbols (The malfunction does not seem to be isolated to CreateSpec, I see it in VStudio 2oo8 and WinDbg too.) SymSrvIsStore keeps failing with error 0x7E no matter what I do :-/ I'm on Win7SP1 x64 and SymSrv.dll and DbgHelp.dll are both 6.8. Anybody got any clues to resolve this ? Some kind of bitness issue (64<-->32) ? Misconfigured sym server (65.55.10.11) ? MS refuse to dish out symbols to north-east Thailand ? The protocol is HTTP(s), so there shouldn't be blockage from my ISP. My firewall don't trigger so it shouldn't be blocking either. Googling for a solution yields zilch.. Only 1000 ways to set _NT_SYMBOL_PATH and absolutely zero hints to resolve malfunctions :-/ A little help guys ? Best Regards // Neo

8 years, 11 months

1
0
0 0

Re: [ros-dev] 4th scenario

by Love Nystrom

Ok, I can understand if it has become uncommon in rich parts of the world like Europe and US, f.ex in Italy, but the rest of the world would probably seem arcane computerwise to you. Here in Southeast Asia where I live, many still run WinXP on their office workstations. Likewise, they run Server 2oo3, if they indeed have legitimate licenses at all. In the computer shops you'll only see Win10 OEM though, cause MS dictates it, while the black market for cracked software of every kind is huge. But this discussion is a bit moot, isn't it? :) Best Regards // Neo On 2016-05-23 15.53, Riccardo Paolo Bestetti <riccardo.kyogre(a)live.it> wrote: > > Il 22/05/2016 23:14, Love Nystrom ha scritto: > >> Server 2oo3 might not be used in big corporations anymore, but I >> think it's not uncommon to keep running it in small companies and >> home servers (due to high licensing cost of Windows server versions). > It /is/ pretty uncommon. > I'm in contact with IT administrators from many small companies, at > this point everyone has either (a) moved to Linux, (b) moved to some > kind of cloud service or (c) upgraded to Server 2012. > Even my school, which struggles to repaint walls, has done (c), lol. > I don't know if it is any different in other parts of the world, but I > suspect it is pretty much the same.

8 years, 11 months

2
1
0 0

Re: [ros-dev] 4th scenario

by Love Nystrom

Server 2oo3 might not be used in big corporations anymore, but I think it's not uncommon to keep running it in small companies and home servers (due to high licensing cost of Windows server versions). Anyway.. IMO there's nothing wrong in moving towards NT6x API-wise, as long as we're not forced to re-architect the *core* of the system (scheduler, et c). Paging the kernel would be a big mistake. Best Regards // Neo On 2016-05-22 18.42, ros-dev-request(a)reactos.org wrote: > They are not fucked up, since they legitimately don't care for the 3 > people out there still using 2k3. > And we are not fucked up, we are only pushed to move to NT6+ > > Timo > > Am 21.05.2016 um 06:12 schrieb Love Nystrom: >> No, they are... Not we ;) >> Same thing would happen if you try to run e.g. a Vista exe on NT4. >> >> // Neo >> >> On 2016-05-20 22.52, Javier Agustìn Fernàndez Arroyo >> <elhoir(a)gmail.com> wrote: >> > Subject: Re: [ros-dev] Pale Moon drops ReactOS support >> > Date: 2016-05-20 22.51 >> > >> > 4th scenario - App is actually "buggy" and doesnt check for any >> export. We´re fucked up :P -- There is one thing stronger than all the armies in the world, and that's an idea whose time has come. [Victor Hugo]

8 years, 11 months

3
3
0 0

Re: [ros-dev] 4th scenario

by Love Nystrom

On 2016-05-23 04.21, "David Quintana (gigaherz)" <gigaherz(a)gmail.com> wrote: > No one is suggesting paging the kernel. Stop being paranoid about that. Ah.. Excellent.. That's such a relief to hear :) > We are speaking about API interfaces for user apps and drivers. > Whatever that implies, will be examined on a case by case basis. ;P Good.. Then we are in full agreement :) I'll sink my teeth into Timo's epic when I can. I'm hoping there's some way we can avoid the mess SxS is causing on e.g my Win7. (I must have 10 versions of each RTL since 2oo5 installed by SxS , and dito with comctl32 versions, all with these obnoxiously long names.) > > On 22 May 2016 at 23:14, Love Nystrom <love.nystrom(a)gmail.com > <mailto:love.nystrom@gmail.com>> wrote: > > Server 2oo3 might not be used in big corporations anymore, > but I think it's not uncommon to keep running it in small companies > and home servers (due to high licensing cost of Windows server > versions). > > Anyway.. IMO there's nothing wrong in moving towards NT6x API-wise, > as long as we're not forced to re-architect the *core* of the system > (scheduler, et c). Paging the kernel would be a big mistake. > > Best Regards > // Neo >

8 years, 11 months

1
0
0 0

Re: [ros-dev] Ros-dev Digest, Vol 141, Issue 24

by Love Nystrom

On 2016-05-23 04.21, "David Quintana (gigaherz)" <gigaherz(a)gmail.com> wrote: > I believe Riccardo referred to people developing apps for ReactOS/NT5, > when they can write them for NT6 instead. I guess I belong to a dying breed ;) I always try to keep my API usage to the least common denominator so that people may run my programs even on legacy systems. I wish more programmers would do the same.. Using a newer API "just because it's there", when there is *no real need* for it, is just plain rude to users IMHO. (F.ex. using SHGetKnownFolderPath when SHGetFolderPath would suffice.) Best Regards // Neo

8 years, 11 months

1
0
0 0

Re: [ros-dev] Actually a GOOD architecture.

by Love Nystrom

Oh.. I get it.. I thought you meant NT vs Unix. I guess we may close the subject then :) (I'm a usermode guy mostly, and I puke when I have to write for Linux, since they don't have things like GDI, et cetera.) Best Regards // Neo On 2016-05-23 04.21, ros-dev-request(a)reactos.org wrote: > Il 22/05/2016 14:18, David Quintana (gigaherz) ha scritto: >> I believe Riccardo referred to people developing apps for >> ReactOS/NT5, when they can write them for NT6 instead. > That's what I meant. > > I also agree with you, Neo, that NT, even version 5, is overall a > better architecture than Linux. > However, I agree with gigahertz that discussing this isn't all that > useful: good != not obsolete. > > Best regards, > --- /Riccardo Paolo Bestetti/

8 years, 11 months

1
0
0 0

Re: [ros-dev] ReactOS versioning

by Love Nystrom

Ah.. Ok, I'll peruse it soon as I get a chance. Best Regards // Neo On 2016-05-22 18.42, Timo Kreuzer <timo.kreuzer(a)web.de> wrote: > I created an epic with a few subtasks regarding ReactOS versioning: > https://jira.reactos.org/browse/CORE-11288 > > Timo

8 years, 11 months

1
0
0 0

Actually a GOOD architecture.

by Love Nystrom

On 2016-05-18 02.10, Riccardo Paolo Bestetti <riccardo.kyogre(a)live.it> wrote: > It's not like developers are gonna pick up again an old (and, > honestly, bad!) architecture just because it is made free, when *here > and now* we already have a better alternative. Bad architecture ? Compared to Linux ? I refute that on the strongest. F.ex: Linux lacks, even to this day, a unified graphics API like GDI (X-Windows notwithstanding), and window manager. Instead they have a plethora of disparate kludges and hacks on top of X-Windows, all more or less cumbersome to use. The API flora of the Windows architecture should, by rights, make Linux programmers green with envy ;-) (Why do you think the WinE project was born in the first place?) Best Regards // Neo

8 years, 11 months

3
2
0 0

ReactOS versioning

by Love Nystrom

Excuse my extremely late thoughts on this issue.. Perhaps they're moot already. Regarding pt.3 in Timo's very succinct post (a year ago), I see a possibility in a "proxy" scheme as follows.. The "standard" dlls knows the 6.x APIS, while implementing the "base" 5.2 functions, and forward newer APIs incrementally to versional "add-on" dlls. This ought to avoid bloat, both RAM and disk-wise. // "Proxy" kernel32.dll knows APIs up to X.Y kernel32.dll!Some52API_1 :: Built-in // "Base" APIs kernel32.dll!Some60API_2 -> rkernel32_60.dll // Additional APIs only kernel32.dll!Some61API_3 -> rkernel32_61.dll // Additional APIs only For DLL_PROCESS_ATTACH the ROS loader could provide kernel32.dll et.al. with version info, gleaned from the exe, through lpvReserved, in case version specific init is needed. In case the exe has no version info, fall back to 5.2. Dito for the other "standard" dlls. Was this what you had in mind? (PS. I'm not privvy to the mechanics of SxS, but I think they replace the entire dlls, wholesale.. right?) Best Regards // Neo On 2016-05-20 17.57, ros-dev-request(a)reactos.org wrote: > From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of Timo Kreuzer > Sent: 18 May 2016 20:28 > To: ReactOS Development List<ros-dev(a)reactos.org> > Subject: Re: [ros-dev] Pale Moon drops ReactOS support > > Looks like I have to chime in here. > > We have been discussing this before and I wonder that Alex is not heavily opposing the idea of randomly adding new exports to our user mode DLLs. It is a well known fact that applications check for existance of exports to decide how to behave, so ... not going to go over this again. > > To addess this issue I suggested to implement a compatibility layer. And there was a detailed discussion about that on this mailing list. > https://www.reactos.org/pipermail/ros-dev/2015-March/017216.html > > Please take your time to read the whole thread again so we can avoid wasting time, talking about the same things again. > > Timo > > ... > > Did you read it? Ok, then we can continue;-) > > Some remaining questions: > 1. Does our SxS / ActiveCtx work properly, and does it work with registry/appcompat db? Otherwise what do we need to make it work? Aleksey? > 2. How do we organize the DLLs? I would suggest to unite some core DLLs into "ros-kernelbase.dll" or something and gdi32/user32 into ros-win32.dll and export all functions from those, using forwarder DLLs through SxS. At the same time we should reorganize the code, organizing it the way that MS API sets do it. And also move the stuff out of the "dlls" folder into "win32core" or something. > 3. How do we handle ntdll? Can we use SxS for ntdll as well? Obviously we cannot load the original ntdll with it, but we can probably load versioned wrapper ntdlls and resolve imports to those. > > Timo > > Am 18.05.2016 um 17:01 schrieb Ged Murphy: >> >Okay, considering no other devs are chiming in on this, and Alex and I had a similar view, I'd like to propose that we move towards a more hybrid system and remove the rule that APIs that weren’t in 2k3 shouldn't be added. >> > >> >Proposal: >> > 1) Add all user mode APIs directly into the code base, and do away with the 'kernel32_vista' libraries we have. >> > 2) Start to add kernel APIs which aren’t reliant on a particular feature. Rtl APIs are the obvious one as Alex highlighted, missing syscalls or enums for 'get/set info' APIs are another obvious one. >> > 3) Features from later versions of NT can be added (e.g. IO cancelation, UEFI, ASLR, etc). The supporting APIs should only be added when the underlying support is in place. (i.e. don't stub NT6 APIs) >> > 4) Continue to report as NT5.2/win2k3 for now. We can consider bumping usermode to report something newer at a later stage. >> > 5) In the short term add a simple compatibility mode which can provide a different OS version for whitelisted processes. The front end could be similar Win7's ' compatibility tab in the file properties, however it wouldn't use shimeng.dll, apphelp.dll, etc, it would just modify the versioning APIs. >> > >> >IMO the above is a quick win to get newer apps running. Apps that >> >check for OS version by looking for APIs should now be happy due to >> >#1. Apps which call VerifyVersionInfo / GetVersion / etc can be >> >tricked into thinking they're running on a later OS due to #5 >> > >> >David mentioned a compatibility shim would open the doors to NT6, but I don't think we should be using it for this purpose. A compatibility shim should behave more like the Windows one, that is it should provide 'hacks' to a more modern codebase to get older apps to work (e.g. 9x APIs, missing flags, bugs some apps rely on, etc). >> >I do think the compatibility shim is worthwhile technology to add, but >> >I think we should use it as intended instead of trying to make it look >> >into the future as well as the past. (btw, didn't Alex write a tool >> >for dumping the shim db in Windows which shows all the 'hacks' MS >> >apply??) >> > >> >Comments please. >> > >> >Ged. >> > >> > >> >-----Original Message----- >> >From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex >> >Ionescu >> >Sent: 17 May 2016 19:05 >> >To: ReactOS Development List<ros-dev(a)reactos.org> >> >Subject: Re: [ros-dev] Pale Moon drops ReactOS support >> > >> >The project doesn't have to be hard-coded to NT5. For example, I am building a UEFI loader/bootmgr based on Windows 10, because 2003 doesn't boot on UEFI systems. >> > >> >That being said, I don't see any good reason for us not to still mainly focus on 2003 for the kernel. The kernel is NOT what's preventing apps from working, or hardware from working. What's preventing that from working is: >> > >> >1) Lacking user-mode APIs, and in some cases Rtl APIs (sure, implement >> >Win 10 ones!) >> >2) Lacking hardware support for things like UEFI (I'm working on it), AHCI (we have a student working on it), USB 3 (someone can implement this...but USB 2 barely works), etc..etc..etc.. >> > >> >Find me a single device driver that*only* works on NT 6... Server >> >2003 is still a support MS OS, so by definition there's still drivers for it. >> >Best regards, >> >Alex Ionescu >> > -- There is one thing stronger than all the armies in the world, and that's an idea whose time has come. [Victor Hugo]

8 years, 11 months

2
2
0 0

Re: [ros-dev] 4th scenario

by Love Nystrom

No, they are... Not we ;) Same thing would happen if you try to run e.g. a Vista exe on NT4. // Neo On 2016-05-20 22.52, Javier Agustìn Fernàndez Arroyo <elhoir(a)gmail.com> wrote: > Subject: Re: [ros-dev] Pale Moon drops ReactOS support > Date: 2016-05-20 22.51 > > 4th scenario - App is actually "buggy" and doesnt check for any export. We´re fucked up :P

8 years, 11 months

2
1
0 0

Re: [ros-dev] Ros-dev Digest, Vol 141, Issue 21

by Love Nystrom

No, they are... Not we ;) Same thing would happen if you try to run e.g. a Vista exe on NT4. // Neo On 2016-05-20 22.52, ros-dev-request(a)reactos.org wrote: > Subject: > Re: [ros-dev] Pale Moon drops ReactOS support > From: > Javier Agustìn Fernàndez Arroyo <elhoir(a)gmail.com> > Date: > 2016-05-20 22.51 > > To: > ReactOS Development List <ros-dev(a)reactos.org> > > > 4th scenario - App is actually "buggy" and doesnt check for any > export. We´re fucked up :P >

8 years, 11 months

1
0
0 0

Re: [ros-dev] Pale Moon drops ReactOS support

by Alex Ionescu

I don't believe I said 'let's add random exports to our DLLs'. In fact, in your old thread, I was totally FOR your idea, I even wrote that the only sane way of doing it is with the app compat work. On Wed, May 18, 2016 at 9:27 PM, Timo Kreuzer <timo.kreuzer(a)web.de> wrote: > We have been discussing this before and I wonder that Alex is not heavily > opposing the idea of randomly adding new exports to our user mode DLLs. It > is a well known fact that applications check for existance of exports to > decide how to behave, so ... not going to go over this again. > > To addess this issue I suggested to implement a compatibility layer. And > there was a detailed discussion about that on this mailing list. > https://www.reactos.org/pipermail/ros-dev/2015-March/017216.html > > Please take your time to read the whole thread again so we can avoid wasting > time, talking about the same things again. > > Timo Best regards, Alex Ionescu

8 years, 11 months

4
3
0 0

Re: [ros-dev] Pale Moon drops ReactOS support

by Alex Ionescu

The project doesn't have to be hard-coded to NT5. For example, I am building a UEFI loader/bootmgr based on Windows 10, because 2003 doesn't boot on UEFI systems. That being said, I don't see any good reason for us not to still mainly focus on 2003 for the kernel. The kernel is NOT what's preventing apps from working, or hardware from working. What's preventing that from working is: 1) Lacking user-mode APIs, and in some cases Rtl APIs (sure, implement Win 10 ones!) 2) Lacking hardware support for things like UEFI (I'm working on it), AHCI (we have a student working on it), USB 3 (someone can implement this...but USB 2 barely works), etc..etc..etc.. Find me a single device driver that *only* works on NT 6... Server 2003 is still a support MS OS, so by definition there's still drivers for it. Best regards, Alex Ionescu On Tue, May 17, 2016 at 4:44 PM, Javier Agustìn Fernàndez Arroyo <elhoir(a)gmail.com> wrote: > "companies and such support NT5?" > > where "support NT5", i meant "drop support for NT5", sorry > > On Tue, May 17, 2016 at 4:43 PM, Javier Agustìn Fernàndez Arroyo > <elhoir(a)gmail.com> wrote: >> >> And why does few developers, companies and such support NT5? Because MS >> dropped support for those systems. But if ReactOS revives that support, >> maybe companies will support us. >> >> On Mon, May 16, 2016 at 10:22 PM, Riccardo Paolo Bestetti >> <riccardo.kyogre(a)live.it> wrote: >>> >>> I'd like to drop my two cents, just because I really believe in this >>> project's filosofy. Since things have gotten pretty hot in the past, >>> especially when someone who is not a developer intervened in a discussion, >>> let me apprise you that my only intention it to bring in the point of view >>> of a potential user that really wants to see ReactOS happen and isn't >>> emotionally attached to the work that has been done. >>> >>> The reality is that very very few manufacturers and developers still >>> support NT5 and all of them are going to drop support in the next few years. >>> This is just a fact. NT5 is legacy software and there's nothing no one can >>> do about that. >>> >>> I've followed this project and this mailing list for the past five years >>> and in this time I've upgraded all of the computer systems of my father's >>> business to Windows 7 and then to Windows 10, because all the pieces of >>> software they run dropped support for NT5, one after another. They still >>> have a single machine in the whole building running Windows XP, for legacy >>> software, and honestly they don't use it very often. In my school, pretty >>> much the same. And even if someone, for whatever reason, intends to run NT5 >>> for 10 more years, why should (s)he re-setup all the systems again to run >>> ReactOS instead of keeping Windows XP? >>> >>> The point is, you can either implement the architecture that runs all of >>> the computer in building, or the architecture that runs that one legacy >>> machine. And even that would happen if and only if you can achieve 100% >>> compatibility with all of NT5 and Windows XP bugs and quirks and give people >>> a really good reason to reinstall the OS on such machines, and sorry that's >>> just not gonna happen. >>> >>> I get why some of you may want to stick to NT5, but you have to be aware >>> that if you do that ReactOS will never be used in the real world. No reason >>> to stick to NT5 is good enough, since no one out there needs or wants NT5. >>> Hell, it would probably be easier for a business to switch from NT6 to >>> GNU/Linux than to go back to NT5. >>> >>> Again, these are just the two cents of a guy that works in the field. >>> >>> Best regards, >>> --- Riccardo Paolo Bestetti >>> >>> >>> Il 16/05/2016 16:42, Ged Murphy ha scritto: >>> >>> But you’re missing the point. The problem is that modern software is >>> leaving XP behind and focusing on Win7 as a minimum recommended requirement. >>> >>> What use is ReactOS if none of the modern browsers or applications will >>> run on it? It limits the OS to being a compatibility solution for older >>> software, or a POS device. No one really wants to see that. >>> >>> >>> >>> I think the best solution to start with is to keep reporting as 5.2 in >>> the kernel, but allowing developers to start moving to the NT6 model. An >>> mish-mash of NT5 and NT6 can co-exist as long things are done sensibly. e.g. >>> adding IO cancelation to our NT5 kernel isn’t going to make us incompatible >>> for XP’s drivers, but it allows us to implement an NT6 feature which hugely >>> benefits the OS. Other obvious candidates are unimplemented areas such as >>> the fltmgr . Why implement the 2k3 fltmgr when we can implement a later >>> fltmgr model which still loads older filter drivers. >>> >>> >>> >>> Usermode should also still report as win2k3 (at least in the short term), >>> but start to add NT6 APIs directly into the codebase instead of using a >>> shim. We then maintain a whitelist of processes that don’t run on ros due to >>> a minimum requirement issue, and they get a modified result from >>> VerifyVersionInfo (and friends) to a later OS version. >>> >>> >>> >>> The above changes keep things pretty simple to start with, and allow us >>> to move forward almost immediately with very little infrastructure work. >>> >>> >>> >>> Ged. >>> >>> >>> >>> >>> >>> From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of Javier >>> Agustìn Fernàndez Arroyo >>> Sent: 15 May 2016 22:55 >>> To: ReactOS Development List <ros-dev(a)reactos.org> >>> Subject: Re: [ros-dev] Pale Moon drops ReactOS support >>> >>> >>> >>> "Being runnable only on old computers" >>> >>> I think this is a bad understanding of the problem.... >>> >>> By such statement, it seems that ReactOS will only work on old computers. >>> And thats not true. >>> >>> ReactOS may work in any computer where there is hardware drivers for. >>> And, as such, any software written for XP/2k3/ReactOS will work in that >>> computer. >>> >>> And afaik, manufacturers are still releasing drivers compatible with XP >>> :) (nVidia, for example....) >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

8 years, 11 months

8
9
0 0

Regarding r71352 and SubGit

by Colin Finck

Hello all, As most of you know, I have been busy setting up a two-way Git mirror of our ReactOS repository using SubGit. Testing was done in the recent weeks by multiple people using a sandbox repository and the results looked pretty well. Therefore, SubGit was considered ready for prime time and I started a first import of our ReactOS repository. The only problem with this: Even without mirroring branches, the Git repository became a 5.5GB monster (from the 750MB of our current git-svn mirror). This size was totally not clonable as shown in testing. The proposed solution: Git offers a garbage cleaner using "git gc --aggressive". And hell yeah, it reduced the size to a nice 500MB repo. While that optimization was running and SubGit was not syncing, two revisions were committed: r71350 and r71351. Without expecting any problems, I resumed SubGit mirroring and then things started to get weird: Apparently, SubGit totally lost traction of the SVN repository and instead of syncing the two new revisions, it committed one in r71352 that _replaces_ trunk by r71349. This is one of the worst commits possible, as it forces SVN clients to redownload everything when updating their working copies. Even more, it shows me that a clear separation of permissions for the SVN Server and SubGit isn't sufficient. SubGit can and actually did harm to our repository this way. This is exactly what I was warned of and what now happened... I'm sure everybody can understand that I cannot continue with the SubGit installation under these circumstances. We cannot put our repository at risk, especially now that we're in the mid of GSoC. This way, SubGit has definitely shown that it's not ready for our repository. I deeply apologize for this trouble and especially to the critics who remained right. And of course to Hermes, whose name SubGit abused for making the guilty commit. Right now, I'm restoring the repository to r71351 using backups and "svnadmin dump". This effectively erases r71352 from SVN history. As r71352 was only online for 10 minutes, I believe it's better to get rid of that commit in SVN history rather than having everyone suffer from it. Again, I deeply apologize! With best regards, Colin

8 years, 11 months

3
2
0 0

Pale Moon drops ReactOS support

by Alexander Rechitskiy

8 years, 11 months

11
23
0 0

Re: [ros-dev] [ros-diffs] [tfaber] 71307: [HAL] - Create a wrapper version of HalpEndSoftwareInterrupt that frees its stack before calling the noreturn version of the next software interrupt handler. Fixes excessive stack u...

by Alex Ionescu

Wait, are you saying that Timo didn't discover this obvious bug for years? Best regards, Alex Ionescu On Mon, May 16, 2016 at 4:06 PM, Timo Kreuzer <timo.kreuzer(a)web.de> wrote: > Wait, are you suggesting that "doing everything the same as MS does" and > "I don't need to care for C standards, I have a huge epeen!" and > "OnlyOnePersonCanWriteHalCode AndItsNotYou".... doesn't work? :O > > > Best regards, > Timo Kreuzer > > > Am 10.05.2016 um 17:03 schrieb tfaber(a)svn.reactos.org: >> >> Author: tfaber >> Date: Tue May 10 15:03:56 2016 >> New Revision: 71307 >> >> URL: http://svn.reactos.org/svn/reactos?rev=71307&view=rev >> Log: >> [HAL] >> - Create a wrapper version of HalpEndSoftwareInterrupt that frees its >> stack before calling the noreturn version of the next software interrupt >> handler. Fixes excessive stack usage when DPCs are queued in quick >> succession. >> CORE-11123 #resolve >> >> Added: >> trunk/reactos/hal/halx86/up/pic.S (with props) >> Modified: >> trunk/reactos/hal/halx86/pic.cmake >> trunk/reactos/hal/halx86/up/pic.c >> >> Modified: trunk/reactos/hal/halx86/pic.cmake >> URL: >> http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/pic.cmake?rev=7… >> >> ============================================================================== >> --- trunk/reactos/hal/halx86/pic.cmake [iso-8859-1] (original) >> +++ trunk/reactos/hal/halx86/pic.cmake [iso-8859-1] Tue May 10 15:03:56 >> 2016 >> @@ -1,7 +1,8 @@ >> list(APPEND HAL_PIC_ASM_SOURCE >> generic/systimer.S >> - generic/trap.S) >> + generic/trap.S >> + up/pic.S) >> list(APPEND HAL_PIC_SOURCE >> generic/profil.c >> >> Added: trunk/reactos/hal/halx86/up/pic.S >> URL: >> http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/up/pic.S?rev=71… >> >> ============================================================================== >> --- trunk/reactos/hal/halx86/up/pic.S (added) >> +++ trunk/reactos/hal/halx86/up/pic.S [iso-8859-1] Tue May 10 15:03:56 >> 2016 >> @@ -0,0 +1,48 @@ >> +/* >> + * FILE: hal/halx86/up/pic.S >> + * COPYRIGHT: See COPYING in the top level directory >> + * PURPOSE: HAL PIC Management and Control Code >> + * PROGRAMMER: Thomas Faber (thomas.faber(a)reactos.org) >> + */ >> + >> +/* INCLUDES >> ******************************************************************/ >> + >> +#include <asm.inc> >> + >> +#include <ks386.inc> >> + >> +EXTERN _HalpEndSoftwareInterrupt2@8:PROC >> + >> +/* GLOBALS >> *******************************************************************/ >> + >> +.data >> +ASSUME CS:NOTHING, DS:NOTHING, ES:NOTHING, FS:NOTHING, GS:NOTHING >> + >> +/* FUNCTIONS >> *****************************************************************/ >> + >> +.code >> +PUBLIC _HalpEndSoftwareInterrupt@8 >> +.PROC _HalpEndSoftwareInterrupt@8 >> + FPO 0, 2, 0, 0, 0, FRAME_FPO >> + >> + /* Call the C function with the same arguments we got */ >> + push [esp+8] >> + push [esp+8] >> + call _HalpEndSoftwareInterrupt2@8 >> + >> + /* Check if we got a pointer back */ >> + test eax, eax >> + jnz CallIntHandler >> + >> + /* No? Just return */ >> + ret 8 >> + >> +CallIntHandler: >> + /* We got a pointer to call. Since it won't return, free up our stack >> + space, or we could end up with some nasty deep recursion */ >> + mov ecx, [esp+8] >> + add esp, 12 >> + jmp eax >> +.ENDP >> + >> +END >> >> Propchange: trunk/reactos/hal/halx86/up/pic.S >> >> ------------------------------------------------------------------------------ >> svn:eol-style = native >> >> Modified: trunk/reactos/hal/halx86/up/pic.c >> URL: >> http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/up/pic.c?rev=71… >> >> ============================================================================== >> --- trunk/reactos/hal/halx86/up/pic.c [iso-8859-1] (original) >> +++ trunk/reactos/hal/halx86/up/pic.c [iso-8859-1] Tue May 10 15:03:56 >> 2016 >> @@ -11,6 +11,11 @@ >> #include <hal.h> >> #define NDEBUG >> #include <debug.h> >> + >> +VOID >> +NTAPI >> +HalpEndSoftwareInterrupt(IN KIRQL OldIrql, >> + IN PKTRAP_FRAME TrapFrame); >> /* GLOBALS >> ********************************************************************/ >> @@ -263,7 +268,7 @@ >> * so it will always preempt until we reach PROFILE_LEVEL. >> */ >> 0b00000000000000000001011111110000, /* IRQL 20 */ >> - 0b00000000000000000001001111110000, /* IRQL 20 */ >> + 0b00000000000000000001001111110000, /* IRQL 21 */ >> 0b00000000000000000001000111110000, /* IRQL 22 */ >> 0b00000000000000000001000011110000, /* IRQL 23 */ >> 0b00000000000000000001000001110000, /* IRQL 24 */ >> @@ -732,15 +737,17 @@ >> KeGetPcr()->IRR &= ~(1 << Irql); >> } >> -VOID >> -NTAPI >> -HalpEndSoftwareInterrupt(IN KIRQL OldIrql, >> - IN PKTRAP_FRAME TrapFrame) >> +PHAL_SW_INTERRUPT_HANDLER_2ND_ENTRY >> +NTAPI >> +HalpEndSoftwareInterrupt2(IN KIRQL OldIrql, >> + IN PKTRAP_FRAME TrapFrame) >> { >> ULONG PendingIrql, PendingIrqlMask, PendingIrqMask; >> PKPCR Pcr = KeGetPcr(); >> PIC_MASK Mask; >> + UNREFERENCED_PARAMETER(TrapFrame); >> + >> /* Set old IRQL */ >> Pcr->Irql = OldIrql; >> @@ -749,10 +756,10 @@ >> { >> /* Check for pending software interrupts and compare with >> current IRQL */ >> PendingIrqlMask = Pcr->IRR & FindHigherIrqlMask[OldIrql]; >> - if (!PendingIrqlMask) return; >> + if (!PendingIrqlMask) return NULL; >> /* Check for in-service delayed interrupt */ >> - if (Pcr->IrrActive & 0xFFFFFFF0) return; >> + if (Pcr->IrrActive & 0xFFFFFFF0) return NULL; >> /* Check if pending IRQL affects hardware state */ >> BitScanReverse(&PendingIrql, PendingIrqlMask); >> @@ -777,10 +784,11 @@ >> else >> { >> /* No need to loop checking for hardware interrupts */ >> - SWInterruptHandlerTable2[PendingIrql](TrapFrame); >> - UNREACHABLE; >> + return SWInterruptHandlerTable2[PendingIrql]; >> } >> } >> + >> + return NULL; >> } >> /* EDGE INTERRUPT DISMISSAL FUNCTIONS >> *****************************************/ >> >> >> > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

8 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 71339: [NTOS][NDK][RTL]: Move the SEM_xxx flags and their corresponding RTL flags around so that they can be accessed in kernel code. I'll need them soon.

by Alex Ionescu

On Mon, May 16, 2016 at 12:40 AM, <hbelusca(a)svn.reactos.org> wrote: > +// > +// Thread Error Mode Flags > +// > +/* Also defined in psdk/winbase.h */ > +#define SEM_FAILCRITICALERRORS 0x0001 > +#define SEM_NOGPFAULTERRORBOX 0x0002 > +#define SEM_NOALIGNMENTFAULTEXCEPT 0x0004 > +#define SEM_NOOPENFILEERRORBOX 0x8000 Hermes, you consistently ignore the formatting rules of other people's code/project. Please correctly format the NDK flags instead of just copy-pasting. Best regards, Alex Ionescu

8 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 71336: [NTOS]: Remove hardcoded constants; fix a comment; move some code around to reduce the level of code indentation.

by Alex Ionescu

On Mon, May 16, 2016 at 12:23 AM, <hbelusca(a)svn.reactos.org> wrote: > - if ((!ExReadyForErrors) && (NT_ERROR(ErrorStatus))) > + if (!ExReadyForErrors && NT_ERROR(ErrorStatus)) Let's not start this again. Our coding conventions (and good programming practice) is to have every conditional in its own paren blob. Best regards, Alex Ionescu

8 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tfaber] 71307: [HAL] - Create a wrapper version of HalpEndSoftwareInterrupt that frees its stack before calling the noreturn version of the next software interrupt handler. Fixes excessive stack u...

by Timo Kreuzer

Wait, are you suggesting that "doing everything the same as MS does" and "I don't need to care for C standards, I have a huge epeen!" and "OnlyOnePersonCanWriteHalCode AndItsNotYou".... doesn't work? :O Best regards, Timo Kreuzer Am 10.05.2016 um 17:03 schrieb tfaber(a)svn.reactos.org: > Author: tfaber > Date: Tue May 10 15:03:56 2016 > New Revision: 71307 > > URL: http://svn.reactos.org/svn/reactos?rev=71307&view=rev > Log: > [HAL] > - Create a wrapper version of HalpEndSoftwareInterrupt that frees its stack before calling the noreturn version of the next software interrupt handler. Fixes excessive stack usage when DPCs are queued in quick succession. > CORE-11123 #resolve > > Added: > trunk/reactos/hal/halx86/up/pic.S (with props) > Modified: > trunk/reactos/hal/halx86/pic.cmake > trunk/reactos/hal/halx86/up/pic.c > > Modified: trunk/reactos/hal/halx86/pic.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/pic.cmake?rev=7… > ============================================================================== > --- trunk/reactos/hal/halx86/pic.cmake [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/pic.cmake [iso-8859-1] Tue May 10 15:03:56 2016 > @@ -1,7 +1,8 @@ > > list(APPEND HAL_PIC_ASM_SOURCE > generic/systimer.S > - generic/trap.S) > + generic/trap.S > + up/pic.S) > > list(APPEND HAL_PIC_SOURCE > generic/profil.c > > Added: trunk/reactos/hal/halx86/up/pic.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/up/pic.S?rev=71… > ============================================================================== > --- trunk/reactos/hal/halx86/up/pic.S (added) > +++ trunk/reactos/hal/halx86/up/pic.S [iso-8859-1] Tue May 10 15:03:56 2016 > @@ -0,0 +1,48 @@ > +/* > + * FILE: hal/halx86/up/pic.S > + * COPYRIGHT: See COPYING in the top level directory > + * PURPOSE: HAL PIC Management and Control Code > + * PROGRAMMER: Thomas Faber (thomas.faber(a)reactos.org) > + */ > + > +/* INCLUDES ******************************************************************/ > + > +#include <asm.inc> > + > +#include <ks386.inc> > + > +EXTERN _HalpEndSoftwareInterrupt2@8:PROC > + > +/* GLOBALS *******************************************************************/ > + > +.data > +ASSUME CS:NOTHING, DS:NOTHING, ES:NOTHING, FS:NOTHING, GS:NOTHING > + > +/* FUNCTIONS *****************************************************************/ > + > +.code > +PUBLIC _HalpEndSoftwareInterrupt@8 > +.PROC _HalpEndSoftwareInterrupt@8 > + FPO 0, 2, 0, 0, 0, FRAME_FPO > + > + /* Call the C function with the same arguments we got */ > + push [esp+8] > + push [esp+8] > + call _HalpEndSoftwareInterrupt2@8 > + > + /* Check if we got a pointer back */ > + test eax, eax > + jnz CallIntHandler > + > + /* No? Just return */ > + ret 8 > + > +CallIntHandler: > + /* We got a pointer to call. Since it won't return, free up our stack > + space, or we could end up with some nasty deep recursion */ > + mov ecx, [esp+8] > + add esp, 12 > + jmp eax > +.ENDP > + > +END > > Propchange: trunk/reactos/hal/halx86/up/pic.S > ------------------------------------------------------------------------------ > svn:eol-style = native > > Modified: trunk/reactos/hal/halx86/up/pic.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/up/pic.c?rev=71… > ============================================================================== > --- trunk/reactos/hal/halx86/up/pic.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/up/pic.c [iso-8859-1] Tue May 10 15:03:56 2016 > @@ -11,6 +11,11 @@ > #include <hal.h> > #define NDEBUG > #include <debug.h> > + > +VOID > +NTAPI > +HalpEndSoftwareInterrupt(IN KIRQL OldIrql, > + IN PKTRAP_FRAME TrapFrame); > > /* GLOBALS ********************************************************************/ > > @@ -263,7 +268,7 @@ > * so it will always preempt until we reach PROFILE_LEVEL. > */ > 0b00000000000000000001011111110000, /* IRQL 20 */ > - 0b00000000000000000001001111110000, /* IRQL 20 */ > + 0b00000000000000000001001111110000, /* IRQL 21 */ > 0b00000000000000000001000111110000, /* IRQL 22 */ > 0b00000000000000000001000011110000, /* IRQL 23 */ > 0b00000000000000000001000001110000, /* IRQL 24 */ > @@ -732,15 +737,17 @@ > KeGetPcr()->IRR &= ~(1 << Irql); > } > > -VOID > -NTAPI > -HalpEndSoftwareInterrupt(IN KIRQL OldIrql, > - IN PKTRAP_FRAME TrapFrame) > +PHAL_SW_INTERRUPT_HANDLER_2ND_ENTRY > +NTAPI > +HalpEndSoftwareInterrupt2(IN KIRQL OldIrql, > + IN PKTRAP_FRAME TrapFrame) > { > ULONG PendingIrql, PendingIrqlMask, PendingIrqMask; > PKPCR Pcr = KeGetPcr(); > PIC_MASK Mask; > > + UNREFERENCED_PARAMETER(TrapFrame); > + > /* Set old IRQL */ > Pcr->Irql = OldIrql; > > @@ -749,10 +756,10 @@ > { > /* Check for pending software interrupts and compare with current IRQL */ > PendingIrqlMask = Pcr->IRR & FindHigherIrqlMask[OldIrql]; > - if (!PendingIrqlMask) return; > + if (!PendingIrqlMask) return NULL; > > /* Check for in-service delayed interrupt */ > - if (Pcr->IrrActive & 0xFFFFFFF0) return; > + if (Pcr->IrrActive & 0xFFFFFFF0) return NULL; > > /* Check if pending IRQL affects hardware state */ > BitScanReverse(&PendingIrql, PendingIrqlMask); > @@ -777,10 +784,11 @@ > else > { > /* No need to loop checking for hardware interrupts */ > - SWInterruptHandlerTable2[PendingIrql](TrapFrame); > - UNREACHABLE; > + return SWInterruptHandlerTable2[PendingIrql]; > } > } > + > + return NULL; > } > > /* EDGE INTERRUPT DISMISSAL FUNCTIONS *****************************************/ > > >

8 years, 11 months

1
0
0 0

Abuse filter bans legit users and ignores spamers

by Alexander Rechitskiy

8 years, 11 months

1
0
0 0

https://code.reactos.org/ is down

by Alexander Rechitskiy

8 years, 11 months

2
1
0 0

CAPCHA does not work

by Alexander Rechitskiy

8 years, 11 months

2
1
0 0

Build Crash ProgMan

by James Tabor

Linux build, on all my systems, Slackware, Fedora,,,,, Building C object base/shell/progman/progman_pch.h.gch FAILED: /usr/local/RosBE/i386/bin/i686-w64-mingw32-gcc -DDBG=1 -DKDBG=1 -DUNICODE -DUSE_COMPILER_EXCEPTIONS -DWINVER=0x502 -D_DLL -D_M_IX86 -D_SEH_ENABLE_TRACE -D_SETUPAPI_VER=0x502 -D_UNICODE -D_USE_32BIT_TIME_T -D_USE_PSEH3=1 -D_WIN32_IE=0x600 -D_WIN32_WINDOWS=0x502 -D_WIN32_WINNT=0x502 -D_X86_ -D__REACTOS__ -D__USE_CRTIMP -D__i386__ -D_inline=__inline -Di386 -Wa,--compress-debug-sections -pipe -fms-extensions -fno-strict-aliasing -nostdinc -mstackrealign -Wold-style-declaration -Wdeclaration-after-statement -fdebug-prefix-map="/home/ros/reactos"=ReactOS -gdwarf-2 -gstrict-dwarf -femit-struct-debug-detailed=none -feliminate-unused-debug-symbols -march=pentium -mtune=i686 -Werror -Wall -Wpointer-arith -Wno-char-subscripts -Wno-multichar -Wno-unused-value -Wno-maybe-uninitialized -O1 -fno-optimize-sibling-calls -fno-omit-frame-pointer -mpreferred-stack-boundary=3 -fno-set-stack-executable -Winvalid-pch -Werror=invalid-pch -Ibase/shell/progman -I../../base/shell/progman -I../../sdk/include -I../../sdk/include/psdk -I../../sdk/include/dxsdk -Isdk/include -Isdk/include/psdk -Isdk/include/dxsdk -Isdk/include/ddk -Isdk/include/reactos -I../../sdk/include/crt -I../../sdk/include/ddk -I../../sdk/include/ndk -I../../sdk/include/reactos -I../../sdk/include/reactos/libs -MMD -MT base/shell/progman/progman_pch.h.gch -MF base/shell/progman/progman_pch.h.gch.d -o base/shell/progman/progman_pch.h.gch -c ../../base/shell/progman/progman.h ../../base/shell/progman/progman.h:35:9: error: #pragma once in main file [-Werror] cc1: all warnings being treated as errors [206/1104] Linking C executable base/shell/cmd/cmd.exe ninja: build stopped: subcommand failed.

8 years, 11 months

1
0
0 0

Spam attack, continuing... (episode 12345/infinity)

by Hermès BÉLUSCA - MAÏTO

So, guys, ... We are yet again subject to a spam attack on the forums AND in the wiki (since yesterday for the latter), but nothing was done yet !! https://reactos.org/forum/ https://reactos.org/wiki/Special:RecentChanges For the wiki, the abuse filter hasn't blocked everything !! Regards, Hermès

8 years, 11 months

1
0
0 0

Google Summer of Code

by Zuodian Hu

Dear ReactOS I am zhu48 from the GSoC, on the network driver project. I'm sorry I am sending this email out so late after the start of the official bonding period. I am going into finals week and I had some trouble getting the mailing list to work. Hello everybody! Zuodian Hu

8 years, 11 months

2
1
0 0

Greetings from GSoC student!

by Aman Priyadarshi

Hello ROS community! My name is Aman Priyadarshi, undergraduate from India. It's a bit late but I would like to thank you all the members of this community who helped me to figure out things, helped me in setting up my build environment and finishing up my GSoC Proposal. It is really great opportunity for me to get selected and prove myself. You people can be sure that I'll put my best. *Project Proposed:* My project is to write "AHCI controller interface and hence ATA/ATAPI driver for windows 2003 targeting NT 5.0" which I later port to ROS. I have started investigation of NT programming concepts and storage class structure. I hope I would able to meet expectation of community. *My Background: *I am a enthusiastic programmer, core languages are C#, C/C++, x86 Assembly. my field of interest includes hardware programming, algorithms (+ optimizations) and Machine Learning. In free time I love to work on my own project Atom OS, It's an multitasking monolithic kernel based operating system that I have written from scratch in C# targeting x86 arch. I also love competitive coding (codechef.com <https://www.codechef.com/users/amaneureka>) and tiny machine Learning project (mainly classification based). I would really like to continue being a developer at ROS community after GSoC project. Greetings *Aman Priyadarshi* *www.atomixos.com <http://www.atomixos.com>* ᐧ

8 years, 11 months

3
2
0 0

WinDbg protocol for debugging, PDB implementation

by Антон Кочков

Hello Everyone! After I saw an article mentioning you're using WinDbg for debugging, I thought that information below could be interesting for you: We (radare2 project) have developed our own implementation of both GDB and WinDbg protocol parsers as a separate libraries in pure C and without hard dependencies of external libraries. Here you can find our WinDbg protocol implementation https://github.com/radare/radare2/tree/master/shlr/wind And here you can find our PDB parser https://github.com/radare/radare2/tree/master/libr/bin/pdb This is how to use radare2 for connecting to WinDbg server https://github.com/radare/radare2/blob/master/doc/windbg And here is how to use radare2 for parsing PDB files https://github.com/radare/radare2/blob/master/doc/pdb/pdb_usage Our goal is to write complete implementations of WinDbg and PDB, both platform independent and working everywhere. If you're interested on joining forces for that - feel free to answer this email or join us in Telegram or IRC - "#radare" on both. I hope this would be useful for someone. Kind regards, Anton Kochkov.

8 years, 11 months

1
0
0 0

Web Developer

by dd

Hello guys, My name is Federico Montanari and I am a student. I am from Italy and I hope to join to ReactOS Team as web developer. My skills: - English and Italian Languages - HTML and CSS (I'm learning Drupal) - Base of C (Not WIN32 API) Timezone: UTC +1 ReactOS Account name: decodp ReactOS IRC name: decodp What Can I do here? I can write some articles about ReactOS Status or something, fix online bugs and I can be moderator of forum and wiki to delete spam. This is my proposal. Have you got any idea? I ready to work on team (especially ReactOS Team) You are a great team! Thank you for your work on ReactOS (I wrote one program in C and.. it was difficult :p) With my greetings, Federico Montanari

8 years, 12 months

1
0
0 0

Greetings from GSoC student!

by mvardan

Hello ReactOS community! My name is Vardan. First of all I want to say thank you to all the members of this community who helped me to figure out status of works and make a proposal for GSoC. Also I want to express my gratitude to those who makes decision to accept my proposal. It is very responsible for me to be accepted for this project. You can be sure that I'll do my best to be able to meet your expectations. For all other members of ReactOS community, I want to introduce myself. I am 1st year master student from Armenia. I have about 2 years of Linux Driver development experience. My GSoC project title is "Improve ReactOS USB stack" and I will be very grateful for any help from anyone of you. I can easily communicate on Russian and English. During this month after submission and before acceptance I have done some investigation of ReactOS and it's built environment. Related to RosBE I want to express separate thanks to them who created such environment where newbies like me are able to easily build and test ReactOS and it's drivers (even with MSVS!). ReactOS wiki page is also very helpful! I have started Investigation of NT driver concepts with "Microsoft Windows Internals" book and some online articles. Any recommendations related sources of information are strongly appreciated by me. I hope that this GSoC project will be a good starting point for me, to join to "very small and exclusive ranks of people who know how to do NT systems development" :) Best regards, Vardan.

8 years, 12 months

5
4
0 0

Re: [ros-dev] [ros-diffs] [akhaldi] 71183: [CLASSPNP] Fix MSVC build. Brought to you by Timo.

by Alex Ionescu

Thomas, the standard says: "If one of the strings has an encoding prefix and the other doesn't, the one that doesn't will be considered to have the same encoding prefix as the other." In other words, this now sends a wide-string to ASSERTMSG. Which is wrong. Best regards, Alex Ionescu On Sun, Apr 24, 2016 at 5:14 AM, Thomas Faber <thomas.faber(a)reactos.org> wrote: > On 2016-04-20 14:16, akhaldi(a)svn.reactos.org wrote: >> [CLASSPNP] Fix MSVC build. Brought to you by Timo. > >> --- trunk/reactos/drivers/storage/classpnp/class.c [iso-8859-1] (original) >> +++ trunk/reactos/drivers/storage/classpnp/class.c [iso-8859-1] Wed Apr 20 12:16:16 2016 >> @@ -877,7 +877,7 @@ >> status = devInfo->ClassStopDevice(DeviceObject, IRP_MN_STOP_DEVICE); >> >> ASSERTMSG("ClassDispatchPnp !! STOP_DEVICE should " >> - "never be failed\n", NT_SUCCESS(status)); >> + L"never be failed\n", NT_SUCCESS(status)); >> >> if(isFdo) { >> status = ClassForwardIrpSynchronous(commonExtension, Irp); >> > > This makes no sense to me at all. You're now concatenating a narrow and > a wide string (which should be an error, but compilers suck), and > passing it to a macro that calls RtlAssert -- which expects a narrow > string. > Am I missing something here? > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

8 years, 12 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [spetreolle] 71201: [CDMAKE] Don't check for extension length on Joliet images. Encountered with AHK binaries. ONLINE-567

by Pierre Schweitzer

Given there seems to be no place where s is checked for length, it would be more appropriated to perform such as check: if ((!joliet && strlen(s) > MAX_EXTENSION_LENGTH) || strlen(s) > MAX_NAME_LENGTH) Le 24/04/2016 20:59, spetreolle(a)svn.reactos.org a écrit : > Author: spetreolle > Date: Sun Apr 24 18:59:33 2016 > New Revision: 71201 > > URL: http://svn.reactos.org/svn/reactos?rev=71201&view=rev > Log: > [CDMAKE] > Don't check for extension length on Joliet images. > Encountered with AHK binaries. > > ONLINE-567 > > Modified: > trunk/reactos/sdk/tools/cdmake/cdmake.c > > Modified: trunk/reactos/sdk/tools/cdmake/cdmake.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/sdk/tools/cdmake/cdmake.c?… > ============================================================================== > --- trunk/reactos/sdk/tools/cdmake/cdmake.c [iso-8859-1] (original) > +++ trunk/reactos/sdk/tools/cdmake/cdmake.c [iso-8859-1] Sun Apr 24 18:59:33 2016 > @@ -692,7 +692,8 @@ > error_exit("'%s' is not ISO-9660, aborting...", filename); > s++; > } > - if (strlen(s) > MAX_EXTENSION_LENGTH) > + // Check for extension length > + if (!joliet && strlen(s) > MAX_EXTENSION_LENGTH) > { > error_exit("'%s' has too long extension, aborting...", filename); > } > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

8 years, 12 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [akhaldi] 71183: [CLASSPNP] Fix MSVC build. Brought to you by Timo.

by Thomas Faber

On 2016-04-20 14:16, akhaldi(a)svn.reactos.org wrote: > [CLASSPNP] Fix MSVC build. Brought to you by Timo. > --- trunk/reactos/drivers/storage/classpnp/class.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/storage/classpnp/class.c [iso-8859-1] Wed Apr 20 12:16:16 2016 > @@ -877,7 +877,7 @@ > status = devInfo->ClassStopDevice(DeviceObject, IRP_MN_STOP_DEVICE); > > ASSERTMSG("ClassDispatchPnp !! STOP_DEVICE should " > - "never be failed\n", NT_SUCCESS(status)); > + L"never be failed\n", NT_SUCCESS(status)); > > if(isFdo) { > status = ClassForwardIrpSynchronous(commonExtension, Irp); > This makes no sense to me at all. You're now concatenating a narrow and a wide string (which should be an error, but compilers suck), and passing it to a macro that calls RtlAssert -- which expects a narrow string. Am I missing something here?

8 years, 12 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [spetreolle] 71188: [NDIS] Silence a debug output. CORE-11137 #resolve

by Thomas Faber

On 2016-04-23 21:09, spetreolle(a)svn.reactos.org wrote: > [NDIS] > Silence a debug output. > CORE-11137 #resolve > --- trunk/reactos/drivers/network/ndis/ndis/protocol.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/network/ndis/ndis/protocol.c [iso-8859-1] Sat Apr 23 19:09:30 2016 > @@ -321,7 +321,7 @@ > PLOGICAL_ADAPTER Adapter; > PNDIS_REQUEST_MAC_BLOCK MacBlock = (PNDIS_REQUEST_MAC_BLOCK)NdisRequest->MacReserved; > > - NDIS_DbgPrint(MAX_TRACE, ("Called.\n")); > + NDIS_DbgPrint(MIN_TRACE, ("Called.\n")); > > ASSERT(MacBindingHandle); > AdapterBinding = GET_ADAPTER_BINDING(MacBindingHandle); This does not silence the trace. It does the opposite.

8 years, 12 months

1
0
0 0

Re: [ros-dev] ReactOS SVN Version Naming

by Alex Ionescu

Are you equally confused when Windows 10 Anniversary Update preview builds also present themselves as such, even though it'snot coming out until later? Best regards, Alex Ionescu On Wed, Apr 13, 2016 at 9:31 AM, Javier Agustìn Fernàndez Arroyo <elhoir(a)gmail.com> wrote: > what about changing "-" by "+"? > > "0.4+SVNx" > that would mean, "this is the 0.4. version, plus svn revisions until x" > > > On Sun, Apr 10, 2016 at 11:25 PM, Mark Jansen <learn0more+ros(a)gmail.com> > wrote: >> >> >> >> This way of numbering seems very confusing to me, and I assume to other >> people as well.. >> When ReactOS presents itself as 0.5-SVN, I would expect this to be a 0.5 >> release, and not a 0.4 release that is working towards a 0.5. >> >> >> regards, >> >> Mark >> >> >> PS: I wasn't subscribed at the time this was sent, so sending a 'fake' >> reply :) >> >> >>> Ged Murphy gedmurphy.maillists at gmail.com >>> Mon Feb 29 16:07:49 UTC 2016 >>> >>> Because that’s what is being worked towards now, and there will be an >>> unknown number of point releases until it’s reached. >>> >>> It’s also a bit of nostalgia, it’s what we’ve always done :) >>> >>> >>> >>>> From: Ros-dev [mailto:ros-dev-bounces at reactos.org] On Behalf Of >>>> Hermès >>>> BÉLUSCA - MAÏTO >>>> Sent: 29 February 2016 16:00 >>>> To: ReactOS Development List <ros-dev at reactos.org> >>>> Subject: [ros-dev] ReactOS SVN version naming >>>> >>>> Hi guys, >>>> >>>> I would like to understand what’s the rationale behind changing the >>>> ReactOS >>>> trunk version from “0.4-SVN” to “0.5-SVN” (see revision 70818) whereas >>>> we >>>> have just started to release ROS 0.4.0 only? >>>> >>>> Thanks in advance for your explanations! >>>> >>>> Cheers, >>>> Hermès. >> >> >> _______________________________________________ >> 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 >

9 years

3
2
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 60701: [NTOSKRNL] - Introduce a new and faster way to return to kernel mode from traps by using a ret 8 instruction instead of an iret. - Make use of KiUserTrap where appropriate - Remov...

by Alex Ionescu

Wait, are you suggesting that "doing things better than Microsoft" and "those idiots have no idea what they're doing" and "we shouldn't just be copying the instructions they use".... doesn't work? :O Best regards, Alex Ionescu On Thu, Apr 14, 2016 at 8:09 AM, Thomas Faber <thomas.faber(a)reactos.org> wrote: > Looks like we've encountered an issue with this > KiTrapReturnNoSegmentsRet8 approach. As seen in > https://jira.reactos.org/browse/CORE-11115, when a large number of > interrupts happen, this will cause us to run out of kernel stack. > > Since the popfd / ret 8 steps do not happen atomically, interrupts will > be re-enabled before those 12 bytes of stack are freed, thus many of > them happening in a row will cause us to run out. > > Thoughts? > > Thanks! > -Thomas > > > > On 2013-10-19 13:33, tkreuzer(a)svn.reactos.org wrote: >> Author: tkreuzer >> Date: Sat Oct 19 11:33:34 2013 >> New Revision: 60701 >> >> URL: http://svn.reactos.org/svn/reactos?rev=60701&view=rev >> Log: >> [NTOSKRNL] >> - Introduce a new and faster way to return to kernel mode from traps by using a ret 8 instruction instead of an iret. >> - Make use of KiUserTrap where appropriate >> - Remove some pointless toplevel volatile >> >> Modified: >> trunk/reactos/ntoskrnl/include/internal/i386/asmmacro.S >> trunk/reactos/ntoskrnl/include/internal/i386/ke.h >> trunk/reactos/ntoskrnl/include/internal/i386/trap_x.h >> trunk/reactos/ntoskrnl/ke/i386/cpu.c >> trunk/reactos/ntoskrnl/ke/i386/exp.c >> trunk/reactos/ntoskrnl/ke/i386/patpge.c >> trunk/reactos/ntoskrnl/ke/i386/trap.s >> trunk/reactos/ntoskrnl/ke/i386/traphdlr.c >> trunk/reactos/ntoskrnl/ke/i386/usercall.c >> trunk/reactos/ntoskrnl/ke/time.c >> >> 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] Sat Oct 19 11:33:34 2013 >> @@ -241,6 +241,7 @@ >> #define KI_EXIT_RET HEX(080) >> #define KI_EXIT_IRET HEX(100) >> #define KI_EDITED_FRAME HEX(200) >> +#define KI_EXIT_RET8 HEX(400) >> #define KI_RESTORE_VOLATILES (KI_RESTORE_EAX OR KI_RESTORE_ECX_EDX) >> >> MACRO(KiTrapExitStub, Name, Flags) >> @@ -248,15 +249,15 @@ >> PUBLIC @&Name&@4 >> @&Name&@4: >> >> - if (Flags AND KI_RESTORE_EFLAGS) >> + if (Flags AND KI_EXIT_RET8) OR (Flags AND KI_EXIT_IRET) >> + >> + /* This is the IRET frame */ >> + OffsetEsp = KTRAP_FRAME_EIP >> + >> + elseif (Flags AND KI_RESTORE_EFLAGS) >> >> /* We will pop EFlags off the stack */ >> OffsetEsp = KTRAP_FRAME_EFLAGS >> - >> - elseif (Flags AND KI_EXIT_IRET) >> - >> - /* This is the IRET frame */ >> - OffsetEsp = KTRAP_FRAME_EIP >> >> else >> >> @@ -335,6 +336,13 @@ >> >> if (Flags AND KI_RESTORE_EFLAGS) >> >> + if (Flags AND KI_EXIT_RET8) >> + >> + /* We are at the IRET frame, so push EFLAGS first */ >> + push dword ptr [esp + 8] >> + >> + endif >> + >> /* Restore EFLAGS */ >> popfd >> >> @@ -357,6 +365,11 @@ >> /* Return to kernel mode with a jmp */ >> jmp edx >> >> + elseif (Flags AND KI_EXIT_RET8) >> + >> + /* Return to kernel mode with a ret 8 */ >> + ret 8 >> + >> elseif (Flags AND KI_EXIT_RET) >> >> /* Return to kernel mode with a ret */ >> >> Modified: trunk/reactos/ntoskrnl/include/internal/i386/ke.h >> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… >> ============================================================================== >> --- trunk/reactos/ntoskrnl/include/internal/i386/ke.h [iso-8859-1] (original) >> +++ trunk/reactos/ntoskrnl/include/internal/i386/ke.h [iso-8859-1] Sat Oct 19 11:33:34 2013 >> @@ -383,13 +383,13 @@ >> ULONG_PTR >> NTAPI >> Ki386EnableGlobalPage( >> - IN volatile ULONG_PTR Context >> + IN ULONG_PTR Context >> ); >> >> ULONG_PTR >> NTAPI >> Ki386EnableTargetLargePage( >> - IN volatile ULONG_PTR Context >> + IN ULONG_PTR Context >> ); >> >> BOOLEAN >> >> Modified: trunk/reactos/ntoskrnl/include/internal/i386/trap_x.h >> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… >> ============================================================================== >> --- trunk/reactos/ntoskrnl/include/internal/i386/trap_x.h [iso-8859-1] (original) >> +++ trunk/reactos/ntoskrnl/include/internal/i386/trap_x.h [iso-8859-1] Sat Oct 19 11:33:34 2013 >> @@ -163,7 +163,7 @@ >> } >> >> /* Check DR values */ >> - if (TrapFrame->SegCs & MODE_MASK) >> + if (KiUserTrap(TrapFrame) >> { >> /* Check for active debugging */ >> if (KeGetCurrentThread()->Header.DebugActive) >> @@ -244,6 +244,7 @@ >> DECLSPEC_NORETURN VOID FASTCALL KiEditedTrapReturn(IN PKTRAP_FRAME TrapFrame); >> DECLSPEC_NORETURN VOID FASTCALL KiTrapReturn(IN PKTRAP_FRAME TrapFrame); >> DECLSPEC_NORETURN VOID FASTCALL KiTrapReturnNoSegments(IN PKTRAP_FRAME TrapFrame); >> +DECLSPEC_NORETURN VOID FASTCALL KiTrapReturnNoSegmentsRet8(IN PKTRAP_FRAME TrapFrame); >> >> typedef >> ATTRIB_NORETURN >> @@ -382,7 +383,7 @@ >> TrapFrame->Dr7 = 0; >> >> /* Check if the frame was from user mode or v86 mode */ >> - if ((TrapFrame->SegCs & MODE_MASK) || >> + if (KiUserTrap(TrapFrame) || >> (TrapFrame->EFlags & EFLAGS_V86_MASK)) >> { >> /* Check for active debugging */ >> @@ -411,7 +412,7 @@ >> TrapFrame->Dr7 = 0; >> >> /* Check if the frame was from user mode or v86 mode */ >> - if ((TrapFrame->SegCs & MODE_MASK) || >> + if (KiUserTrap(TrapFrame) || >> (TrapFrame->EFlags & EFLAGS_V86_MASK)) >> { >> /* Check for active debugging */ >> >> Modified: trunk/reactos/ntoskrnl/ke/i386/cpu.c >> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/cpu.c?rev… >> ============================================================================== >> --- trunk/reactos/ntoskrnl/ke/i386/cpu.c [iso-8859-1] (original) >> +++ trunk/reactos/ntoskrnl/ke/i386/cpu.c [iso-8859-1] Sat Oct 19 11:33:34 2013 >> @@ -1535,7 +1535,7 @@ >> if (TargetAffinity) >> { >> /* Sanity check */ >> - ASSERT(Prcb == (volatile PKPRCB)KeGetCurrentPrcb()); >> + ASSERT(Prcb == KeGetCurrentPrcb()); >> >> /* FIXME: TODO */ >> ASSERTMSG("Not yet implemented\n", FALSE); >> >> Modified: trunk/reactos/ntoskrnl/ke/i386/exp.c >> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/exp.c?rev… >> ============================================================================== >> --- trunk/reactos/ntoskrnl/ke/i386/exp.c [iso-8859-1] (original) >> +++ trunk/reactos/ntoskrnl/ke/i386/exp.c [iso-8859-1] Sat Oct 19 11:33:34 2013 >> @@ -137,7 +137,7 @@ >> KiEspFromTrapFrame(IN PKTRAP_FRAME TrapFrame) >> { >> /* Check if this is user-mode or V86 */ >> - if ((TrapFrame->SegCs & MODE_MASK) || >> + if (KiUserTrap(TrapFrame) || >> (TrapFrame->EFlags & EFLAGS_V86_MASK)) >> { >> /* Return it directly */ >> @@ -175,7 +175,7 @@ >> Previous = KiEspFromTrapFrame(TrapFrame); >> >> /* Check if this is user-mode or V86 */ >> - if ((TrapFrame->SegCs & MODE_MASK) || >> + if (KiUserTrap(TrapFrame) || >> (TrapFrame->EFlags & EFLAGS_V86_MASK)) >> { >> /* Write it directly */ >> @@ -225,7 +225,7 @@ >> /* Just return it */ >> return TrapFrame->HardwareSegSs; >> } >> - else if (TrapFrame->SegCs & MODE_MASK) >> + else if (KiUserTrap(TrapFrame)) >> { >> /* User mode, return the User SS */ >> return TrapFrame->HardwareSegSs | RPL_MASK; >> @@ -251,7 +251,7 @@ >> /* Just write it */ >> TrapFrame->HardwareSegSs = Ss; >> } >> - else if (TrapFrame->SegCs & MODE_MASK) >> + else if (KiUserTrap(TrapFrame)) >> { >> /* Usermode, save the User SS */ >> TrapFrame->HardwareSegSs = Ss | RPL_MASK; >> @@ -398,7 +398,7 @@ >> TrapFrame->V86Fs = Context->SegFs; >> TrapFrame->V86Gs = Context->SegGs; >> } >> - else if (!(TrapFrame->SegCs & MODE_MASK)) >> + else if (!KiUserTrap(TrapFrame)) >> { >> /* For kernel mode, write the standard values */ >> TrapFrame->SegDs = KGDT_R3_DATA | RPL_MASK; >> @@ -429,7 +429,7 @@ >> >> /* Handle the extended registers */ >> if (((ContextFlags & CONTEXT_EXTENDED_REGISTERS) == >> - CONTEXT_EXTENDED_REGISTERS) && (TrapFrame->SegCs & MODE_MASK)) >> + CONTEXT_EXTENDED_REGISTERS) && KiUserTrap(TrapFrame)) >> { >> /* Get the FX Area */ >> FxSaveArea = (PFX_SAVE_AREA)(TrapFrame + 1); >> @@ -463,7 +463,7 @@ >> >> /* Handle the floating point state */ >> if (((ContextFlags & CONTEXT_FLOATING_POINT) == >> - CONTEXT_FLOATING_POINT) && (TrapFrame->SegCs & MODE_MASK)) >> + CONTEXT_FLOATING_POINT) && KiUserTrap(TrapFrame)) >> { >> /* Get the FX Area */ >> FxSaveArea = (PFX_SAVE_AREA)(TrapFrame + 1); >> @@ -692,7 +692,7 @@ >> >> /* Handle extended registers */ >> if (((Context->ContextFlags & CONTEXT_EXTENDED_REGISTERS) == >> - CONTEXT_EXTENDED_REGISTERS) && (TrapFrame->SegCs & MODE_MASK)) >> + CONTEXT_EXTENDED_REGISTERS) && KiUserTrap(TrapFrame)) >> { >> /* Get the FX Save Area */ >> FxSaveArea = (PFX_SAVE_AREA)(TrapFrame + 1); >> @@ -712,7 +712,7 @@ >> >> /* Handle Floating Point */ >> if (((Context->ContextFlags & CONTEXT_FLOATING_POINT) == >> - CONTEXT_FLOATING_POINT) && (TrapFrame->SegCs & MODE_MASK)) >> + CONTEXT_FLOATING_POINT) && KiUserTrap(TrapFrame)) >> { >> /* Get the FX Save Area */ >> FxSaveArea = (PFX_SAVE_AREA)(TrapFrame + 1); >> @@ -1045,6 +1045,13 @@ >> } >> } >> _SEH2_END; >> + >> + DPRINT("First chance exception in %.16s, ExceptionCode: %lx, ExceptionAddress: %p, P0: %lx, P1: %lx\n", >> + PsGetCurrentProcess()->ImageFileName, >> + ExceptionRecord->ExceptionCode, >> + ExceptionRecord->ExceptionAddress, >> + ExceptionRecord->ExceptionInformation[0], >> + ExceptionRecord->ExceptionInformation[1]); >> } >> >> /* Try second chance */ >> @@ -1060,11 +1067,13 @@ >> } >> >> /* 3rd strike, kill the process */ >> - DPRINT1("Kill %.16s, ExceptionCode: %lx, ExceptionAddress: %p, BaseAddress: %p\n", >> + DPRINT1("Kill %.16s, ExceptionCode: %lx, ExceptionAddress: %p, BaseAddress: %p, P0: %lx, P1: %lx\n", >> PsGetCurrentProcess()->ImageFileName, >> ExceptionRecord->ExceptionCode, >> ExceptionRecord->ExceptionAddress, >> - PsGetCurrentProcess()->SectionBaseAddress); >> + PsGetCurrentProcess()->SectionBaseAddress, >> + ExceptionRecord->ExceptionInformation[0], >> + ExceptionRecord->ExceptionInformation[1]); >> >> ZwTerminateProcess(NtCurrentProcess(), ExceptionRecord->ExceptionCode); >> KeBugCheckEx(KMODE_EXCEPTION_NOT_HANDLED, >> >> Modified: trunk/reactos/ntoskrnl/ke/i386/patpge.c >> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/patpge.c?… >> ============================================================================== >> --- trunk/reactos/ntoskrnl/ke/i386/patpge.c [iso-8859-1] (original) >> +++ trunk/reactos/ntoskrnl/ke/i386/patpge.c [iso-8859-1] Sat Oct 19 11:33:34 2013 >> @@ -20,9 +20,9 @@ >> ULONG_PTR >> NTAPI >> INIT_FUNCTION >> -Ki386EnableGlobalPage(IN volatile ULONG_PTR Context) >> -{ >> - volatile PLONG Count = (PLONG)Context; >> +Ki386EnableGlobalPage(IN ULONG_PTR Context) >> +{ >> + PLONG Count = (PLONG)Context; >> ULONG Cr4, Cr3; >> >> /* Disable interrupts */ >> @@ -144,7 +144,7 @@ >> if (PageTable) >> *PageTable = (PHARDWARE_PTE)(Pde->PageFrameNumber << PAGE_SHIFT); >> } >> - >> + >> return TRUE; >> } >> >> @@ -172,7 +172,7 @@ >> /* Get PTE of VirtualPtr, make it valid, and map PhysicalPtr there */ >> Pte = &PageTable[(VirtualPtr >> 12) & ((1 << PTE_BITS) - 1)]; >> Pte->Valid = 1; >> - Pte->PageFrameNumber = PhysicalPtr.QuadPart >> PAGE_SHIFT; >> + Pte->PageFrameNumber = (PFN_NUMBER)(PhysicalPtr.QuadPart >> PAGE_SHIFT); >> >> return TRUE; >> } >> @@ -189,7 +189,7 @@ >> PhysicalPtr = MmGetPhysicalAddress(VirtualPtr); >> >> /* Map its physical address in the page table provided by the caller */ >> - Pte->PageFrameNumber = PhysicalPtr.QuadPart >> PAGE_SHIFT; >> + Pte->PageFrameNumber = (PFN_NUMBER)(PhysicalPtr.QuadPart >> PAGE_SHIFT); >> } >> >> BOOLEAN >> >> 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] Sat Oct 19 11:33:34 2013 >> @@ -166,6 +166,7 @@ >> KiTrapExitStub KiEditedTrapReturn, (KI_RESTORE_VOLATILES OR KI_RESTORE_EFLAGS OR KI_EDITED_FRAME OR KI_EXIT_RET) >> KiTrapExitStub KiTrapReturn, (KI_RESTORE_VOLATILES OR KI_RESTORE_SEGMENTS OR KI_EXIT_IRET) >> KiTrapExitStub KiTrapReturnNoSegments, (KI_RESTORE_VOLATILES OR KI_EXIT_IRET) >> +KiTrapExitStub KiTrapReturnNoSegmentsRet8,(KI_RESTORE_VOLATILES OR KI_RESTORE_EFLAGS OR KI_EXIT_RET8) >> >> #ifdef _MSC_VER >> EXTERN _PsConvertToGuiThread@0:PROC >> >> 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] Sat Oct 19 11:33:34 2013 >> @@ -100,7 +100,7 @@ >> if (__builtin_expect(TrapFrame->Dr7 & ~DR7_RESERVED_MASK, 0)) >> { >> /* Check if the frame was from user mode or v86 mode */ >> - if ((TrapFrame->SegCs & MODE_MASK) || >> + if (KiUserTrap(TrapFrame) || >> (TrapFrame->EFlags & EFLAGS_V86_MASK)) >> { >> /* Handle debug registers */ >> @@ -124,13 +124,13 @@ >> if (TrapFrame->EFlags & EFLAGS_V86_MASK) KiTrapReturnNoSegments(TrapFrame); >> >> /* Check for user mode exit */ >> - if (TrapFrame->SegCs & MODE_MASK) KiTrapReturn(TrapFrame); >> + if (KiUserTrap(TrapFrame)) KiTrapReturn(TrapFrame); >> >> /* Check for edited frame */ >> if (KiIsFrameEdited(TrapFrame)) KiEditedTrapReturn(TrapFrame); >> >> /* Exit the trap to kernel mode */ >> - KiTrapReturnNoSegments(TrapFrame); >> + KiTrapReturnNoSegmentsRet8(TrapFrame); >> } >> >> DECLSPEC_NORETURN >> @@ -152,7 +152,7 @@ >> KeGetCurrentThread()->PreviousMode = (CCHAR)TrapFrame->PreviousPreviousMode; >> >> /* Check for user mode exit */ >> - if (TrapFrame->SegCs & MODE_MASK) >> + if (KiUserTrap(TrapFrame)) >> { >> /* Check if we were single stepping */ >> if (TrapFrame->EFlags & EFLAGS_TF) >> @@ -186,13 +186,13 @@ >> if (TrapFrame->EFlags & EFLAGS_V86_MASK) KiTrapReturnNoSegments(TrapFrame); >> >> /* Check for user mode exit */ >> - if (TrapFrame->SegCs & MODE_MASK) KiTrapReturn(TrapFrame); >> + if (KiUserTrap(TrapFrame)) KiTrapReturn(TrapFrame); >> >> /* Check for edited frame */ >> if (KiIsFrameEdited(TrapFrame)) KiEditedTrapReturn(TrapFrame); >> >> /* Exit the trap to kernel mode */ >> - KiTrapReturnNoSegments(TrapFrame); >> + KiTrapReturnNoSegmentsRet8(TrapFrame); >> } >> >> >> @@ -1250,10 +1250,10 @@ >> /* Call the access fault handler */ >> Status = MmAccessFault(TrapFrame->ErrCode & 1, >> (PVOID)Cr2, >> - TrapFrame->SegCs & MODE_MASK, >> + KiUserTrap(TrapFrame), >> TrapFrame); >> if (NT_SUCCESS(Status)) KiEoiHelper(TrapFrame); >> - >> + >> /* Check for syscall fault */ >> #if 0 >> if ((TrapFrame->Eip == (ULONG_PTR)CopyParams) || >> @@ -1541,7 +1541,7 @@ >> TrapFrame->Dr7 = 0; >> >> /* Check if the frame was from user mode */ >> - if (TrapFrame->SegCs & MODE_MASK) >> + if (KiUserTrap(TrapFrame)) >> { >> /* Check for active debugging */ >> if (KeGetCurrentThread()->Header.DebugActive & 0xFF) >> >> Modified: trunk/reactos/ntoskrnl/ke/i386/usercall.c >> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/usercall.… >> ============================================================================== >> --- trunk/reactos/ntoskrnl/ke/i386/usercall.c [iso-8859-1] (original) >> +++ trunk/reactos/ntoskrnl/ke/i386/usercall.c [iso-8859-1] Sat Oct 19 11:33:34 2013 >> @@ -67,7 +67,7 @@ >> _SEH2_TRY >> { >> /* Sanity check */ >> - ASSERT((TrapFrame->SegCs & MODE_MASK) != KernelMode); >> + ASSERT(KiUserTrap(TrapFrame)); >> >> /* Get the aligned size */ >> AlignedEsp = Context.Esp & ~3; >> @@ -210,7 +210,7 @@ >> } >> >> >> -/* >> +/* >> * Stack layout for KiUserModeCallout: >> * ---------------------------------- >> * KCALLOUT_FRAME.ResultLength <= 2nd Parameter to KiCallUserMode >> >> Modified: trunk/reactos/ntoskrnl/ke/time.c >> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/time.c?rev=607… >> ============================================================================== >> --- trunk/reactos/ntoskrnl/ke/time.c [iso-8859-1] (original) >> +++ trunk/reactos/ntoskrnl/ke/time.c [iso-8859-1] Sat Oct 19 11:33:34 2013 >> @@ -153,7 +153,7 @@ >> >> /* Check if we came from user mode */ >> #ifndef _M_ARM >> - if ((TrapFrame->SegCs & MODE_MASK) || (TrapFrame->EFlags & EFLAGS_V86_MASK)) >> + if (KiUserTrap(TrapFrame) || (TrapFrame->EFlags & EFLAGS_V86_MASK)) >> #else >> if (TrapFrame->PreviousMode == UserMode) >> #endif >> >> > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

9 years

1
0
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 60701: [NTOSKRNL] - Introduce a new and faster way to return to kernel mode from traps by using a ret 8 instruction instead of an iret. - Make use of KiUserTrap where appropriate - Remov...

by Thomas Faber

Looks like we've encountered an issue with this KiTrapReturnNoSegmentsRet8 approach. As seen in https://jira.reactos.org/browse/CORE-11115, when a large number of interrupts happen, this will cause us to run out of kernel stack. Since the popfd / ret 8 steps do not happen atomically, interrupts will be re-enabled before those 12 bytes of stack are freed, thus many of them happening in a row will cause us to run out. Thoughts? Thanks! -Thomas On 2013-10-19 13:33, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Sat Oct 19 11:33:34 2013 > New Revision: 60701 > > URL: http://svn.reactos.org/svn/reactos?rev=60701&view=rev > Log: > [NTOSKRNL] > - Introduce a new and faster way to return to kernel mode from traps by using a ret 8 instruction instead of an iret. > - Make use of KiUserTrap where appropriate > - Remove some pointless toplevel volatile > > Modified: > trunk/reactos/ntoskrnl/include/internal/i386/asmmacro.S > trunk/reactos/ntoskrnl/include/internal/i386/ke.h > trunk/reactos/ntoskrnl/include/internal/i386/trap_x.h > trunk/reactos/ntoskrnl/ke/i386/cpu.c > trunk/reactos/ntoskrnl/ke/i386/exp.c > trunk/reactos/ntoskrnl/ke/i386/patpge.c > trunk/reactos/ntoskrnl/ke/i386/trap.s > trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > trunk/reactos/ntoskrnl/ke/i386/usercall.c > trunk/reactos/ntoskrnl/ke/time.c > > 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] Sat Oct 19 11:33:34 2013 > @@ -241,6 +241,7 @@ > #define KI_EXIT_RET HEX(080) > #define KI_EXIT_IRET HEX(100) > #define KI_EDITED_FRAME HEX(200) > +#define KI_EXIT_RET8 HEX(400) > #define KI_RESTORE_VOLATILES (KI_RESTORE_EAX OR KI_RESTORE_ECX_EDX) > > MACRO(KiTrapExitStub, Name, Flags) > @@ -248,15 +249,15 @@ > PUBLIC @&Name&@4 > @&Name&@4: > > - if (Flags AND KI_RESTORE_EFLAGS) > + if (Flags AND KI_EXIT_RET8) OR (Flags AND KI_EXIT_IRET) > + > + /* This is the IRET frame */ > + OffsetEsp = KTRAP_FRAME_EIP > + > + elseif (Flags AND KI_RESTORE_EFLAGS) > > /* We will pop EFlags off the stack */ > OffsetEsp = KTRAP_FRAME_EFLAGS > - > - elseif (Flags AND KI_EXIT_IRET) > - > - /* This is the IRET frame */ > - OffsetEsp = KTRAP_FRAME_EIP > > else > > @@ -335,6 +336,13 @@ > > if (Flags AND KI_RESTORE_EFLAGS) > > + if (Flags AND KI_EXIT_RET8) > + > + /* We are at the IRET frame, so push EFLAGS first */ > + push dword ptr [esp + 8] > + > + endif > + > /* Restore EFLAGS */ > popfd > > @@ -357,6 +365,11 @@ > /* Return to kernel mode with a jmp */ > jmp edx > > + elseif (Flags AND KI_EXIT_RET8) > + > + /* Return to kernel mode with a ret 8 */ > + ret 8 > + > elseif (Flags AND KI_EXIT_RET) > > /* Return to kernel mode with a ret */ > > Modified: trunk/reactos/ntoskrnl/include/internal/i386/ke.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/i386/ke.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/i386/ke.h [iso-8859-1] Sat Oct 19 11:33:34 2013 > @@ -383,13 +383,13 @@ > ULONG_PTR > NTAPI > Ki386EnableGlobalPage( > - IN volatile ULONG_PTR Context > + IN ULONG_PTR Context > ); > > ULONG_PTR > NTAPI > Ki386EnableTargetLargePage( > - IN volatile ULONG_PTR Context > + IN ULONG_PTR Context > ); > > BOOLEAN > > Modified: trunk/reactos/ntoskrnl/include/internal/i386/trap_x.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/i386/trap_x.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/i386/trap_x.h [iso-8859-1] Sat Oct 19 11:33:34 2013 > @@ -163,7 +163,7 @@ > } > > /* Check DR values */ > - if (TrapFrame->SegCs & MODE_MASK) > + if (KiUserTrap(TrapFrame) > { > /* Check for active debugging */ > if (KeGetCurrentThread()->Header.DebugActive) > @@ -244,6 +244,7 @@ > DECLSPEC_NORETURN VOID FASTCALL KiEditedTrapReturn(IN PKTRAP_FRAME TrapFrame); > DECLSPEC_NORETURN VOID FASTCALL KiTrapReturn(IN PKTRAP_FRAME TrapFrame); > DECLSPEC_NORETURN VOID FASTCALL KiTrapReturnNoSegments(IN PKTRAP_FRAME TrapFrame); > +DECLSPEC_NORETURN VOID FASTCALL KiTrapReturnNoSegmentsRet8(IN PKTRAP_FRAME TrapFrame); > > typedef > ATTRIB_NORETURN > @@ -382,7 +383,7 @@ > TrapFrame->Dr7 = 0; > > /* Check if the frame was from user mode or v86 mode */ > - if ((TrapFrame->SegCs & MODE_MASK) || > + if (KiUserTrap(TrapFrame) || > (TrapFrame->EFlags & EFLAGS_V86_MASK)) > { > /* Check for active debugging */ > @@ -411,7 +412,7 @@ > TrapFrame->Dr7 = 0; > > /* Check if the frame was from user mode or v86 mode */ > - if ((TrapFrame->SegCs & MODE_MASK) || > + if (KiUserTrap(TrapFrame) || > (TrapFrame->EFlags & EFLAGS_V86_MASK)) > { > /* Check for active debugging */ > > Modified: trunk/reactos/ntoskrnl/ke/i386/cpu.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/cpu.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/cpu.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/cpu.c [iso-8859-1] Sat Oct 19 11:33:34 2013 > @@ -1535,7 +1535,7 @@ > if (TargetAffinity) > { > /* Sanity check */ > - ASSERT(Prcb == (volatile PKPRCB)KeGetCurrentPrcb()); > + ASSERT(Prcb == KeGetCurrentPrcb()); > > /* FIXME: TODO */ > ASSERTMSG("Not yet implemented\n", FALSE); > > Modified: trunk/reactos/ntoskrnl/ke/i386/exp.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/exp.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/exp.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/exp.c [iso-8859-1] Sat Oct 19 11:33:34 2013 > @@ -137,7 +137,7 @@ > KiEspFromTrapFrame(IN PKTRAP_FRAME TrapFrame) > { > /* Check if this is user-mode or V86 */ > - if ((TrapFrame->SegCs & MODE_MASK) || > + if (KiUserTrap(TrapFrame) || > (TrapFrame->EFlags & EFLAGS_V86_MASK)) > { > /* Return it directly */ > @@ -175,7 +175,7 @@ > Previous = KiEspFromTrapFrame(TrapFrame); > > /* Check if this is user-mode or V86 */ > - if ((TrapFrame->SegCs & MODE_MASK) || > + if (KiUserTrap(TrapFrame) || > (TrapFrame->EFlags & EFLAGS_V86_MASK)) > { > /* Write it directly */ > @@ -225,7 +225,7 @@ > /* Just return it */ > return TrapFrame->HardwareSegSs; > } > - else if (TrapFrame->SegCs & MODE_MASK) > + else if (KiUserTrap(TrapFrame)) > { > /* User mode, return the User SS */ > return TrapFrame->HardwareSegSs | RPL_MASK; > @@ -251,7 +251,7 @@ > /* Just write it */ > TrapFrame->HardwareSegSs = Ss; > } > - else if (TrapFrame->SegCs & MODE_MASK) > + else if (KiUserTrap(TrapFrame)) > { > /* Usermode, save the User SS */ > TrapFrame->HardwareSegSs = Ss | RPL_MASK; > @@ -398,7 +398,7 @@ > TrapFrame->V86Fs = Context->SegFs; > TrapFrame->V86Gs = Context->SegGs; > } > - else if (!(TrapFrame->SegCs & MODE_MASK)) > + else if (!KiUserTrap(TrapFrame)) > { > /* For kernel mode, write the standard values */ > TrapFrame->SegDs = KGDT_R3_DATA | RPL_MASK; > @@ -429,7 +429,7 @@ > > /* Handle the extended registers */ > if (((ContextFlags & CONTEXT_EXTENDED_REGISTERS) == > - CONTEXT_EXTENDED_REGISTERS) && (TrapFrame->SegCs & MODE_MASK)) > + CONTEXT_EXTENDED_REGISTERS) && KiUserTrap(TrapFrame)) > { > /* Get the FX Area */ > FxSaveArea = (PFX_SAVE_AREA)(TrapFrame + 1); > @@ -463,7 +463,7 @@ > > /* Handle the floating point state */ > if (((ContextFlags & CONTEXT_FLOATING_POINT) == > - CONTEXT_FLOATING_POINT) && (TrapFrame->SegCs & MODE_MASK)) > + CONTEXT_FLOATING_POINT) && KiUserTrap(TrapFrame)) > { > /* Get the FX Area */ > FxSaveArea = (PFX_SAVE_AREA)(TrapFrame + 1); > @@ -692,7 +692,7 @@ > > /* Handle extended registers */ > if (((Context->ContextFlags & CONTEXT_EXTENDED_REGISTERS) == > - CONTEXT_EXTENDED_REGISTERS) && (TrapFrame->SegCs & MODE_MASK)) > + CONTEXT_EXTENDED_REGISTERS) && KiUserTrap(TrapFrame)) > { > /* Get the FX Save Area */ > FxSaveArea = (PFX_SAVE_AREA)(TrapFrame + 1); > @@ -712,7 +712,7 @@ > > /* Handle Floating Point */ > if (((Context->ContextFlags & CONTEXT_FLOATING_POINT) == > - CONTEXT_FLOATING_POINT) && (TrapFrame->SegCs & MODE_MASK)) > + CONTEXT_FLOATING_POINT) && KiUserTrap(TrapFrame)) > { > /* Get the FX Save Area */ > FxSaveArea = (PFX_SAVE_AREA)(TrapFrame + 1); > @@ -1045,6 +1045,13 @@ > } > } > _SEH2_END; > + > + DPRINT("First chance exception in %.16s, ExceptionCode: %lx, ExceptionAddress: %p, P0: %lx, P1: %lx\n", > + PsGetCurrentProcess()->ImageFileName, > + ExceptionRecord->ExceptionCode, > + ExceptionRecord->ExceptionAddress, > + ExceptionRecord->ExceptionInformation[0], > + ExceptionRecord->ExceptionInformation[1]); > } > > /* Try second chance */ > @@ -1060,11 +1067,13 @@ > } > > /* 3rd strike, kill the process */ > - DPRINT1("Kill %.16s, ExceptionCode: %lx, ExceptionAddress: %p, BaseAddress: %p\n", > + DPRINT1("Kill %.16s, ExceptionCode: %lx, ExceptionAddress: %p, BaseAddress: %p, P0: %lx, P1: %lx\n", > PsGetCurrentProcess()->ImageFileName, > ExceptionRecord->ExceptionCode, > ExceptionRecord->ExceptionAddress, > - PsGetCurrentProcess()->SectionBaseAddress); > + PsGetCurrentProcess()->SectionBaseAddress, > + ExceptionRecord->ExceptionInformation[0], > + ExceptionRecord->ExceptionInformation[1]); > > ZwTerminateProcess(NtCurrentProcess(), ExceptionRecord->ExceptionCode); > KeBugCheckEx(KMODE_EXCEPTION_NOT_HANDLED, > > Modified: trunk/reactos/ntoskrnl/ke/i386/patpge.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/patpge.c?… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/patpge.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/patpge.c [iso-8859-1] Sat Oct 19 11:33:34 2013 > @@ -20,9 +20,9 @@ > ULONG_PTR > NTAPI > INIT_FUNCTION > -Ki386EnableGlobalPage(IN volatile ULONG_PTR Context) > -{ > - volatile PLONG Count = (PLONG)Context; > +Ki386EnableGlobalPage(IN ULONG_PTR Context) > +{ > + PLONG Count = (PLONG)Context; > ULONG Cr4, Cr3; > > /* Disable interrupts */ > @@ -144,7 +144,7 @@ > if (PageTable) > *PageTable = (PHARDWARE_PTE)(Pde->PageFrameNumber << PAGE_SHIFT); > } > - > + > return TRUE; > } > > @@ -172,7 +172,7 @@ > /* Get PTE of VirtualPtr, make it valid, and map PhysicalPtr there */ > Pte = &PageTable[(VirtualPtr >> 12) & ((1 << PTE_BITS) - 1)]; > Pte->Valid = 1; > - Pte->PageFrameNumber = PhysicalPtr.QuadPart >> PAGE_SHIFT; > + Pte->PageFrameNumber = (PFN_NUMBER)(PhysicalPtr.QuadPart >> PAGE_SHIFT); > > return TRUE; > } > @@ -189,7 +189,7 @@ > PhysicalPtr = MmGetPhysicalAddress(VirtualPtr); > > /* Map its physical address in the page table provided by the caller */ > - Pte->PageFrameNumber = PhysicalPtr.QuadPart >> PAGE_SHIFT; > + Pte->PageFrameNumber = (PFN_NUMBER)(PhysicalPtr.QuadPart >> PAGE_SHIFT); > } > > BOOLEAN > > 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] Sat Oct 19 11:33:34 2013 > @@ -166,6 +166,7 @@ > KiTrapExitStub KiEditedTrapReturn, (KI_RESTORE_VOLATILES OR KI_RESTORE_EFLAGS OR KI_EDITED_FRAME OR KI_EXIT_RET) > KiTrapExitStub KiTrapReturn, (KI_RESTORE_VOLATILES OR KI_RESTORE_SEGMENTS OR KI_EXIT_IRET) > KiTrapExitStub KiTrapReturnNoSegments, (KI_RESTORE_VOLATILES OR KI_EXIT_IRET) > +KiTrapExitStub KiTrapReturnNoSegmentsRet8,(KI_RESTORE_VOLATILES OR KI_RESTORE_EFLAGS OR KI_EXIT_RET8) > > #ifdef _MSC_VER > EXTERN _PsConvertToGuiThread@0:PROC > > 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] Sat Oct 19 11:33:34 2013 > @@ -100,7 +100,7 @@ > if (__builtin_expect(TrapFrame->Dr7 & ~DR7_RESERVED_MASK, 0)) > { > /* Check if the frame was from user mode or v86 mode */ > - if ((TrapFrame->SegCs & MODE_MASK) || > + if (KiUserTrap(TrapFrame) || > (TrapFrame->EFlags & EFLAGS_V86_MASK)) > { > /* Handle debug registers */ > @@ -124,13 +124,13 @@ > if (TrapFrame->EFlags & EFLAGS_V86_MASK) KiTrapReturnNoSegments(TrapFrame); > > /* Check for user mode exit */ > - if (TrapFrame->SegCs & MODE_MASK) KiTrapReturn(TrapFrame); > + if (KiUserTrap(TrapFrame)) KiTrapReturn(TrapFrame); > > /* Check for edited frame */ > if (KiIsFrameEdited(TrapFrame)) KiEditedTrapReturn(TrapFrame); > > /* Exit the trap to kernel mode */ > - KiTrapReturnNoSegments(TrapFrame); > + KiTrapReturnNoSegmentsRet8(TrapFrame); > } > > DECLSPEC_NORETURN > @@ -152,7 +152,7 @@ > KeGetCurrentThread()->PreviousMode = (CCHAR)TrapFrame->PreviousPreviousMode; > > /* Check for user mode exit */ > - if (TrapFrame->SegCs & MODE_MASK) > + if (KiUserTrap(TrapFrame)) > { > /* Check if we were single stepping */ > if (TrapFrame->EFlags & EFLAGS_TF) > @@ -186,13 +186,13 @@ > if (TrapFrame->EFlags & EFLAGS_V86_MASK) KiTrapReturnNoSegments(TrapFrame); > > /* Check for user mode exit */ > - if (TrapFrame->SegCs & MODE_MASK) KiTrapReturn(TrapFrame); > + if (KiUserTrap(TrapFrame)) KiTrapReturn(TrapFrame); > > /* Check for edited frame */ > if (KiIsFrameEdited(TrapFrame)) KiEditedTrapReturn(TrapFrame); > > /* Exit the trap to kernel mode */ > - KiTrapReturnNoSegments(TrapFrame); > + KiTrapReturnNoSegmentsRet8(TrapFrame); > } > > > @@ -1250,10 +1250,10 @@ > /* Call the access fault handler */ > Status = MmAccessFault(TrapFrame->ErrCode & 1, > (PVOID)Cr2, > - TrapFrame->SegCs & MODE_MASK, > + KiUserTrap(TrapFrame), > TrapFrame); > if (NT_SUCCESS(Status)) KiEoiHelper(TrapFrame); > - > + > /* Check for syscall fault */ > #if 0 > if ((TrapFrame->Eip == (ULONG_PTR)CopyParams) || > @@ -1541,7 +1541,7 @@ > TrapFrame->Dr7 = 0; > > /* Check if the frame was from user mode */ > - if (TrapFrame->SegCs & MODE_MASK) > + if (KiUserTrap(TrapFrame)) > { > /* Check for active debugging */ > if (KeGetCurrentThread()->Header.DebugActive & 0xFF) > > Modified: trunk/reactos/ntoskrnl/ke/i386/usercall.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/usercall.… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/usercall.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/usercall.c [iso-8859-1] Sat Oct 19 11:33:34 2013 > @@ -67,7 +67,7 @@ > _SEH2_TRY > { > /* Sanity check */ > - ASSERT((TrapFrame->SegCs & MODE_MASK) != KernelMode); > + ASSERT(KiUserTrap(TrapFrame)); > > /* Get the aligned size */ > AlignedEsp = Context.Esp & ~3; > @@ -210,7 +210,7 @@ > } > > > -/* > +/* > * Stack layout for KiUserModeCallout: > * ---------------------------------- > * KCALLOUT_FRAME.ResultLength <= 2nd Parameter to KiCallUserMode > > Modified: trunk/reactos/ntoskrnl/ke/time.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/time.c?rev=607… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/time.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/time.c [iso-8859-1] Sat Oct 19 11:33:34 2013 > @@ -153,7 +153,7 @@ > > /* Check if we came from user mode */ > #ifndef _M_ARM > - if ((TrapFrame->SegCs & MODE_MASK) || (TrapFrame->EFlags & EFLAGS_V86_MASK)) > + if (KiUserTrap(TrapFrame) || (TrapFrame->EFlags & EFLAGS_V86_MASK)) > #else > if (TrapFrame->PreviousMode == UserMode) > #endif > >

9 years

1
0
0 0

ReactOS SVN Version Naming

by Mark Jansen

This way of numbering seems very confusing to me, and I assume to other people as well.. When ReactOS presents itself as 0.5-SVN, I would expect this to be a 0.5 release, and not a 0.4 release that is working towards a 0.5. regards, Mark PS: I wasn't subscribed at the time this was sent, so sending a 'fake' reply :) *Ged Murphy* gedmurphy.maillists at gmail.com > <ros-dev%40reactos.org?Subject=Re%3A%20%5Bros-dev%5D%20ReactOS%20SVN%20version%20naming&In-Reply-To=%3C005201d1730b%2456b98b90%24042ca2b0%24%40gmail.com%3E> > *Mon Feb 29 16:07:49 UTC 2016* > > Because that’s what is being worked towards now, and there will be an > unknown number of point releases until it’s reached. > > It’s also a bit of nostalgia, it’s what we’ve always done :) > > > >> >> From: Ros-dev [mailto:ros-dev-bounces at reactos.org <http://www.reactos.org/mailman/listinfo/ros-dev>] On Behalf Of Hermès >> BÉLUSCA - MAÏTO >> Sent: 29 February 2016 16:00 >> To: ReactOS Development List <ros-dev at reactos.org <http://www.reactos.org/mailman/listinfo/ros-dev>> >> Subject: [ros-dev] ReactOS SVN version naming >> >> Hi guys, >> >> I would like to understand what’s the rationale behind changing the ReactOS >> trunk version from “0.4-SVN” to “0.5-SVN” (see revision 70818) whereas we >> have just started to release ROS 0.4.0 only? >> >> Thanks in advance for your explanations! >> >> Cheers, >> Hermès. > >

9 years

2
1
0 0

Re: [ros-dev] [ros-diffs] [tfaber] 71129: [NTOS:WMI] - Avoid a memory leak in failure case of WmipGetRawSMBiosTableData. CORE-11095 #resolve

by Thomas Faber

That should have included "Patch by Víctor Martínez Calvo. CID 1322162." On 2016-04-09 18:16, tfaber(a)svn.reactos.org wrote: > Author: tfaber > Date: Sat Apr 9 16:16:12 2016 > New Revision: 71129 > > URL: http://svn.reactos.org/svn/reactos?rev=71129&view=rev > Log: > [NTOS:WMI] > - Avoid a memory leak in failure case of WmipGetRawSMBiosTableData. > CORE-11095 #resolve > > Modified: > trunk/reactos/ntoskrnl/wmi/smbios.c > > Modified: trunk/reactos/ntoskrnl/wmi/smbios.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/wmi/smbios.c?rev=… > ============================================================================== > --- trunk/reactos/ntoskrnl/wmi/smbios.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/wmi/smbios.c [iso-8859-1] Sat Apr 9 16:16:12 2016 > @@ -196,6 +196,7 @@ > TableMapping = MmMapIoSpace(PhysicalAddress, TableSize, MmCached); > if (TableMapping == NULL) > { > + ExFreePoolWithTag(BiosTables, 'BTMS'); > return STATUS_UNSUCCESSFUL; > } > > >

9 years

1
0
0 0

Status Meeting (March 2016)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place last Thursday of a month, 31th of March, 19:00 UTC, as usual. That's tomorrow! IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. Please send agenda proposals to me before the meeting. And yes, 0.4.1 release discussion is in the agenda list already, proposed by Alex Rex :-) Regards, Aleksey Bragin

9 years

5
6
0 0

First Buildslaves back up again

by Colin Finck

Hi all, After the plugs at our old hosting site have finally been pulled yesterday, I managed to save all the important data and bring up a new server. The following services are up again, even if their performance might not match the old one: * Build GCCLin_x86 * Build GCCLin_x86 Release * Test KVM * iso.reactos.org In a short timeframe, I may be able to revive the Windows 7 builder as well as Doxygen and download.reactos.org. Needs some evaluation as to whether the resources of the server manage that. Approximately around May or June, we can add some of our previous servers to the server farm again. All services should be back up by then, with the same or even improved performance. Cheers, Colin

9 years

1
0
0 0

Re: [ros-dev] Status Meeting (March 2016)

by Matthias Kupfer

Hello, unfortunately I can't attend this meeting because of another official appointment. Nevertheless I would like to offer support the GSoC student as contact or mentor of necessary. Rama already contacted me and I reviewed his proposal last week. As long as it is on the optional list of projects I deem necessary to mention this. Regards, Matthias Am Wednesday 30 March 2016 20:15:08 schrieb Aleksey Bragin: > Hello, > Let me invite you to the monthly status meeting taking place last > Thursday of a month, 31th of March, 19:00 UTC, as usual. That's tomorrow! > > IRC service will only be started shortly before the meeting. Your > participation passwords and server address will be emailed to you > shortly before the meeting starts, and they are going to be different > once again as they are not stored in any database. Hopefully it's not > much of inconvenience. > > Please send agenda proposals to me before the meeting. And yes, 0.4.1 > release discussion is in the agenda list already, proposed by Alex Rex :-) > > Regards, > Aleksey Bragin > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev -- Matthias Kupfer phone +49 371 236 46 52 Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54 09122 Chemnitz, Germany

9 years

4
3
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 71085: [NETAPI32] DsEnumerateDomainTrustsW missing in netapi32.dll. Patch by Jared Smudde. CORE-11056 #resolve #comment Thanks a lot!

by Thomas Faber

On 2016-03-31 23:12, ekohl(a)svn.reactos.org wrote: > +DWORD WINAPI DsEnumerateDomainTrustsW(LPWSTR ServerName, ULONG Flags, PDS_DOMAIN_TRUSTSW* Domains, PULONG DomainCount) > +{ > + FIXME("(%s, %x, %p, %p): stub\n", ServerName, Flags, Domains, DomainCount); > + return ERROR_NO_LOGON_SERVERS; > +} Copypasta format string.

9 years

1
0
0 0

Re: [ros-dev] [ros-diffs] [akhaldi] 71057: [REISERFS] Import ReiserFS file system driver for Windows. It will be enabled later on. Brought to you by Peter Hater. CORE-11005

by Alex Ionescu

Hide your wife. Best regards, Alex Ionescu On Sat, Mar 26, 2016 at 1:40 PM, <akhaldi(a)svn.reactos.org> wrote: > Author: akhaldi > Date: Sat Mar 26 20:40:42 2016 > New Revision: 71057 > > URL: http://svn.reactos.org/svn/reactos?rev=71057&view=rev > Log: > [REISERFS] Import ReiserFS file system driver for Windows. It will be enabled later on. Brought to you by Peter Hater. CORE-11005 > > Added: > trunk/reactos/drivers/filesystems/reiserfs/ > trunk/reactos/drivers/filesystems/reiserfs/CMakeLists.txt (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/ > trunk/reactos/drivers/filesystems/reiserfs/inc/gplntifs.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/ > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/bit_spinlock.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/bitops.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/config.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/errno.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/fs.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/jbd.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/journal-head.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/kernel.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/list.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/log2.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/module.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/nls.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_acl.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_fs.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_fs_i.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_fs_sb.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_xattr.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/slab.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/spinlock.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/stddef.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/string.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/types.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/linux/version.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/reiserfs.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/inc/rfsd.h (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/ > trunk/reactos/drivers/filesystems/reiserfs/src/blockio.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/cleanup.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/close.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/cmcb.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/create.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/debug.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/devctl.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/dirctl.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/dispatch.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/except.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/fastio.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/fileinfo.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/flush.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/fsctl.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/init.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/lockctl.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/memory.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/misc.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/ > trunk/reactos/drivers/filesystems/reiserfs/src/nls.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_base.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_big5.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp1251.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp1255.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp437.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp737.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp775.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp850.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp852.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp855.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp857.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp860.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp861.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp862.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp863.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp864.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp865.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp866.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp869.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp874.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp932.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp936.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp949.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp950.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_euc-jp.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_euc-kr.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_gb2312.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-1.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-13.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-14.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-15.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-2.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-3.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-4.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-5.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-6.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-7.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-8.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-9.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_koi8-r.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_koi8-ru.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_koi8-u.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_sjis.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_tis-620.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_utf8.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/pnp.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/read.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/rfsd.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/rfsd.rc (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/rfsdblock.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/shutdown.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/volinfo.c (with props) > trunk/reactos/drivers/filesystems/reiserfs/src/write.c (with props) > Modified: > trunk/reactos/drivers/filesystems/CMakeLists.txt > > [This mail would be too long, it was shortened to contain the URLs only.] > > Modified: trunk/reactos/drivers/filesystems/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/CMakeL… > > Added: trunk/reactos/drivers/filesystems/reiserfs/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/gplntifs.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/bit_spinlock.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/bitops.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/config.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/errno.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/fs.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/jbd.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/journal-head.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/kernel.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/list.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/log2.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/module.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/nls.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_acl.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_fs.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_fs_i.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_fs_sb.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_xattr.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/slab.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/spinlock.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/stddef.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/string.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/types.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/linux/version.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/reiserfs.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/inc/rfsd.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/blockio.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/cleanup.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/close.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/cmcb.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/create.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/debug.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/devctl.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/dirctl.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/dispatch.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/except.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/fastio.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/fileinfo.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/flush.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/fsctl.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/init.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/lockctl.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/memory.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/misc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_base.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_big5.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp1251.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp1255.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp437.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp737.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp775.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp850.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp852.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp855.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp857.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp860.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp861.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp862.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp863.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp864.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp865.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp866.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp869.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp874.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp932.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp936.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp949.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_cp950.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_euc-jp.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_euc-kr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_gb2312.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-1.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-13.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-14.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-15.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-2.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-3.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-4.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-5.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-6.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-7.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-8.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_iso8859-9.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_koi8-r.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_koi8-ru.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_koi8-u.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_sjis.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_tis-620.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/nls/nls_utf8.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/pnp.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/read.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/rfsd.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/rfsd.rc > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/rfsdblock.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/shutdown.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/volinfo.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > > Added: trunk/reactos/drivers/filesystems/reiserfs/src/write.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/reiser… > >

9 years

3
2
0 0

502 Bad Gateway

by Javier Agustìn Fernàndez Arroyo

Hello, I am receiving this when trying to access website... Is anyone having the same problem?

9 years

2
1
0 0

Spam, the irony

by Hermès BÉLUSCA - MAÏTO

Hi all, I guess this post is spam : http://www.reactos.org/forum/viewtopic.php?f=2 <http://www.reactos.org/forum/viewtopic.php?f=2&t=9752#p120604> &t=9752#p120604 Ironically placed inside the thread titled Spam Bot Detection Guidelines ^^ Cheers, Hermès.

9 years

1
0
0 0

GSoC Students! Attention!

by Alexander Rechitskiy

9 years

1
0
0 0

[GSOC] Fully Integrate lwIP

by Valy Mitrea

Hello, I am interested in participating at GSOC 2016 and ReactOS has attracted my attention as being an interested project to work on. The project that aims to fully integrate lwIP is the one that caught my attention so I sent an application to it. I would be grateful if someone can provide some feedback to my application. Also, I tried to compile the ReactOS sources on my laptop, but I am having some problems. I tried solving them with the help of someone on the IRC channel, but that was unsuccessful. I have cloned the SVN repository in a directory on my hard disk and installed the RoSBuildEnvironment for Windows. When I run the "configure.cmd" script from the RoSBE terminal as is explained in the tutorial I am getting the message "find: cmake version: No such file or directory" which is strange because if I run the command "cmake --version" in the same terminal I get "cmake version 3.2.1-ReactOS" which means it is detecting cmake so there isn't a problem in my PATH environment variable. Anyone can help me with some tips regarding this issue? Best regards, Valentin Mitrea.

9 years, 1 month

2
2
0 0

Problems with debug log

by Илья Скапенко

Hello, everyone. I have an issue with retrieving debugging info. I've tried both: my built (debug, x32) version and yours one. I used 2 methods: putty serial <https://reactos.org/wiki/VirtualBox#Getting_debug_output>, and VMware Gateway <https://reactos.org/wiki/VirtualBox#Using_VMwareGateway>. All of them have the same response. OS: Windows 10 x64. Running ReactOS under Virtual Box. Debug log is attached. What is wrong? Or could you advise me more suitable place for asking such kind of questions?

9 years, 1 month

3
8
0 0

[GSoC] Student Application Form (RAPPS)

by Алексей Эльнатанов

Hi! My name is Alexey Elnatanov and I'm 2nd course student of Lomonosov Moscow State University Faculty of Computational Mathematics and Cybernetics. *Languages:* *Russian, English* *Timesone:* *UTC +03:00* *IRC Nickname:** InvalidPointer* I have some skill in C, NASM, UNIX-based systems (basic architecture, RAM organization, file systems, syscalls, IPC, etc.). Also like Python. In React-OS I'm interested in *Applications Manager Rapps *because it's description looks interesting for me and it's very helpful for React-OS user, which is very inspiring. And as for my most serious project, I was working at, it's Conway's Game of Life parrallel realization, using multiple processes and UNIX IPC. Glad to hear from somebody soon. With best regards, Alexey Elnatanov.

9 years, 1 month

1
0
0 0

[GSOC] Student Application Form (NTFS RW)

by Vlad Kudoyar

Hello My name is Vlad Kudoyar and I'm a 3rd course student in Donetsk National Technical Univercity (Ukraine). My speciality is Computer Engineering. Languages: Russian, English (I can easily read texts but write with Google Translate :) ). Timezone: UTC +03:00. IRC Nickname: Vlad8161. I will be able to spend almost all of my summer working on this project. I have bodybuilding trainings 3 times a week, but they don't take too much time. In ROS project I want to work on NTFS driver. I think I can cope with implementing RW features. General milestones: 1. Implementing features to modify MFT records' attributes 2. Implementing create/delete MFT records functionality 3. Implementing journaling I realize that this plan is easy to write but hard to implement but it is another goot reason to try hard. I had filesystem course in my university so I can imagine what I have to work with. I know basic NTFS concepts and structure of this file system, but I have too little experience with driver development. I hope mentors will help me in this field.

9 years, 1 month

1
0
0 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 71032: [NTOSKRNL] Fix build. Seriously... GCC, you allow this?!

by Thomas Faber

On 2016-03-20 20:30, pschweitzer(a)svn.reactos.org wrote: > Seriously... GCC, you allow this?! Apparently this is valid in newer C++ standards, so GCC allows it also for C. It will warn with -pedantic, which is probably too... pedantic for our code base unfortunately ;)

9 years, 1 month

1
0
0 0

GSOC Proposal

by Oleg Brezhnev

Hello everyone, Please, could anyone check my GSOC proposal and give me some feedback? https://docs.google.com/document/d/1fcRXosGEzNzpy9SMAAdkTSAkOZwnKjYj7wO gVWUWTXc/edit?usp=sharing

9 years, 1 month

1
1
0 0

ReactOS kernel driver

by Mohammad Samian Yusuf

Hi everyone I was wondering, developing kernel drivers for reactOS, does it have any templates to follow up, or how does the driver development work for reactOS, I am am trying to understand if I am to develop a kernel driver, should I be building it against a windows version,which can be ported to reactOS later through some changes?? Any advices would be appreciated With Care Samian Sent from my BlackBerry 10 smartphone on the Fido network.

9 years, 1 month

2
1
0 0

GSoC 2016: SSH Service

by Михаил Широков

9 years, 1 month

3
2
0 0

GSoC 2016 interest on RAPPS and GUI installer

by Niebieski Poganiac

Hello everyone. I'm Niebieski from freenode. I like Free Software and thus believe that a free software OS that is binary compatible with Windows will be huge contribution to the computing world. When I saw ReactOS on the orgs list in GSoC I totally considered checking the possibility of working with you guys. I'm interested on RAPPS and the GUI installer. Why ? It's clear that it's easy to install Windows because of the GUI installer, is it the easiest OS installer ever ? If you insert a bootable Windows media and kept pressing ENTER, you will probably end up with an installed system. So I think the GUI installer is a big step into ease of use. For RAPPS, it's essential utility. Lets you install apps without searching their names one by one on a search engine. or even give me a script that installs my favourite tools ? It's also a good way to discover new good software, specially if it's GPL software. Note that I'm talking about end-user point of view. I've seen the document made by Amine Khaldi about RAPPS. I've tried to get familiar with the WIN32 API a couple of years ago. Why ? because I like low level GUI stuff and then tried out GTK and Qt when I used Linux. I found out about Charles Petzold's book. I like C that's why I liked WIN32 API at first. The latest code I wrote was mainly academic assignments, A Caesar cipher implementation and a multi-threaded sorting program using pthread library. Note that I didn't develop something serious using WIN32 API I just read some tutorials but didn't build something. I know handles, WinMain and these basic stuff. so honestly I don't have any 'real' development experience. but I've tried to contribute to several open source orgs. I'm pursuing my bachelor degree in computer engineering and going to submit my senior project implementation during May/June. I might register for summer courses. I would like to have your honest opinions, do you think I should drop it ? or continue and try to find how it's going to be done technically ? and submit a proposal ? I've seen that some people are already interested on RAPPS and doing good job. Thank you guys for the work on ReactOS and the time spent on helping GSoC students. I really appreciate it and hope you the best.

9 years, 1 month

1
0
0 0

Fwd: [Supertuxkart-devel] Get STK running into ReactOS

by Javier Agustìn Fernàndez Arroyo

This is the STK main developer answer... ---------- Forwarded message ---------- From: M Gagnon <auria.mg(a)gmail.com> Date: Fri, Mar 18, 2016 at 10:54 PM Subject: Re: [Supertuxkart-devel] Get STK running into ReactOS To: supertuxkart-devel(a)lists.sourceforge.net Hi, we only use "supported" for systems where a regular team member frequently tests and ensures the game works correctly. I'm afraid no one in the core team uses ReactOS so we cannot mark it as officially supported. Of course, it might still work, but we can't garantee it -- Auria On Fri, Mar 18, 2016 at 10:47 AM, Javier Agustìn Fernàndez Arroyo < elhoir(a)gmail.com> wrote: > hello to all, > > Yes, Ged, this was sent to STK mailing list. I just CC`ed ReactOS so that > you know my movement. > > Hello Deve, no, this is not an issue message. I just wondered if you could > put ReactOS as a supported operating system, along with Windows XP. That > would bring visibility to ReactOS, imo. > > On Fri, Mar 18, 2016 at 1:21 PM, Deve <deveee(a)gmail.com> wrote: > >> Hi, >> >> As far, as I understand ReactOS is/should be binary-compatible with >> Windows and you should be able to run our WinXP version on it. At least if >> ReactOS contains all required features. >> >> Last time that I checked STK on Wine, it was working fine. I have no >> possibility to check it on ReactOS, but I assume that it works in similar >> way. >> >> What kind of problem do you have when you try to run on this operating >> system? Does it crash or it doesn't run at all? Do you get some logs in >> console? >> >> Regards, >> Deve >> >> >> >> ------------------------------------------------------------------------------ >> Transform Data into Opportunity. >> Accelerate data analysis in your applications with >> Intel Data Analytics Acceleration Library. >> Click to learn more. >> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 >> _______________________________________________ >> Supertuxkart-devel mailing list >> Supertuxkart-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/supertuxkart-devel >> >> > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 > _______________________________________________ > Supertuxkart-devel mailing list > Supertuxkart-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/supertuxkart-devel > > ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ Supertuxkart-devel mailing list Supertuxkart-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/supertuxkart-devel

9 years, 1 month

2
1
0 0

Re: [ros-dev] [Supertuxkart-devel] Get STK running into ReactOS

by Javier Agustìn Fernàndez Arroyo

hello to all, Yes, Ged, this was sent to STK mailing list. I just CC`ed ReactOS so that you know my movement. Hello Deve, no, this is not an issue message. I just wondered if you could put ReactOS as a supported operating system, along with Windows XP. That would bring visibility to ReactOS, imo. On Fri, Mar 18, 2016 at 1:21 PM, Deve <deveee(a)gmail.com> wrote: > Hi, > > As far, as I understand ReactOS is/should be binary-compatible with > Windows and you should be able to run our WinXP version on it. At least if > ReactOS contains all required features. > > Last time that I checked STK on Wine, it was working fine. I have no > possibility to check it on ReactOS, but I assume that it works in similar > way. > > What kind of problem do you have when you try to run on this operating > system? Does it crash or it doesn't run at all? Do you get some logs in > console? > > Regards, > Deve > > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 > _______________________________________________ > Supertuxkart-devel mailing list > Supertuxkart-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/supertuxkart-devel > >

9 years, 1 month

2
1
0 0

Get STK running into ReactOS

by Javier Agustìn Fernàndez Arroyo

Hello, STK users and devs, First of all, i´m new to this mailing list, so i hope not to disturb it... I´m a fan of SuperTuxKart both in Linux (Ubuntu) and Windows. And i´m also a fan and user of the new operating system Reactos. http://www.reactos.org Yes, i do love open source. I hae seen in your homepage that you bring binaries for Windows XP. You all know XP ended support long ago. And here is where ReactOS comes in place. ReactOS aims to clone Windows 2003 behavior (and, as you know, 2k3 and XP are quite similar). So my request is simple. I think it would be asesome if your game runs in this OS. And if not, its a bug that ReactOS devs have to fix. What would help development too. What do u think? is it worth to give STK a try into ReactOS? what about putting this OS as a supported one, along with XP? Thanks in advance for your attention.

9 years, 1 month

3
2
0 0

Re: [ros-dev] Ros-diffs Digest, Vol 146, Issue 58

by Hermès BÉLUSCA - MAÏTO

This is indeed an amazing feature, until you notice that you've tested already local build compilation (just before committing) and neither GCC nor MSVC detected any error, and only after commit you see that it breaks the build bots... Hermès. -----Message d'origine----- Date: Thu, 17 Mar 2016 07:55:00 -0000 From: pschweitzer(a)svn.reactos.org To: ros-diffs(a)reactos.org Subject: [ros-diffs] [pschweitzer] 71017: [VFATLIB] Hint for future and current developers: there's a hidden feature in ReactOS, you can build it locally before committing, so that you can check whether your commit bre... Message-ID: <mailman.4.1458216001.13352.ros-diffs(a)reactos.org> Content-Type: text/plain; charset="utf-8" Author: pschweitzer Date: Thu Mar 17 07:55:00 2016 New Revision: 71017 URL: http://svn.reactos.org/svn/reactos?rev=71017&view=rev Log: [VFATLIB] Hint for future and current developers: there's a hidden feature in ReactOS, you can build it locally before committing, so that you can check whether your commit breaks build... Amazing, isn't it? Modified: trunk/reactos/lib/fslib/vfatlib/check/common.h Modified: trunk/reactos/lib/fslib/vfatlib/check/common.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/fslib/vfatlib/check/com mon.h?rev=71017&r1=71016&r2=71017&view=diff ============================================================================ == --- trunk/reactos/lib/fslib/vfatlib/check/common.h [iso-8859-1] (original) +++ trunk/reactos/lib/fslib/vfatlib/check/common.h [iso-8859-1] Thu Mar 17 07:55:00 2016 @@ -32,7 +32,7 @@ void die_func(const char *msg, ...); #define die(msg, ...) \ do { \ - die_func("DIE! (%s:%d) " msg "\n", __RELFILE__, __LINE__, ##__VA_ARGS__) \ + die_func("DIE! (%s:%d) " msg "\n", __RELFILE__, __LINE__, + ##__VA_ARGS__); \ } while (0) /* Displays a prinf-style message and terminates the program. */ @@ -42,7 +42,7 @@ void pdie_func(const char *msg, ...); #define pdie(msg, ...) \ do { \ - pdie_func("P-DIE! (%s:%d) " msg "\n", __RELFILE__, __LINE__, ##__VA_ARGS__) \ + pdie_func("P-DIE! (%s:%d) " msg "\n", __RELFILE__, __LINE__, + ##__VA_ARGS__); \ } while (0) /* Like die, but appends an error message according to the state of errno. */ ------------------------------ Subject: Digest Footer _______________________________________________ Ros-diffs mailing list Ros-diffs(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-diffs ------------------------------ End of Ros-diffs Digest, Vol 146, Issue 58 ******************************************

9 years, 1 month

1
0
0 0

GSoC proposal

by Илья Скапенко

Hello, everyone. I want to participate in GSoC. Please, take a look at my draft version of proposal <https://docs.google.com/document/d/1lYg5Tm0gr8neXa8j_vTUzFjkkHWBkQfTyqnkQ0J…>. Unfortunately I can't say anything about milestones and shedule, because of non acquaintance with the difficulty of this project. I desided to add some additional background information. I don't have any experience in patching or writing soucre for ReactOS. I also consider Integrating SMB in ReactOS as a potentional project. Could you advise me something?

9 years, 1 month

2
1
0 0

Question about TCP/IP

by MarylandenyChu

Hi, I'd like to apply for "Fully Integrate lwIP" part this year. I noticed that in last year's idea list, this part is performed as another way: making a own TCP/IP implementation. I don't know why we change the direction to make fully integrate lwIP. Does it because that it seems very hard to finish? Can I have the answers? Thanks! 初炳享Chu Bingxiang哈尔滨工程大学计算机科学与技术学院College of Computer Science and Technology in Harbin Engineering University

9 years, 1 month

1
0
0 0

Student Application for GSoC2016

by Viacheslav Lebedev

My name is Viacheslav (or just Slava). Firstly I want to say that I don’t have any special IT education and I am not a student already. I did not find such limitations in the description, but it seems that it is only for undergraduate students. I worked as a C++ programmer for 4.5 years. My job was to support the old projects. I don’t have any special skills. Do I have any chance to join you? *General info* Full Name: Viacheslav Lebedev Language: Russian and English (I don’t know my English level) Time Zone: UTC +3 ReactOS website Account Name: I don’t have it and don’t see the way to get it. *Time commitment* I don’t have plans in summer, but I have a job. If it will be necessary I can try to take a vacation or even leave it. *Proposed Project* I am a new here and it is too early for me to have my own idea. I think the only I can try is Search Band in Explorer. On Saturday, I saw Folder Treeview, but now it’s absent. Probably, it is also Applications Manager Rapps. I could try something special like Integrating SMB or Audio Mixer, but I am afraid I’ll fail it.

9 years, 1 month

3
2
0 0

TR: ReactOs newbie. Help to get started with bug fixes.

by Hermès BÉLUSCA - MAÏTO

Hi Rama, I’m retransmitting your mail to the reactos developers mailing-list so that other people can also guide you. There are some ideas already proposed for the GSoC that you can see on this page: https://www.reactos.org/wiki/Google_Summer_of_Code_2016_Ideas and on which you can choose, depending on your familiarity with one or any other proposals, or bring your own proposal (read also https://www.reactos.org/wiki/Google_Summer_of_Code_2016 for more details). Regards, Hermès BÉLUSCA - MAÏTO De : Rama Teja G [mailto:ramateja.g@gmail.com] Envoyé : mardi 15 mars 2016 15:10 À : hermes.belusca(a)sfr.fr Objet : ReactOs newbie. Help to get started with bug fixes. Hi, This is Rama Teja.G a student applying to reactOs for GSoc. I want to get started with the community(may be some patches?). I am not sure how to get started. Can you please help me. Any advice will be appreciated. Thanks in advance, Rama Teja.G

9 years, 1 month

1
0
0 0

GSoC 2016

by Nikita Belov

Hello. My name is Nikita Belov and I'm a master's degree student of Moscow State University faculty of Computational Mathematics and Cybernetics. General Information. 1. Full Name: Nikita Belov. 2. Languages You Speak: Russian and English. 3. Timezone: UTC+03:00 (Moscow). 4, 5. ReactOS website Account Name, IRC Nickname on Freenode: I don't have an account yet. Time Commitment. I can spend on ReactOS project as many time as it will need. Proposed Projects: 1. NTFS driver improvements. or 2. GUI 1st Stage Installer. (Please propose any other ideas you think are suitable for my skills.) I don't have any experience in this fields, but I have skills in emulation programming (in C) as my course and graduation works: 1. Development of guest code hot replacement method for dynamic binary translation in QEMU. 2. Automatic uninitialized value usage detection during full-system emulation. Also, is it necessary to submit this application form elsewhere?

9 years, 1 month

1
0
0 0

Google Summer of Code

by Sergey P.

Hello, my name is Sergey and I want to participate in Summer of Code 2016. I have some experience in C/C++ and reverse engineering, primarily from modding certain video games. My main project is Widescreen Fixes Pack: http://thirteenag.github.io/wfp Others can be found on github: https://github.com/ThirteenAG I would like to work on RAPPS (adding command line parameters support to RAPPS), because this idea seems interesting and doable for me. So, my question is, whether I should apply or not, because I have never done anything like this and have my doubts.

9 years, 1 month

1
0
0 0

GSoC 2016: USB 3.0 Support

by Vardan Mikayelyan

Hi, My name is Vardan, I am from National Polytechnic University of Armenia, and this is my 5th year here. I'm student of 1st course of master program. In parallel to studying I am contributing Linux USB stack and have community accepted commits which are presented in Linux 4.5-rc4. I saw ReactOS in GSoC organizations list, and it interested me as great place to learn and grow as professional developer. I am interested in driver development and especially I like USB stack. Because USB supports many kinds of transfers and USB protocols are interesting by themselves. I have investigated dwc2 driver in Linux Kernel. As you may know it is driver for dual-role HS USB controller, so I am familiar with USB HCD and gadget stacks. I have looked into ReactOS's git repo and saw that there is completely missing XHCI driver. In case of OHCI, UHCI and EHCI I saw Michael Martin's and Johannes Anderwald's drivers. As I understand one of them or someone from this community will be the mentor for the XHCI project in terms of GSoC 2016. For me is very interesting to work on NT platform, because till now I had only Linux Kernel development practice. I have few questions as probable applicant, 1. Should the deliverable XHCI driver support all kind of transfers? 2. How it will be tested and should it pass any kind of certification with any XHCI host controller? 3. Should it have support for non transfer related features? I mean for example LPM or Hibernation. 4. Will whole project entrusted to the one student or he'll be team member? >From your reply I want to understand what are you expecting form applicant and how can I fit to your expectations. Thanks in advance, Vardan.

9 years, 1 month

2
2
0 0

Re: [ros-dev] [ros-diffs] [rnaumann] 70914: [APPWIZ] Stubplement ConfigStartMenu Patch by Jared Smudde. CORE-10788

by Thomas Faber

On 2016-03-05 11:36, rnaumann(a)svn.reactos.org wrote: > +LONG > +CALLBACK > +ConfigStartMenu(HWND hwndCPl, UINT uMsg, LPARAM lParam1, LPARAM lParam2) Where does this prototype come from?

9 years, 1 month

2
1
0 0

Student Application

by Dasha Che

Hello, my name is Dasha. I would like to apply to be a participant in your group for the Google Summer of Code. Below I have written out some of the information that you were asking for and I would be very grateful if you took the time to read over and consider it. General Info Name: Daria (Dasha) Chekhovskaya Languages: Fully fluent in both Russian and English Time Zone: Central Time Zone ReactOS website account name: N/A IRC nickname on Freenode: Dashka Time Commitment I have two main things that I have set in stone for this coming summer. I have to take a drivers ed course, because learning how drive is a useful skill as we all know, but the course is only two weeks long either in the mornings or in the afternoons, so it shouldn’t really get in the way much. The second is boxing. I take boxing and kickboxing lessons and also help out with some of the kids classes. It’s generally Monday to Friday for a couple hours in the evening. Most of the time that I would be working on the project on would probably be in the morning, evening, and into the late evenings. Proposed Projects -Folder Treeview in Explorer https://www.reactos.org/wiki/Google_Summer_of_Code_2016_Ideas#Folder_TreeVi… -Audio Mixer https://www.reactos.org/wiki/Google_Summer_of_Code_2016_Ideas#Audio_Mixer -NTFS Driver Improvement https://www.reactos.org/wiki/Google_Summer_of_Code_2016_Ideas#NTFS_driver_i… One of the problems is that I don’t have a portfolio. I do have some precious experience in working in C++ and a couple other programming languages. I am by no means a professional but I’m always ready to listen and learn. I pick things up very quickly, so as long as I’m given pretty straight forward directions as to what needs to be done I, personally, have no doubts I’ll be able to figure out what to do. Best Regards, Dasha Chekhovskaya

9 years, 1 month

3
5
0 0

GSOC-2016

by Mohammad Samian Yusuf

Hi my name is samian I wanted to write up a proposal for the project "Integrating SMB into ReactOS " I was wondering whether anyone has taken up this project or not yet ? Is this an active project as is anyone currently working on it, as of now i am looking int the codes to come up with a plan for the development. Currently i am working with the samba team in testing a new copy transfer system, which they plan to implement into the future. I just need to know this project is online and someone working around to mentor me at some stages. Any advice would be appreciated With Care Samian

9 years, 1 month

3
5
0 0

Student Application Form for Google Summer of Code 2016

by Willy Fox

General Information - *Full Name: **Anton Slyadnev* - *Languages: English, Russian* - *Timezone: GMT+10* - *ReactOS website Account Name: none (Is it broken? Forum "Access Denied")* - *IRC Nickname on Freenode: WillyFox* - *E-Mail: willyfox569803(a)gmail.com <willyfox569803(a)gmail.com>* - *VK.com login: /willy_the_fox * Time Commitment I'm 100% ready to spend all of my time to my GSoC project. Optional (But Suggested) *Proposed Project: *Windows native SSH-server Service *Useful for: *End-users and developers *Description: *Implement a native Windows service for accepting SSH connections and authenticating with Windows accounts to allow the user to interact with Windows through the command prompt should they not need access to the GUI shell. Once authenticated, any commands passed through SSH are executed using the user's credentials to prevent abuse of the service's privileges. And as the user is not technically logged in, there are no restrictions with respect to how many connections are permitted except as system resources allow.

9 years, 1 month

2
2
0 0

SMB integration to reactOS

by Mohammad Samian Yusuf

Hi Pierre The Samba-TNG code has not been updated recently as per i know. Can you elaborate on how we can implement this, from the userland space atm ? i am looking into the source codes, so a bit of more explanation on how we might achieve this could be helpful. Sorry i am have not done kernel programming, i did a few course, on kernel dev, but nothing big,. One thing i noticed that reactOS does not support POSIX, so can use the CIFS.KO from samba, to develop some baseline which can be used to develop a client tool i really could use some advice on how we can go on implementing this, With Care Samian

9 years, 1 month

1
0
0 0

Revived the Scrum Board!

by Colin Finck

Hi all, I have started using the Scrum Board of our JIRA again. Last time it was used was in 2012, and now that I'm using it everyday at work, I wonder how we could ever live without it.. Scrum Board for this month: https://jira.reactos.org/secure/RapidBoard.jspa?rapidView=3 (pretty lonely so far) So what is Scrum again? In a few words: I pick some JIRA issues I want to tackle this month. I can order them and drag & drop between "To Do", "In Progress" and "Done". When everybody does that, we have a nice list of tasks being worked on per month. Finally, you don't have to hope for your bug report to get attention anymore. You instantly see when it is planned to be worked on :) I refrain from going into the details of Scrum, Sprints and Kanban now. This already didn't work for us last time ;) I hope some of you join my efforts. If not, well, I will continue to use it as it doesn't just help the public, but also myself to organize better. Cheers, Colin

9 years, 1 month

1
0
0 0

Fwd: Google Summers of Code

by Сергей

> Начало переадресованного сообщения: > > Отправитель: Сергей <gaserd123(a)gmail.com> > Тема: Google Summers of Code > Дата: 9 марта 2016 г., 11:43:25 GMT+3 > Получатель: ros-dev-subscribe(a)reactos.org > > Hi guys! > I am Sergey and I study ITMO University Saint-Petersburg ( first courses magistracy ). I like web-developing. > I see your tasks of Google Summer of Code and I interested this task - "REST API in testman» > > My profile in github: > https://github.com/Gaserd <https://github.com/Gaserd> > > What i made that make this task?

9 years, 1 month

2
1
0 0

question about GSoC Student Application

by satori

1. Should i be a real student? 2. Should i give my real name for application? I'd like to participate in Google Summer of Code 2016, and i've already downloaded 18 GB of windows dev vbox image and made some first commits for windows ssh server from https://www.reactos.org/wiki/Google_Summer_of_Code_2016_Ideas. I coded in C, C++, C#, Delphi, Basic(MS Excel), SQL, PHP, Nodejs, js, html, css, bash, python, a bit of ruby, haskell, lisp. And i have nothing interesting to show as my portfolio.

9 years, 1 month

2
1
0 0

Greetings and short CV

by Алексей Эльнатанов

Hi! I'm student of MSU Faculty of Computational Mathematics and Cybernetics. I've read about GSoC competition and want to tell something about myself. I know C with some most usefull UNIX syscalls, signals, channels, IPC system, basics about UNIX kernel, file systems, RAM management and external drives management in UNIX. Also studied NASM and now learning C++. I want to improve my knowledge about NT systems. Also I like to write some usefull stuff. In ReactOS ideas I prefer "Applications Manager Rapps", because it's interesting, it can help many people and because for other things I haven't enough skills. The most complicated project I've written was parallel realization (using UNIX processes and IPC) of Conway's Game of Life in C. Also, I like writing Python scripts.

9 years, 1 month

1
0
0 0

GSOC RAPPS

by Boris Atamanovskiy

Hi. I am Boris Atamanovskiy, first year undergraduate student from Moscow aviation institute, Russia. I am interested in rapps. I have some questions about it. What should I use, rapps_new C++ or rapps C? Should rapps be a command-line tool with GUI frontend or GUI app with command line args? I am new to Windows development, so any advices about resources for learning it will be helpful. Regards, Boris Atamanovskiy

9 years, 1 month

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