I've just managed to get hold of a copy of VMWare 5.0 through work.
I'll install a copy tonight and see how that goes.
Ged.
-----Original Message-----
From: ea [mailto:ea@iol.it]
Sent: 14 April 2005 23:18
To: Jason Filby; ReactOS Development List
Subject: Re: [ros-dev] crash on ROS vmware install
On the 13th, in QEmu I had a stop due to serial.sys
http://users.libero.it/ea/ros/qemu-ros-200504130002.jpg
On IRC, Hervé said he's working on it.
Jason Filby wrote:
>Hi
>
>I'm getting a similar crash under QEmu.
>
>Cheers
>Jason
>
>On 4/14/05, Gedi <gedi(a)ntlworld.com> wrote:
>
>
>>Source taken from HEAD just before Casper took it down for the rebuild.
>>
>>Initially it was hanging just after the splash so I rebuilt with DGB to
>>see if I could glean more info.
>>
>>Now it crashes upon install, just before it goes to the GUI config.
>>
>>Here is a sceenshot of the crash
>>http://homepage.ntlworld.com/gedmurphy/crash.jpg
>>
>>I have attached the map files for smss. I would have stuck on one for
>>ntoskrnl too, but it's a little large.
>>
>>
The map file is for the production SM: the one in the blue screen is the
1st stage (text) setup program (in the boot disk it get renamed to be
run by ntoskrnl with no changes).
Emanuele
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Since two days I released the RC2 to sf.net
What's our plan for the next release (candidate)?
As you may see, I went to RAR concerning sources and map files. I don't
know whether this is such a good idea. At least the size relation
convinced me. Map: 17MB vs. 30MB or Src: 15MB vs. 27MB
I think for people still working with modem this is an advance (even if
they have to search to unrar). The difference in sizes seems to me is
the solid kind of archive. Thus tarbz2 should do the same
Comments?
Thanks Dmitry, I'm cc'ing our dev team on this :)
Cheers
Jason
On 4/13/05, Dmitry Viktorovich Long <dvd.long(a)gmail.com> wrote:
> Yes.
> ReactOS is the most f**king BEST product I've ever seen. Great thanks
> to all of you. Do not ever stop, don't even think it.
>
> Best regards, ReactOS fan.
>
I've been doing a bit of work on the usetup code and came to realize
that we have a bit of a widespread problem in a lot of code. There is a
great deal of code that looks basically like this pseudo code:
NSTATUS DoSomething()
{
NSTATUS Status;
...
Status = NtXXX();
if( !NT_SUCCESS( Status ) )
return Status;
Status = NtYYY();
if( !NT_SUCCESS( Status ) )
{
cleanupXXX();
return Status;
}
Status = NtZZZ();
if( !NT_SUCCESS( Status ) )
{
cleanupYYY();
cleanupXXX();
return Status;
}
// yay, everything worked
cleanupZZZ();
cleanupYYY();
cleanupXXX();
return STATUS_SUCCESS;
}
This type of error handling is absolutely horrible. Just look at all of
the duplicate code! There are 3 different return points and each one
duplicates all of the code from the previous, and adds one more line.
Maintaining code like this becomes very hard, and it produces a larger,
slower executing binary.
Now ideally all of those NtXXX functions would be throwing a SEH
exception on failure instead of returning the failure code, and we could
just write that code like so:
void do_something()
{
__try {
NtXXX();
NtYYY();
NtZZZ();
// manipulate the stuff you allocated
}
__finally {
cleanupZZZ();
cleanupYYY();
cleanupXXX();
}
}
But sadly, I don't think that is ever going to happen. Instead, I
propose that we use goto to eliminate the duplicate points of return,
and wrap the goto in a nice macro. So far I've come up with this macro:
#define NTCALL(target, function) if( Status = function ) goto target;
And you use it like this:
NTSTATUS do_something()
{
NTSTATUS Status;
NTCALL( done, NtXXX(...) );
NTCALL( cleanXXX, NtYYY(...) );
NTCALL( cleanYYY, NtZZZ(...) );
// manipulate x, y, and z here
cleanZZZ:
cleanupZZZ();
cleanYYY:
cleanupYYY();
cleanXXX:
cleanupXXX();
done:
return Status;
}
Now that code is more compact and maintainable than the original, and
will produce a leaner binary. I'm still trying to improve on it a bit
but I like this basic idea, so I'm throwing it out for comments. Last
night I came up with this macro and in about 10 minutes I rewrote the
file copy routine in usetup to use memory mapping instead of allocating
a huge buffer, reading in the source file, then writing it out to the
destination. The new code involves making several more system calls
than the old code, but since the error handling has been greatly cleaned
up, the new code is more compact and easier to maintain.
Hi all.
On 13.04.2005 at about 09:00 CET, I'll be taking svn.reactos.com down for reconfiguration of RAID and installation of Service Pack
1.
I expect the repository to be operational within 8 hours.
Casper
hey arty,
seems you forgot to commit one file :
rosdhcp_public.h
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
Hi,
today I was pointed to an article in the austrian newspaper named "Der
Standard" about ReactOS:
http://derstandard.at/?id=2010724
It's quite short, but what if not even heise.de reports?
Hi,
why do you change this file? Alloca.c isn't used and should be removed.
If we have an alloca function somewhere in our source, it must be
completely written in assembler because the stack layout and the using
of ebp depends on the compilers optimisation.
- Hartmut
arty(a)svn.reactos.com wrote:
>Commit for blight: fix stack alignment.
>
>
>Updated files:
>trunk/reactos/lib/crtdll/stdlib/alloca.c
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
>
