I had the same problem on real hardware.
I removed serenum & serial.sys and the system could boot again.
I dont know if the problem is into serenum or serial though.
hpoussin, it seems the solution is in your hands ;)
--- Saveliy Tretiakov <saveliyt(a)mail.ru> wrote:
> revision 14561 can't boot on vmware 4.5
> debug output is attached
> > _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
Some bioses set numlock to on at startup.
Since ReactOS is setting it to off state,
the LED status must be set accordingly.
Attached patch fixes it.
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
Hi,
I am currently entering the last 5 weeks of school of my last year, so
I'm going to be focusing on that instead of ReactOS. Lately, I've tried
to work on both, but this has delayed my code as well as hurt my grades.
I intend to be back around the week of May 10th.
In the meanwhile, I would kindly like to ask developers to e-mail me if
they have any plans to touch the following:
- Kernel Scheduler, Thread Creation, Context Switching, System
Initialization. I have re-written everything for a faster and more
complete system based on NT semantics. Includes everything from realtime
support, proper dynamic and static priorities, real system thread
support, much faster scheduling, pre-emption, removal of the PEB/TEB 64K
block hack and ros-only members, better organized code and Mm routines
for manipulating kernel stack/teb/peb, etc...
- Pushlocks. I have almost all the necessary support code written and
I'm only missing one function.
- IRQL management in HAL and Spinlocks. I have highly modified the IRQL
routines for a large increase in speed, as well as made spinlocks faster
on UP and non-debug builds. I have also corrected some IRQL routines to
use the proper KPCR members for the IRR and others.
- Object Manager. I have a complete re-write in progress which uses
public NT structures instead of our internal ones, adds more security,
and corrects some missing features and adds some. Majorly changes some
aspects of the Ob (for example regarding on the status of handle/pointer
count after creating an object, and the work of ObCreate/ObInsertObject,
which is totally different in ROS vs NT. See blog article for more
info). However, any bugs that are easy to fix should still be fixed in
the current Ob. The new one is months away.
- Queued Spin Locks, KGATES, Guarded Mutex. I already know Filip is
working on this and I was planning on collaborating with him. Unlike the
previous things, I haven't actually *coded* anything regarding these,
but I have the design in my head and would like to work on it, so I
would love to share what I know if anyone is actively interested in
working on it.
Once again, to clear up any misconceptions, I'm asking an email to know
if anyone plans to work on this for the purposes of:
1) Not duplicating work
2) Sharing what information/code I might have written.
In any case, I'll be back in exactly one month, so I don't think it'll
matter. You guys keep focusing on PnP and other stuff meanwhile, okay?
*joke*
Best regards,
Alex Ionescu
Hi all.
This is my changes :)
serialui
- Started serialui dll
- Implemented drvCommConfigDialogA and drvCommConfigDialogW
kernel32.diff
- Implemented CommConfigDialogA and CommConfigDialogW
- Removed @unimplemented comments for some implemented functions
include.diff
- Add missing ioctls to ntddser.h:
IOCTL_SERIAL_GET_COMMCONFIG and IOCTL_SERIAL_SET_COMMCONFIG
btw.
Screenshot is here:
http://www.ljplus.ru/img2/drg4njubas/commdlg.JPG
Hi,
it'd be nice if something like
r14554: Delete riched20
r14555: Copy riched20
can be avoided in preference of the *cause* the required the changes above.
Everybody can see that riched20 was deleted and added afterwards but you
cannot see *why* this has been done.
Regards,
Mark
I'm not sure what the current state of ReactOS' GDIPLUS.DLL implementation
is, and I know it's just a case of downloading the DLL from Microsoft for
the functionality, but I've been recently looking into making a mini GUI
API for a program I'm working on, and the author informed me someone is
making a GDIPLUS.DLL clone, using Anti-Grain:
www.antigrain.com
I'm unsure what the URL was for the project as I'm not at home at the
moment, but I figured if GDIPLUS.DLL needs some work in ReactOS, it would
be a good starting point to use the one based on Anti-Grain, as apparently
the one from MS is slower and has a few glitches (see the demos on the
Anti-Grain site - specifically the one with the arrows pointing at the
different blobs.)
Just thought it might be worth a mention :)
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
--- Mark Junker <mjscod(a)gmx.de> wrote:
> r14554: Delete riched20
> r14555: Copy riched20
>
> can be avoided in preference of the *cause* the required the changes above.
>
> Everybody can see that riched20 was deleted and added afterwards but you
> cannot see *why* this has been done.
This was because it was a merge from the trunk and when importing Wine code on the trunk you have
to delete the existing copy and import from the vendor branch.
Please read
http://reactos.com/wiki/index.php/Using_code_from_other_projects
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
I can imagine the News:
BIG CORPORATION SUES A GROUP OF COLLEGES FOR
DEVELOPING A NEW WINDOWS.
MICROSOFT THREATENS A LITTLE NON PROFIT PROYECT!
MICROSOFT AGAINST LIBRE SOFTWARE!
This has the chance to make microsoft more damage than
you think they can do to ReactOS, unless they feel
really threatened i doubt there will be any microsoft
legal atack unless you use clearly microsoft code in
the near or intermediate time.
>
----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 7 Apr 2005 13:31:19 -0700 (PDT)
> From: Steven Edwards <steven_ed4153(a)yahoo.com>
> Subject: Re: [ros-dev] ReactOS Foundation 501c3
> Status - Approved
> To: ReactOS Development List <ros-dev(a)reactos.com>
> Message-ID:
> <20050407203119.68427.qmail(a)web21121.mail.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hi James,
>
> --- James Tabor
> <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net>
> wrote:
> > Paying developers? Hum?
> >
> > I don't want to be the bad guy here, but this
> could push people away from the project. It would
> > be
> > like going back to five years ago when ROS had no
> GUI just a command console. Everyone will wait
> > for five or so developers to fix things, and trust
> me it does happen that way in the real world.
> > The back log will kick their asses.
>
> See the other thread. I don't think paying
> developers as full time workers is a good idea. I
> think
> Contracts or bounties on certain projects are.
>
> > Now I have to ask, where does the money come from?
> If the ORG has no money, I guess it should
> > produce a competing distribution CD. This could
> make M$ happy, so M$ would have a target to
> > sue at. Also everyone on the board would become a
> target as well.
>
> I was wrong in the other email. I forgot we have $25
> in the general fund atm which was raised at
> LinuxWorld. I expect we can make quite a bit selling
> CDs, T-Shirts, Etc, if we want as well as
> just accepting donations. As for the fear of
> lawsuit, the idea behind the foundation was that it
> was better the foundation get sued and try to have
> some cash for legal defence rather than some
> poor developer in school. Everybody here knows the
> risk from Microsoft....
>
> Thanks
> Steven
>
______________________________________________
Renovamos el Correo Yahoo!: ¡250 MB GRATIS!
Nuevos servicios, más seguridad
http://correo.yahoo.es
