gdalsnes(a)svn.reactos.com wrote:
> alloc at minimum 16 bytes (spotted by WaxDragon)
> realloc should free passed mem if new size is 0
>
>
> Updated files:
> trunk/reactos/lib/crt/stdlib/malloc.c
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-svn
>
>
This fixes the bug in windres, right?
Best regards,
Alex Ionescu
> From: mf(a)svn.reactos.com
>
> create some start menu entries for notepad, regedit and winefile
Do we really need/want the winefile link on the desktop? Especially since it
is also present in the start menu now. If I recall correctly, the Command
Prompt was put on the desktop 'cause at the time it was the only viable way
to start programs, I think maybe even the Command Prompt link could go from
the desktop now.
Gé van Geldorp.
I've been thinking about a chat I had with Alex Ionescu about the
"userspace driver framework" that MS has put in Windows Vista for a
couple of days now. Mostly I was trying to think of how they could
create a secure system where the drivers could live outside the
kernel and still manage to do the job of providing clean access to
the hardware.
I was doing this because I am just starting to take a look at the
ReactOS code with an eye towards helping on the project. That being
the case I decided to see if I could find a spot where I could fit my
skills into the project. While I'm more geared towards fixing bugs or
filling out places marked "TODO" the thought of userspace drivers -
or rather, just the thought that such a system would allow for
drivers that could die and not take the system with them - has caught
my interest.
At the current time the only way I can see this being done is by using
the HAL to abstract all hardware and providing an API that, via the
HAL, will allow for _AUTHENTICATED_ programs (aka drivers) to
register themselves with the kernel and provide access to said
devices. The access itself would best be handled by the drivers
registering an interface that programs can use to call directly into
the driver.
This just leaves me with a simple problem to solve - should the
interface be a COM/COM+ interface (or it's primitive, since I don't
think anyone wants the lag having COM/COM+ in the kernel would cause)
or should it be something simpler, like a UFS path ?
DRH
(if the PGP signature looks bad, the list probably modified the mail)
After copying the files over in stage 1 installer i get the error
"Failed to create regisrty hives". This is off a clean build i am
doing(RosBE), same result when i download a iso from sin. any advice?
Brandon
As according to our voting rules, any permanent developer may vote on
this for one week as of now.
Should the flow control macros for looping double linked lists be
allowed in ntoskrnl?
[ ] Yes
[ ] No
More on voting can be found at: http://www.reactos.com/wiki/index.php/Voting
Just a quick report from LinuxWorld London. We've just finished
the first day of the exhibition, lots of interest. What surprised
me a bit was that the general awareness about the project was
somewhat lower than last year in Frankfurt. I guess that 80-90%
of the people we spoke last year had already heard about the
project, that percentage was a lot lower here (more around 30%).
Another pleasant surprise was the stability of the system. We ran
it on an old laptop with a few applications: Quake 1, WinZip,
IrfanView, AbiWord. On demand we showed some other apps like
regedit, notepad, task manager. The system froze one time when
a visitor played around with it, other than that no problems at
all. Not a single kernel crash. We had to Tab-K to force a kernel
check to show the BSOD to a visitor. I say let's bring out r18189
(I think...) as 0.2.8 (j/k).
People were reacting very nicely. It was nice to see them
picking up a flyer rather uninterestedly, start to read, and
then suddenly turn back to watch the demo when they realized
what the project was all about.
Ge van Geldorp.