A simpler fix would be to a change of the BootDrive value to 0xFF.
As you said, the current value is 0,
but thats by design,
since all the values have been filled for a 1.44M diskette.
Even the File System ID could have been set differently,
since the neutral value 'FAT ' is allowed here.
--- Phillip Susi <psusi(a)cfl.rr.com> wrote:
> Well, I finally solved my problems with getting freeldr to boot from a
> hard drive. The first is a problem with fat.bin itself. Early during
> it's execution it checks to see if the boot sector header specifies a
> device ID of 0xff, and if so, it uses the device ID the bios passes in
> CL when it invokes the boot sector, otherwise it uses the device ID in
> the boot sector header. The device ID field of the boot sector is
> inherently unreliable and should NEVER be used. In my case mtools was
> leaving it as it was in fat.bin, which is 0, so it was trying to access
> the floppy instead of the hard disk. I have fixed this by removing the
> check to see if the field is 0xff, so the code will always use the
> device passed by the bios.
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
phreak(a)svn.reactos.com wrote:
>Fixed freeldr fat16 boot sector to use the bios provided boot device number instead of the ( usually invalid ) one in the boot sector header.
>
>
Could you please fix that also in the fat32 bootsector?
Best Regards,
Thomas
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