Hello,
Last thursday of this month is quite close, 30th of June, 20:00 UTC
I'm awaiting you all for the monthly status meeting. Colin said that
our private irc server is going to be ready by that date, so if
that's still true, Colin - could you please provide details for those
who don't remember where to connect?
Proposed agenda is:
1. New release of ReactOS
2. Website work status
3. GSoC status
4. Developers status.
With the best regards,
Aleksey Bragin.
I'm definitely not sure that the header[1] added to all converted files was absolute necessity.
AFAIK, that's SVN logs purpose...
Unless someone has a real justification to such line?
Many files even don't have a translator copyright but this line... Weird!
[1]: /* UTF-8 Conversion: Elton Chung aka MfldElton <elton328(a)gmail.com> (June, 2011) */
Hi Erik,
The NDK is for *undocumented* types. These flags are documented.
--
Best regards,
Alex Ionescu
On 2011-06-26, at 7:29 AM, ekohl(a)svn.reactos.org wrote:
> CM_RESOURCE_INTERRUPT_LEVEL_SENSITIVE
Hello,
as all of you could notice, I committed the LDR rewrite recently. I
tried to get rid of as much regressions as possible (any rewrite
should introduce improvements of course, rewrites are not done to
introduce regressions, however there is no rewrite without some
particulars problems).
So, dear developers, I need your help. Gabriel did a very nice work
and bugzilled all kinds of problems which new LDR introduced. Here is
the meta-bug:
http://www.reactos.org/bugzilla/show_bug.cgi?id=6346
Please look into the bugs, check something and add your findings to
bugzilla. The new LDR code is perfectly organized, very well
documented, so most of those bugs should be quite simple to fix, but
my time is not infinite, so I'm asking for collaboration. I'm always
available via IRC for any questions about the new code, so feel free
to ask.
Put away your usual stuff for an hour or for a day and look into
those. It would help greatly and motivate me to finish other parts of
the rewrite quicker.
Thanks,
Aleksey Bragin.
Hi sir_richard and welcome back!
Just to make sure you know, it seems this commit introduces a regression, ros hangs while loading ndis.sys, see testbot logs:
http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/1342/s…
I've filed http://www.reactos.org/bugzilla/show_bug.cgi?id=6292
Could you please take a look?
Thanks.
> Date: Sun, 5 Jun 2011 20:48:34 +0000
> To: ros-diffs(a)reactos.org
> From: sir_richard(a)svn.reactos.org
> Subject: [ros-diffs] [sir_richard] 52098: [FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms wou...
>
> Author: sir_richard
> Date: Sun Jun 5 20:48:34 2011
> New Revision: 52098
>
> URL: http://svn.reactos.org/svn/reactos?rev=52098&view=rev
> Log:
> [FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms would build FreeLDR "page entries" for every page from 0 to 0x7FFF0000 and mark it as unusable, then build the actual valid entries from 0x80000000 -> end of RAM, thus resulting in large memory consumption (and in the bloat of the PFN database later once NTOS loads) and boot time. Therefore, the algorithm is changed to start the PFN database at the lowest valid RAM page described by the Firemware descriptors, and entries therefore will be offset. This means a 128MB embedded system no longer appears to have 2048+128MB of RAM worth of PFN entries.
> NOTE: Windows does not do this, opting instead to force manufacturers/use pull-up resistors/reconfigure the ARM Bus to map RAM at 0x00000000. For wider portability, I believe it makes more sense to simply do this "trick" in the boot loader.
>
> Modified:
> trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c
> trunk/reactos/boot/freeldr/freeldr/mm/meminit.c
>
Hi,
I'd like to change the Vtbl based architecture of freeldr into a normal
function call system.
Currently we have stuff like
#define MachHwDetect() MachVtbl.HwDetect()
MachVtbl.HwDetect = PcHwDetect;
This is IHO simply useless, since these functions don't change. I
suggest simply renaming PcHwDetect to MachHwDetect and do that will all
of those and get rid of the MachVtbl.
Any objections?
Regards,
Timo
gedmurphy(a)svn.reactos.org wrote:
> +// WIDL temp hack : [...]
Even though we all like to see a full MSVC build in the future, does
this really justify such an even bigger hack on top of the existing
ones? Would a proper fix really require that much more time?
If we don't want to end up in a new mess, this pretty much forces
someone to fix it in the coming days or the hack/commit will be
forgotten again. I'm certain about this, because nobody on #reactos-dev
really knew the reason behind the older __ROS_LONG64__ hack either.
Alternatively, you could open a detailed bug report about this issue and
assign some CMake people to it. But in any case, such hacks should be
tracked in our Bugzilla, in particular when more information about a
solution is known already.
- Colin
Hello all,
Edijus from #reactos has just tried ReactOS on his system, but the boot
process got stuck at "usbdriver.sys". When reading his notice, I was
wondering why we still include this ancient driver in every ReactOS build.
As far as I know ...
* it has never worked for us
* it is incomplete and not well-tested
* it has obvious code bugs (e.g. just look in ehci.c:3465 how it
enumerates more PCI devices and functions than possible,
consequently enumerating the first function twice due to bitshifts)
* better USB work by Johannes and Michael is progressing well
Although it might be useful as a testcase for the legacy HAL functions
(like HalAssignSlotResources), it should still be removed from the build
process for now.
If there are no objections, I'll do this change on the weekend.
- Colin
Hi,
While taking a short break from my GSOC work, I like to do some work on
freeldr.
Final goal is to make it work with MSVC, but first I'd like to do a
little cleanup, since its a bit messy.
First I'd like to know how the state of the old bootcode is and if we
still need it and whats left to do to get rid of it.
Then I'd suggest to remove the code that draws purple unicorns like it
was done for ARM (afaik, we don't use it anyway)
I'd also like to fix formatting (tabs -> spaces)
Any remarks, objections, wishes, doubts?
Regards,
Timo
Thanks for being that efficient for reverting.
Less than two days after message on ML. Congratz.
Next time I take days off, I won't take four days any longer, in case you would question some other of my patches.
I'll also send you my next patches, that way you'll be able to commit them, or just to skip them to prevent any revert.
Hi all,
I write this mail with great sadness, but I've recently been informed
that Ge Van Geldorp, one of the original and important contributers to
the ReactOS project has recently passed away.
Having met up with him personally, I can say with some confidence that
he was not only blessed with an impressive skill in the hobby /
industry we all love, but was also a man of great integrity.
Being one of my original mentors in reactos, and having spent time
busting our guts at various linux projects with him trying to convince
the unix fanatics of the merits of NT, I can assure you that this he
was both a great colleague and friend. I'm sure all the old school
reactos devs would more than agree.
I propose we have some sort of eulogy on our homepage. I'd be more
than willing to compose something.
If people would like to send their thoughts, wishes or memories, I'd
be more than happy to compile them.
Ged.
Hiya
Managed to find Greg brother's letter to Wine, with bit more details regarding this tragedy. Since GvG was also our man, not only Wine's, perhaps some collaborative effort could be set to commemorate him.
With best regards
Caemyr
-------- Original Message --------
Subject:
Date:
From:
To: RE: Ge van Geldorp
Thu, 9 Jun 2011 23:05:46 +0200
Erven Gé van Geldorp <erven.van.geldorp <at> gmail.com>
'Paul Vriens' <paul.vriens.wine <at> gmail.com>
Hi all,
My name is Arno van Geldorp. I’m the brother of Gé (Greg) van Geldorp. I’m very sorry that I have to inform you that Greg has passed away almost 3 weeks ago. 2 Months earlier he was diagnosed with cancer in a very aggressive form.
I know he made his contribution to the Wine project. And that one of them is the WineTestBot. His passing away went so fast that he didn’t have the time to inform me all about it. What he did ask me is to make sure that the server where the WineTestBot is running on will be hosted for at least 2 more years. So we will take care of that. But I don’t know if anyone took over the administration off the server.
If anyone took over the administration from Greg could you please contact me at erven.van.geldorp at gmail.com
Kind regards,
Arno van Geldorp
Am 09.06.2011 15:56, schrieb tkreuzer(a)svn.reactos.org:
> Author: tkreuzer
> Date: Thu Jun 9 13:56:44 2011
> New Revision: 52156
>
> URL: http://svn.reactos.org/svn/reactos?rev=52156&view=rev
> Log:
> [BOOTSECTOR]
> - export obj2bin on gcc builds, too
> - Add new macro CreateBootSectorTarget2, which uses portable assembly and use it with isoboot.S. I will replace all bootsectors with the new code one at a time, and in the end we can eventually drop nmake
> - add wrapper isobtrt.S, which defines ROS_REGTEST and includes isoboot.S
>
I mean of course "drop nasm" not "drop nmake"
The notification routine can change the list, as there is no lock involved.
Therefore, you should grab the next entry before notifying the driver, to maintain a consistent list state.
--
Best regards,
Alex Ionescu
On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote:
> + DriverNotificationRoutine(DeviceObject, TRUE);
> +
> + /* Go to the next entry */
> + ListEntry = ListEntry->Flink;
Hiya
The today's failure of my slaves can be explained two-way.
First, buildslaves (windows ones especially, but not only) seem to be very vulnerable to ping dropouts. A single icmp drop is resulting in build interruption.
Second, the hetzner.de hosting is dropping packets from my provider (atman.pl) all the way from teleport to reactos host, at a rate of one every few minutes or even more.
Combined those two, any build started at the moment is dropped after 2-3 minutes of runtime.
I have no idea if the network issue is temporary or not, thus no chance to predict when we will continue with runtime, Any ideas?
With best regards
Caemyr