hpoussin(a)svn.reactos.org wrote:
> Author: hpoussin
> Date: Tue Oct 3 22:04:03 2006
> New Revision: 24379
>
> URL: http://svn.reactos.org/svn/reactos?rev=24379&view=rev
> Log:
> Copy i8042prt driver from 0.3.1 branch to trunk. Try #2
>
> Added:
> trunk/reactos/drivers/input/i8042prt/
> - copied from r24378, branches/ros-branch-0_3_1/reactos/drivers/input/i8042prt/
>
>
Why are we copying it from branch to trunk? Shouldn't it be copied from
trunk to the branch?
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
Sometimes pictures speak better then commit messages, so here's the
current boot status:
http://www.tinykrnl.org/ros_by_ntldr.png
It fails because our Memory Manager early-boot initialization depends on
some freeldr information. If I can/have time, I'll try to make it not
depend on them, and/or use NTLDR structures instead.
Anyways, serial debug printing works and the GDT, IDT, TSS, KPCR are all
setup, so this can now be used as a good tool for blackboxing ntldr.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
Hi,
I took a break from the project hoping any regressions I might've caused
could be found/fixed... isntead, I now find myself with an OS that won't
recognize my mouse/keyboard. I've tried rebooting it to re-start 2nd
stage (which used to work before), but all this does is gradually damage
the registry more and more, either leading to aSSERTs or freeldr
codepage error.
This is with a 100% clean trunk on QEMU 0.8.2.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
Hello list!,
i have two questions that i hope that someone of you could answer.
The first one:
- Should RegOpenKeyExW() do a SetLastError() or it just return an
error code?
I ask this because in the timedate control panel applet,
GetSyncSetting() reads a key from the registry using that function
and if it fails it calls the function GetError() that calls
FormatMessage() using GetLastError() as an argument. For some
reason in my computer this call fails and i receive an window
that says "ERROR_INVALID_WINDOW_HANDLE" that obviously is not
the right error code.
This bug could be reproduced by double clicking in the Hour
located in the right corner of the start menu bar. Next you
click the Internet Time tab and you should receive the error.
To fix this i can think of two possibilities:
- Modify RegOpenKeyExW() to do a SetLastError() if this fails
to set a right code for GetLastError(), or
- Modify the GetError() function in the timedate control panel
applet
I don't know which is the right way to fix this.
Finally in my opinion, if an error occurs in this situation
i think that no message should appear because i think that
is not too bad if this key isn't present.
And the second question follows...
- I have written a program that displays a Status bar using
the DrawStatusText() function. In Windows it is working pretty
well but in ReactOS it doesnt. DrawStatusText() in ReactOS doesnt
draw a background when calling this function thus my status
window draws over itself each time i receive a WM_PAINT message.
So its clear that in windows DrawStatusText() draws a background
before painting the text, but in ReactOS it doesnt. Currently i
have hacked the DrawStatusText() function to draw a background
like this:
void WINAPI DrawStatusTextW (HDC hdc, LPRECT lprc, LPCWSTR text, UINT style)
{
RECT r = *lprc;
UINT border = BDR_SUNKENOUTER;
HBRUSH hBkBrush, hOldBrush;
if (style & SBT_POPOUT)
border = BDR_RAISEDOUTER;
else if (style & SBT_NOBORDERS)
border = 0;
DrawEdge (hdc, lprc, border, BF_RECT|BF_ADJUST);
/* now draw text */
if (text) {
int oldbkmode = SetBkMode (hdc, TRANSPARENT);
UINT align = DT_LEFT;
if (*text == L'\t') {
text++;
align = DT_CENTER;
if (*text == L'\t') {
text++;
align = DT_RIGHT;
}
}
r.left += 3;
if (style & SBT_RTLREADING)
FIXME("Unsupported RTL style!\n");
// yep this fixed the problem, but i don't know what the
// right color it is
hBkBrush = GetSysColorBrush(GetSysColor(COLOR_BTNFACE));
hOldBrush = SelectObject(hdc, hBkBrush);
FillRect(hdc, lprc, hBkBrush);
DrawTextW (hdc, text, -1, lprc,
align|DT_VCENTER|DT_SINGLELINE|DT_NOPREFIX);
SelectObject(hdc, hOldBrush);
SetBkMode(hdc, oldbkmode);
}
}
Attached i send the code that shows this "bug" and a precompiled binary.
Also i have tested this program under WINE with the same results
(0.9.x i think).
Thats all,
Best regards,
Felipe Villarroel
--
_______________________________________________
Get your free email from http://www.linuxmail.org
Powered by Outblaze
hpoussin(a)svn.reactos.org wrote:
> Author: hpoussin
> Date: Thu Sep 28 20:33:12 2006
> New Revision: 24286
>
> URL: http://svn.reactos.org/svn/reactos?rev=24286&view=rev
> Log:
> Support mount manager in disk.sys
>
> Modified:
If you're going to add this kind of support, I'd appreciate it if you
took a look at TinyKRNL/WDK to see how this should be done. FTDISK is
responsible for all the code you've added, not disk.sys, and if we're
going to implement NT5+ Storage stack features on top of an NT4 driver,
this will mean either one of these two things:
1) A crappy "ROS" stack that's incompatible with anything NT offers (and
the storage stack is heavily documented in NT, so we're at a big loss if
we do this).
2) Someone will have to eventually re-write even more code to make it
compatible.
I suggest you work on implementing an XP/2K3 style classpnp driver
first. The WDK and TinyKRNL have sample source code (non-reversed), and
there's 50 pages of documentation on it.
Once that works, a new disk.sys can be written (same information as
above is available).
Then ftdisk should follow. It handles all Fault-Tolerance stuff, but
about 6000 lines of it are responsible for the glue layer between the
storage stack. TinyKRNL has just finished implementing it, so the
information and documentation located there should be helpful (using
TinyKRNL documentation and code for learning purposes is fully in-line
with our IP policy and the whole point of the project).
Then partmgr, mountmgr can be written. These are also implemented in
TinyKRNL completely. (Except GPT support).
Finally, some parts of the kernel's IoMgr needs to be changed in the
method in which it sets up disk letters, and kernel32 needs some new
code (which Filip has on his disk).
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
Dear Friends
Here I am again. I would like to prepare the CD with ReactOS live. But I
need a description - how to instal, why use it, how use it, what works on it
etc for our readers.
Please let me know if someone can help us and write it.
Best Regards
Kate
www.mscoder.org/es
---
Katarzyna Chauca
Market Manager
Editorial Software
0048228871457
Hi,
Sylvain Petreolle wrote:
> Hi James,
> why dont you try the new driver ?
> (drivers/usb/nt4compat/usbdriver)
I guess I can try it. I moved the drivers out of the directory and the system just sit there
doing nothing.
Thanks,
James