- Ros-dev - ReactOS.org

Weirdness on QEMU
by Zachary Gorden 24 May '16

24 May '16

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?

2 2

Re: [ros-dev] 4th scenario
by Love Nystrom 24 May '16

24 May '16

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]

1 0

rosapps CreateSpec (Fw: ReactOS versioning)
by Love Nystrom 24 May '16

24 May '16

@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

1 0

Re: [ros-dev] 4th scenario
by Love Nystrom 23 May '16

23 May '16

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.

2 1

Re: [ros-dev] 4th scenario
by Love Nystrom 23 May '16

23 May '16

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]

3 3

Re: [ros-dev] 4th scenario
by Love Nystrom 23 May '16

23 May '16

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 >

1 0

Re: [ros-dev] Ros-dev Digest, Vol 141, Issue 24
by Love Nystrom 22 May '16

22 May '16

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

1 0

Re: [ros-dev] Actually a GOOD architecture.
by Love Nystrom 22 May '16

22 May '16

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/

1 0

Re: [ros-dev] ReactOS versioning
by Love Nystrom 22 May '16

22 May '16

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

1 0

Actually a GOOD architecture.
by Love Nystrom 22 May '16

22 May '16

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

3 2

ReactOS versioning
by Love Nystrom 21 May '16

21 May '16

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]

2 2

Re: [ros-dev] 4th scenario
by Love Nystrom 21 May '16

21 May '16

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

2 1

Re: [ros-dev] Ros-dev Digest, Vol 141, Issue 21
by Love Nystrom 21 May '16

21 May '16

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 >

1 0

Re: [ros-dev] Pale Moon drops ReactOS support
by Alex Ionescu 19 May '16

19 May '16

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

4 3

Re: [ros-dev] Pale Moon drops ReactOS support
by Alex Ionescu 19 May '16

19 May '16

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 9

Regarding r71352 and SubGit
by Colin Finck 18 May '16

18 May '16

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

3 2

Pale Moon drops ReactOS support
by Alexander Rechitskiy 17 May '16

17 May '16

11 23

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 17 May '16

17 May '16

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

1 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 17 May '16

17 May '16

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

1 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 17 May '16

17 May '16

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

1 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 16 May '16

16 May '16

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 *****************************************/ > > >

1 0

Abuse filter bans legit users and ignores spamers
by Alexander Rechitskiy 16 May '16

16 May '16

1 0

https://code.reactos.org/ is down
by Alexander Rechitskiy 13 May '16

13 May '16

2 1

CAPCHA does not work
by Alexander Rechitskiy 13 May '16

13 May '16

2 1

Build Crash ProgMan
by James Tabor 12 May '16

12 May '16

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.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev