May these VESA drivers be useful for ros testing ?
----- Message transféré ----
De : Jan Jezabek <jezabek(a)poczta.onet.pl>
À : qemu-devel(a)nongnu.org
Envoyé le : Mercredi, 18 Avril 2007, 21h25mn 40s
Objet : [Qemu-devel] Re: QEMU drivers repository
Natalia Portillo wrote:
> Hi all,
> I have collected all drivers I could for GD-5446 in
> http://www.claunia.com/qemu/drivers/index.html
>
Hi,
If you're interested in NT 3.51 you can find a graphics driver here:
http://www.navozhdeniye.narod.ru/vbemp.htm
It's a generic VESA driver, but it was the only one I could find that
supported high resolution true-color display in NT 3.51, so maybe it's
worth to put a link on your page.
As for network - I had a good experience with the Realtek 8029 drivers:
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=15&PFi…
WBR,
JJ
Hi Peter,
it's a good idea to post an explanation here (might be someone will edit
this into a page in our wiki).
1. Traditional DPRINT debug printing ("old way"): All source code files have
an #define NDEBUG atop of them, a developer could get a detailed tracing of
function calls inside this src code file. DPRINT1()s are used when that code
branch must always notify a user / developer (examples are: critical error,
not fully implemented branch with a reminder to finish implementation, and
any other kind of a situation which occurs rarely and may have a severe
impact on a system).
2. "Wine-way" of debug print messages. The printing is done using three
macros: TRACE(), WARN(), ERR(). Respectively, TRACE() is the most frequently
printed, WARN() is less frequently, and ERR() is an equivalent of a
DPRINT1() - always printed, in error situations.
In order to enable TRACE() and WARN() debug prints, one must add a #define
YDEBUG to the respective place inside an interesting source code file. (Wine
has a concept of debug channels, which can be turned on and off, however
ReactOS for now does not implement this).
3. Other ways exist, specific for drivers / applications (e.g. for miniport
/ port / class drivers, client drivers usually use their class's driver's
debug print routine, a custom one, having custom severities levels).
4. Newer ways of debug printing (kernel-specific, look for debug channels in
windows 2003, debug printing in Vista, -- OSR magazine had a nice article
about these).
WBR,
Aleksey Bragin.
----- Original Message -----
From: <breakoutbox(a)web.de>
To: <Ros-dev(a)reactos.org>
Sent: Thursday, April 19, 2007 4:21 PM
Subject: [ros-dev] DbgPrint() - DPRINT() - DPRINT1()
> Hello,
>
> can please anybody explain me how You want DbgPrint() - DPRINT() -
> DPRINT1() to be used ?
> I found a lot of DPRINT() _for_example_ in "win32/in32k/objects/dc.c" but
> it is not shown on serial debug (?)
> (and also SOME ot these DPRINT1() .. )
>
> 1)
> If I use DPRINT1() instead, it is always shown.
> If I use DbgPrint() instead, it is only shown when #DEBUG is defined in
> the file + in *.rbuild
> But what's the sense of DPRINT() then ?
> =>
>
> 2)
> 2nd stage: on installing from BootCD I can see serial debug only when I
> select DEBUG from startup options.
> Is this DPRINT1() suppressed when I DON'T select DEBUG ?
>
> 3)
> Why is there not one DbgPrint() in "win32/in32k/objects/dc.c" (and also in
> other files in /DRIVER/ and /NTOSKRNL/ ..) ?
> I now have to change every serial debug output to be able to see anything
> .. ( if You don't explain me ... ;-) )
>
>
> Best regards,
> Peter.
Hello,
can please anybody explain me how You want DbgPrint() - DPRINT() - DPRINT1() to be used ?
I found a lot of DPRINT() _for_example_ in "win32/in32k/objects/dc.c" but it is not shown on serial debug (?)
(and also SOME ot these DPRINT1() .. )
1)
If I use DPRINT1() instead, it is always shown.
If I use DbgPrint() instead, it is only shown when #DEBUG is defined in the file + in *.rbuild
But what's the sense of DPRINT() then ?
=>
2)
2nd stage: on installing from BootCD I can see serial debug only when I select DEBUG from startup options.
Is this DPRINT1() suppressed when I DON'T select DEBUG ?
3)
Why is there not one DbgPrint() in "win32/in32k/objects/dc.c" (and also in other files in /DRIVER/ and /NTOSKRNL/ ..) ?
I now have to change every serial debug output to be able to see anything .. ( if You don't explain me ... ;-) )
Best regards,
Peter.
_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
----- Original Message -----
From: "Lucio Diaz" <reactos_translate(a)yahoo.es>
To: <ros-dev(a)reactos.org>
Sent: Wednesday, April 18, 2007 11:08 PM
Subject: Re: [ros-dev] Ros-dev Digest, Vol 32, Issue 12
> -Irony on- I suppouse that copying each individual
> resource file, every time it is updated, dont waste
> developers time.-Irony off-
I don't want to disappoint you even more, but there is a whole concept of a
so-called patches (or diffs), which are the thing to be placed in bugzilla,
not whole files.
I suggest some investigation in this area, like
http://en.wikipedia.org/wiki/Patch_%28Unix%29 (it's automated on win32 using
TortoiseSVN for example, in GUI mode, etc). And in general about version
control systems, bug tracking systems, changesets, and other related terms.
WBR,
Aleksey Bragin.
Hi!
FYI:
Real hardware boot log,
(ntoskrnl\kd\kdio.c:193) -----------------------------------------------------
(ntoskrnl\kd\kdio.c:194) ReactOS 0.4-SVN (Build 20070417-r26382)
(ntoskrnl\kd\kdio.c:195) Command Line: DEBUGPORT=COM1
(ntoskrnl\kd\kdio.c:199) ARC Paths: multi(0)disk(0)rdisk(0)partition(1) \
multi(0)disk(0)rdisk(0)partition(1) \ReactOS\
(ntoskrnl\ke\i386\cpu.c:518) Not handling AMD caches yet
Used memory 1015744Kb
(ntoskrnl\se\semgr.c:36) FIXME: SeAccessCheck has been HACKED to always grant access!
(ntoskrnl\se\semgr.c:37) FIXME: Please fix all the code that doesn't get properrights!
(ntoskrnl\ke\i386\kiinit.c:43) Large Page support detected but not yet taken advantage of!
WARNING: HaliQuerySystemInformation at hal\halx86\generic\sysinfo.c:26 is UNIMPLEMENTED!
(ntoskrnl\ke\i386\patpge.c:62) Advanced Memory features detected but not yet taken advantage of.
(ntoskrnl\ke\i386\mtrr.c:24) Your machine supports MTRR but ReactOS doesn't yet.
0 bytes requested - initiating pool verification
0 bytes requested - initiating pool verification
(ntoskrnl\io\iomgr\iorsrce.c:701) IoReportResourceUsage is unimplemented
(ntoskrnl\io\iomgr\iorsrce.c:701) IoReportResourceUsage is unimplemented
(ntoskrnl\io\iomgr\driver.c:798) Driver 'BUSLOGIC.SYS' load failed, status (c00000c0)
(ntoskrnl\io\iomgr\file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1
MmPageEntireDriver at ntoskrnl\mm\drvlck.c:87 is unimplemented, have a nice day
MmPageEntireDriver at ntoskrnl\mm\drvlck.c:87 is unimplemented, have a nice day
MmPageEntireDriver at ntoskrnl\mm\drvlck.c:87 is unimplemented, have a nice day
(ntoskrnl\io\iomgr\file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 10001
(ntoskrnl\io\iomgr\file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1
(ntoskrnl\vdm\vdmmain.c:42) VME detected but not yet supported
(lib\rtl\registry.c:362) RTL: Expand variables for %SystemRoot%\system32\cmd.exe failed - Status ==
c0000023 Size a8 > 7e <e>
(lib\rtl\registry.c:362) RTL: Expand variables for
%SystemRoot%\bin;%SystemRoot%\system32;%SystemRoot% failed - Status == c0000023 Size f4 > ac <14>
(lib\fslib\vfatlib\vfatlib.c:215) VfatChkdsk() unimplemented!
(lib\rtl\registry.c:362) RTL: Expand variables for %SystemRoot%\system32 failed - Status == c0000023
Size a4 > 7e <6>
(ntoskrnl\io\iomgr\file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff
(ntoskrnl\io\iomgr\file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff
(ntoskrnl\io\iomgr\file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff
(ntoskrnl\se\semgr.c:1161) FIX caller rights (granted 0x8, desired 0x28, generic mapping 80C049E0)!
(dll\win32\iphlpapi\ifenum_reactos.c:99) openTcpFile for <\Device\Tcp> failed: 0xc0000034
(dll\win32\iphlpapi\ifenum_reactos.c:99) openTcpFile for <\Device\Tcp> failed: 0xc0000034
(ntoskrnl\io\iomgr\file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff
(dll\ntdll\ldr\utils.c:1199) LdrGetExportByName(): failed to find mxdMessage
(dll\ntdll\ldr\utils.c:2025) Failed to create or open dll section of 'msacm.drv' (Status c0000135)
(dll\ntdll\ldr\utils.c:1199) LdrGetExportByName(): failed to find auxMessage
(dll\ntdll\ldr\utils.c:1199) LdrGetExportByName(): failed to find mxdMessage
(dll\ntdll\ldr\utils.c:1199) LdrGetExportByName(): failed to find midMessage
(dll\ntdll\ldr\utils.c:1199) LdrGetExportByName(): failed to find widMessage
(dll\ntdll\ldr\utils.c:1199) LdrGetExportByName(): failed to find wodMessage
(dll\win32\shell32\shellpath.c:1688) Failed to create directory 'L".\\Local Settings\\Temporary
Internet Files"'.
(dll\win32\shell32\shellpath.c:1688) Failed to create directory 'L".\\Local Settings\\History"'.
(dll\win32\shell32\shellpath.c:1688) Failed to create directory 'L".\\Cookies"'.
(dll\ntdll\ldr\utils.c:1199) LdrGetExportByName(): failed to find mxdMessage
(dll\ntdll\ldr\utils.c:2025) Failed to create or open dll section of 'msacm.drv' (Status c0000135)
(dll\ntdll\ldr\utils.c:1199) LdrGetExportByName(): failed to find auxMessage
(dll\ntdll\ldr\utils.c:1199) LdrGetExportByName(): failed to find mxdMessage
(dll\ntdll\ldr\utils.c:1199) LdrGetExportByName(): failed to find midMessage
(dll\ntdll\ldr\utils.c:1199) LdrGetExportByName(): failed to find widMessage
(dll\ntdll\ldr\utils.c:1199) LdrGetExportByName(): failed to find wodMessage
(dll\win32\newdev\newdev.c:680) SetupDiOpenDeviceInfoW() failed with error 0xe000020b (InstanceId
HTREE\ROOT\0)
(dll\win32\newdev\newdev.c:736) Installing PCI BIOS (Root\*PNP0A03\0000)
(dll\win32\newdev\newdev.c:525) Installing driver (Generic system devices): PCIbus
(dll\win32\setupapi\queue.c:1521) copy error 2 L"C:\\ReactOS\\inf\\pci.sys" ->
L"C:\\ReactOS\\System32\\drivers\\pci.sys"
(dll\win32\rpcrt4\ndr_marshall.c:928) unhandled data type=09
(drivers\bus\pci\fdo.c:535) Unknown IOCTL 0xd
(drivers\bus\pci\fdo.c:373) No bus number resource found (bug in acpi.sys?), assuming bus number #0
(0,8D7D0178,36)
(dll\win32\newdev\newdev.c:736) Installing <NULL> (Root\*PNP0F13\0000)
(dll\win32\newdev\newdev.c:525) Installing driver (Standard mice): PS/2 port for PS/2-style mice
(dll\win32\setupapi\queue.c:1521) copy error 2 L"C:\\ReactOS\\inf\\i8042prt.sys" ->
L"C:\\ReactOS\\System32\\drivers\\i8042prt.sys"
(dll\win32\setupapi\queue.c:1521) copy error 2 L"C:\\ReactOS\\inf\\mouclass.sys" ->
L"C:\\ReactOS\\System32\\drivers\\mouclass.sys"
(dll\win32\rpcrt4\ndr_marshall.c:928) unhandled data type=09
(dll\win32\newdev\newdev.c:736) Installing <NULL> (Root\*PNP0303\0000)
(dll\win32\newdev\newdev.c:525) Installing driver (Standard keyboards): IBM PC/AT keyboard
(dll\win32\setupapi\queue.c:1521) copy error 2 L"C:\\ReactOS\\inf\\i8042prt.sys" ->
L"C:\\ReactOS\\System32\\drivers\\i8042prt.sys"
(dll\win32\setupapi\queue.c:1521) copy error 2 L"C:\\ReactOS\\inf\\kbdclass.sys" ->
L"C:\\ReactOS\\System32\\drivers\\kbdclass.sys"
(dll\win32\rpcrt4\ndr_marshall.c:928) unhandled data type=09
(dll\win32\newdev\newdev.c:736) Installing COM1 (Root\*PNP0501\0000)
(dll\win32\newdev\newdev.c:525) Installing driver (Standard ports): Serial communication port
(dll\win32\setupapi\queue.c:1521) copy error 2 L"C:\\ReactOS\\inf\\serial.sys" ->
L"C:\\ReactOS\\System32\\drivers\\serial.sys"
(dll\win32\setupapi\queue.c:1521) copy error 2 L"C:\\ReactOS\\inf\\serenum.sys" ->
L"C:\\ReactOS\\System32\\drivers\\serenum.sys"
(dll\win32\rpcrt4\ndr_marshall.c:928) unhandled data type=09
(dll\win32\rpcrt4\ndr_marshall.c:928) unhandled data type=09
(drivers\serial\serenum\fdo.c:209) IRP_MJ_PNP / unknown minor function 0xd
(drivers\serial\serial\pnp.c:400) Unknown minor function 0xd
(drivers\serial\serial\pnp.c:221) KdComPort: D11025FF=üà <two lines of junk>
Comm dies, it does continue to boot with a BSOD with the usb driver.
Thanks,
James
> + * @remarks
> + * The function will always return the complete size of the object's
> data,
> + * but will copy only a maximum of count bytes to the specified buffer.
This isn't necessarily true, and the function is slightly flawed because of
it. It's a rather weird API in terms of it's results.
Your rewrite doesn't take into account the following cases, according to XP:
................................................................
BITMAP behaviour
GetObjectW(hBmp, -1, &bmp) returns 24 and fills the struct
GetObjectW(hBmp, 0, &bmp) returns 0 and doesn't fill the struct
GetObjectW(hBmp, 1, &bmp) returns 0 and doesn't fill the struct
GetObjectW(hBmp, sizeof(BITMAP), &bmp) returns 24 and fills the struct
GetObjectW(hBmp, 5000, &bmp) returns 24 and fills the struct
DIBSECTION behaviour
GetObjectW(hBmp, -1, &dib) returns 24 and fills the struct
GetObjectW(hBmp, 0, &dib) returns 0 and doesn't fill the struct
GetObjectW(hBmp, 1, &dib) returns 0 and doesn't fill the struct
GetObjectW(hBmp, sizeof(BITMAP), &dib) returns 24 and fills the struct
GetObjectW(hBmp, sizeof(DIBSECTION), &dib) returns 24 and fills the struct
GetObjectW(hBmp, 5000, &dib) returns 24 and fills the struct
Non struct behaviour
The function will always return 24, no matter what size is passed.
................................................................
So, we can conclude that if size is less than 0, it works.
If size if between 0 and 23, it doesn't, and anything above works.
If we pass NULL, as the struct, we return 24, but obviously don't fill the
struct.
I would have grabbed you on IRC, but you weren't around ;)
Ged.
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
Amteus PLC
57 Cardigan Lane,
Leeds,
LS4 2LE
t:+44 (0) 870 8368770
f: +44 (0) 870 8368701
Registered in England No 4760795
http://www.amteus.com
I am new and am keen on developing ReactOS.
I looked through the source of ReactOS, there are only 13 Nasm files.
A while ago (2 weeks I think) I mentioned RosAsm, it was shunned a bit
though by some of the devs.
Anyway, I would prefer to develop in RosAsm rather than Nasm, I know how you
guys feel about it stealing your name
but I prefer it to Nasm. (Syntax is cleaner)
So would it be possible for me to develop in RosAsm for ReactOS?
It does run under ReactOS so it's just a case of your acceptance.
I am sick of you, Betov, as for your outright lies.
>Well, while I am at it, about the previous shocking absurdities:
Shocking absurdities... what a great name for your post.
>* RosAsm exist since September 1998. I started this Project the very
>First day I heard of ReactOS. This is to say, I never wrote one single
>Line for Windows, and I never used Windows any other way, but as
>A development platform, as long as ReactOS was not usable.
http://en.wikipedia.org/wiki/RosAsm
History:
In September 1998, René Tournois (also known as Betov), created SpAsm - The
Specific assembler which was maintained and supported by him until 24 July
2003. It was then continued with its successor, RosAsm....
Spasm 4.15j ,was the last of the versions released and maintained by René.
On 24 July 2003, he decided to take a higher step toward advancing the
benefit of Assembly Language and the free programming community. Concerned
about the ongoing of the Software and his constant efforts in keeping with
his ethical and political views, he left the project. From that remarkable
day, RosAsm was born!
RosAsm 1.1a was the first version from the renewed Software, released on 27
July 2003.
RosASM branched
from SpASM in 2003. Thus statement as RosASM even EXISTED in 1998 is
an outright lie.
>* We are not used to promote our Tool, and would we have intention to
>Do so, we would certainly not have suggested, with its name, that it
>was, in any way, devoted to an OS that does not exist, yet. "The
>Visual Assembler", or whatever such name would have been many
>Times more appropriated.
Using Ros as a part of your name is enough. Compare how many people know
the name ReactOS, to the number of
those who know about RosASM... it`ll be clear enough, who is leeching from who.
>* The fact that our Assembler name is "RosAsm" expresses the flat fact
>That it is devoted to ReactOS. Period.
The fact is that the name RosASM was chosen to CREATE IMPRESSION that RosASM
is in any way
related to ReactOS project. It is not. ROS never used and never will be
using RosASM. There is no relation
to RosASM. You were asked
to add a disclaimer on RosASM website, stating this fact. You failed
to provide it.
Why? You afraid of shattering the illusion of any RosASM-ROS relations? Your
devs still think they are working
for ROS project?
>This irritates Alex because he Hates me, and this is OK to me to
>irritates the very same individual, Who is implying that poor old
>Harmut was a dirty guy, having done something bad to reactOS,
>when leaving because of his conduct.
I dont know you as well as Alex does, and you know what? Those several posts
of yours i seen
were enough. Alex doesnt hate you. You just make him laugh. But you DO
IRRITATE ME.
I think you have several mental issues, including paranoia, neurosis, as
well as inferiority complex
regarding Alex. I suggest you take a long break from any computer-related
activities and rethink
your behaviour.
>* If ReactOS is a virtually dead Project, because of the topic that all of
>you seem to carefully avoid and try to hide under the carpet, we (the
>RosAsm Project), will effectively have serious problems, and not only
>with its Name. See what I mean Alexey? ("Nothing has been found yet",
">these are rumors", and so on...).
Again, another sign of your mental issues. If you are certain about Ros
project
being dead, you are free to change name as well as an object of your
devotion.
This should eliminate all the sources of your troubles. We would welcome
this
change with great joy. Please, do all of us a favour, and just GTFO with
your ASM.
>Betov.
Regards
Caemyr
First of All: The message is not in the wrong list,
but directed to developers.
A few facts about translators:
-Most are not programmers or they would be coding the
OS, just powerusers, or just users.
-Many like me can install SVN, and get the source
code, but never have made a patch, or even used
bugzilla(and probably wont have the time).
Now the matter:
Actually the process of translating reactos, or even
the web page is difficult, and for me it have been
frustrating. I started following the project in the
0.1.9 version, and about two years ago i tried to help
in the translation of ReactOS, and later in the
translation of the web page, but with little success.
I have the SVN, i got the code, i translated some
files, but sending them to bugzilla... i dont know how
to send them to bugzilla, i dont have a bugzilla
acount, it was tiring trying to find someone to send
the files, and i dont have the time or will to learn
bugzilla. So time passed, and no translation was made.
Something similar happened when i tried to translate
the web page, i got translator access, but after
making some translations, and sending it, i never saw
it applied (probably i was doing something wrong, but
never knew what).
Almost two years have passed from that time, i have a
hard job, and little free time, but still i wish to
help. I feel there are other translators in my
situation, as i see people that offer to help, but
never comes back.
So here is what i believe could be a solution:
The possible solution:
Html have an option to include code "as is", thus a
wiki should have that option.
-make a script that makes html files of all the rc
files.
-Add a page in the wiki (or another wiki) where those
html files are displayed.
-Anyone can get read access to them.
-There is an easy way to get write access to that
wiki.
-Translator teams for each language are created...
with a cordinator for each language (they give write
access to other translators).
-Translator access the rc files, that are in wiki
format, and edit them.
-Every week developers run a script to build rc files
from the html wiki files in each language.
Result: a translation effort, easy, coordinated, with
minimal need of learning technical stuff and many
developers that wont be molested by translators who
want their translations added to the svn.
Thanks,
Lucio Diaz.
PD: Please comment.
____________________________________________________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
Please use descriptive messages in your commit logs, this must've been stressed by Fireball at least a dozen times (Sometimes even with consequences). When we have to go over the changelog (Which is textlog-only), what are we supposed to put when we see 10 "Fix a bug" entries? It means we have to check out the log for every revision with such a message, and try to understand the change. Since the log is usually done by non-technical people, this becomes impossible for them.
Best regards,
Alex Ionescu
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dgorbachev(a)svn.reactos.org
Sent: April-14-07 2:07 PM
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [dgorbachev] 26342: Fix a bug.
Author: dgorbachev
Date: Sat Apr 14 22:07:08 2007
New Revision: 26342
URL: http://svn.reactos.org/svn/reactos?rev=26342&view=rev
Log:
Fix a bug.
Modified:
trunk/reactos/ntoskrnl/ps/query.c
Modified: trunk/reactos/ntoskrnl/ps/query.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/query.c?rev=26…
==============================================================================
--- trunk/reactos/ntoskrnl/ps/query.c (original)
+++ trunk/reactos/ntoskrnl/ps/query.c Sat Apr 14 22:07:08 2007
@@ -267,7 +267,7 @@
VmCounters->PeakPagefileUsage = Process->QuotaPeak[2];
/* Set the return length */
- *ReturnLength = sizeof(VM_COUNTERS);
+ Length = sizeof(VM_COUNTERS);
}
_SEH_HANDLE
{
Hello,
I suggest this patch for fixing the italian translation of SNDVOL32.
Sincerely,
Carlo Bramini
------------------------------------------------------
Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom
http://click.libero.it/infostrada
Hello,
I'm leaving for a 3 weeks vacation (starting today) and will be accessible
mostly via email.
Have fun with the ReactOS development, and do not introduce new bugs :).
Remember - when I'm back, we're going to prepare a new release - 0.3.2.
If trunk is not ready for a release by the moment I'm back, I'll start
killing devs one by one until it's ready.
--
WBR,
Aleksey Bragin
ReactOS Project Coordinator
http://www.reactos.org
P.S. The last sentence is a joke, obviously.
The source code for ReactOS is only 30MB.
The project has been going for 10 years so why so small?
Is there a need for any developers who can program assembler?
I use the ReactOS assembler. RosAsm. http://www.rosasm.org
Or do you only program in C and C++?
> We shouldn't allow attaching to a device that's still
> initlizaing, but ROS currently does because of some
> device that tries to do this, in the PnP manager or
> early boot-phase drivers (it has an auto-generated name).
> Please fix this!
Init function of that driver (PnpDriverInitializeEmpty() in pnpmgr.c) is
not called at all because of hack in IopCreateDriver(), line 1206.
Hi,
I promised a new testing/development environment but unfortunately I cannot
pursue my work because nobody has been able to fix rbuild to my
requirements. If anyone does want to see the standardized environment I
promised, please prod your local ReactOS developer for the following
features:
1) *Working* ROS_INTERMEDIATE and ROS_OUTPUT directories. They are
broken in many ways:
a. Don't work with relative pats.
b. Don't work at all for .pch files and/or compilation units.
c. Create other sorts of unpredictable errors due to hard-coded
strings/directories in makefiles or rbuild.
2) ROS_TOOLS_DIRECTORY. The ability for the tools to be outside the
ROS_OUTPUT directory, such as in c:\rosde\tools. Someone committed such a
patch but it was reverted without a newer version/fix.
a. Also requires making rbuild check if the binaries are present, and
if so, NOT to rebuild them.
b. Create -forcetools switch to rbuild which would force it to bypass
the check in 2a.
3) Tools must be built and work with the -O3 optimization setting.
Of course, I won't go into the fact that my request for the other rbuild
features such as a graphical dependency map have gone unanswered. Many
thanks to those who _have_ worked on some of the MSVC features/bugfixes I
brought forward and do the small attempt at a depmap.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
While I agree in spirit with the revert, we should use DDK #defines for compatibility. Please re-commit that part.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of fireball(a)svn.reactos.org
Sent: March-30-07 11:39 AM
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [fireball] 26210: - Revert useless commit: * No need to copy stuff from DDK, it's prohibited (#define _INC_NEWDEV) * #pragma was put there especially, and no reason to remove it was said * pushpack /
I recenly found out about this website. I checked out the sources (great)
and tried to run React OS under VMware player (not so great) and even tried
some of my sw to run under it (disaster!).
I have a few questions:
1. I noted some inconsistencies in handling 8-bit/UTF-16 translation in
..A/..W calls between ...A functions in graphics (TextOut...) and
synchronization (CreateSemaphore...). Graphics part always allocates memory
(HeapAlloc) - a waste of time, IMHO.
2. I'm, not sure if is there a list of already checked/done, but not
verified/not implemented API?
3. How could I help (I know some C)
Regards,
dn
PS Meanwhile, I was reading Doxygen & could not figure out how
MultiByteToWideChar() works (=i.e. how you implemented it), but I think it
calls RtlMultiByteToUnicodeN(), which implements CP -> UTF-16 mapping for
currently selected CP, and RtlCustomCPToUnicodeN() for any other CP. Some my
programs use MultiByteToWideChar() with CP_UTF8 which is IMHO NOT
implemented!?!?
May I work on this (in my spare time)? Is somebody else working on this
area?
Is it possible, that one of the official ROS-developer can contact
http://scan.coverity.com/index.html
to let also searched the ROS-code for bugs?
Greatings
theuserbl
_________________________________________________________________
Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit
Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu!
http://desktop.msn.de/ Jetzt gratis downloaden!
We'll.... I found out how MultiByteToWideChar (MBTWC) is implemented, and
looks OK.
But then, there are following issues:
1 some functions (DefWindowProcA) call MBTWC, but with CP_ACP and HeapAlloc
ALWAYS (IMHO should be: CP_THREAD_ACP, use some local cache if the 8-bit
string is short enough, for performance)
2 some functions (GetMonitorInfoA) call MBTWC using CP_THREAD_ACP
3 yet other functions (RegisterClassExA) call
RtlCreateUnicodeStringFromAsciiz and and RtlFreeUnicodeString later (no TEB
cache, allocation ALWAYS)
4 and some other functions (CreateEventExA) call
RtlAnsiStringToUnicodeString and use cache from TEB
5 other functions use RtlAnsiStringToUnicodeString with allocation, and
RtlFreeUnicodeString later.
6 and some other functions (SetWindowTextA) call
RtlAnsiStringToUnicodeString and RtlFreeUnicodeString (allocation ALWAYS)
Is this inconsistent or what?!
Best regards
Daniel
I verified that bug occuring on a Pentium MMX, and then ran the liveCD on bochs with a breakpoint at
the faulty instruction... It's a CMOVZ (Conditional MOVe if Zero flag set)...
Conditional moves were introduced in Pentium II, but never mind!
What *really* matters is that that code looks like resulting from compilation (because of the C
calling convention clearly used, and no one uses C calling conventions in handwritten ASM code)...
So..... Either this isn't a bug (and recompilation is required for non-default configurations), or
there is a -march option when compiling the default LiveCD that shouldn't be there... Personally, I
would go for the later...
PS: Can I view a symbol map for the freeloader image in the prebuilt liveCD?
JJ
_______________________________________________________
Yahoo! Mail - Sempre a melhor op��o para voc�!
Experimente j� e veja as novidades.
http://br.yahoo.com/mailbeta/tudonovo/
Hello,
I just finished upgrading svn.reactos.org to SVN 1.4.3. You should
feel noticeable improvements - faster work and less traffic. However,
if any problem arise, don't hesitate to email ros-general / ros-dev.
For a full list of changes over previous version, please look to
http://subversion.tigris.org.
With the best regards,
Aleksey Bragin.
Hi and welcome,
thanks for your offer to help - we were just discussing today in the
irc-channel that there are some people in our current team who are
willing to guide newbies through the process (get src code, build,
run, modify something, try writing something new, send in patches, etc).
If you have ability, please join #reactos on freenode irc network. If
not, then email is allright (ask questions right here, so other can
read and learn too).
WBR,
Aleksey Bragin.
On Mar 13, 2007, at 11:33 PM, Arko Provo Mukherjee wrote:
> Dear friends,
> We are 3 undergrad comp sc. and IT students from India. We have
> some coding experience but have never worked for the Open Source
> Community as developers. Yet we have always admired the concept and
> used FLOSS stuff like GNU/Linux.
> We came across ReactOS project and got really interested in it. We
> really want to contribute to the development of React OS and since
> we are new in Open Source development, we would require your
> guidance and support in stuff like understanding the code, building
> the build environment etc.
> Among other shortfalls that we have, we haven't programmed much on
> Windows platform (almost always Linux ie) and hence know little
> about the Windows API. But we are eager to learn and can definitely
> learn parts of the API as long as you can guide us.
> We humbly request you to guide us and give us some problems so that
> we can try and support this community. A lot is left to be done in
> ReactOS and it would be great being a part of such a project.
> Also we are better at writing C codes than reading them ( like
> almost everyone ;) ) and hence would request you to give us some
> problems that we can write from stratch rather than bug fixing that
> would require reading all codes.
> But we are ready to contribute in any way you feel we can as
> developers and support this community.
> Regards
> Arko Provo Mukherjee
> Abhishek Biswas
> Biswanath Banik
Hi,
I wanted to extend my thanks to ReactOS developers. I have used the
ReactOS source code on several occasions to help develop and debug
drivers intended for Microsoft Windows (WDM NT). I also used it to help
diagnose a hardware problem.
The Vista Windows Driver Kit sometimes include sample driver code
that will not work on systems newer than Windows 2003. I think I
actually used OpenRCE.org to help figure this out, but ReactOS does a
better job of letting me follow kernel level function logic.
The new PREfast annotations are also poorly documented but I don't
expect ReactOS will help with that. Perhaps its drivers could help
though.
One computer we had was bug checking (BSoD) with an NMI error with
Windows XP. Microsoft's documentation on this was poor and sometimes
misleading. Many other web sites provided incomplete (mostly just
inquiries), or misleading information (speculation that the wrong
hardware was at fault). With WinDBG, a search engine, and the ReactOS
source code, I managed to find what hardware was generating the bug
check. I then looked up the specifications from Intel and got quite a
bit of a better understanding.
I vaguely recall Walter Oney's WDM driver book provides a stub driver
which will help newer Windows drivers run on older versions of Windows
(although it's not redistributable and is documented as a workaround he
doesn't want others to use). Pointers to this may help ReactOS driver
developers.
Making sure source code is easy to search with Google is very useful. I
see that Google's source code search seems to search ReactOS, and
there's some Doxygen documentation that can be searched. Unfortunately
SVN or even other current source code seemingly cannot be searched without
using alternate methods (such as downloading and searching offline).
Ideally, something like lxr would be available for ReactOS, and through
Google. I also have the same wish for the most recent version of the
Linux kernel (Google doesn't seem to index lxr).
Having more sample driver code (even third party) would certainly be
useful.
I'd like to sell companies on using ReactOS, but there seems to be a
real anti production use message widely conveyed. I feel ReactOS is far
more stable than is given credit. That said, it would be nice if even
just some basic core part of ReactOS was stabilised (not even at a
Desktop user level). By "stabilised", I mean if people could test and
testify certain kinds of qualified stability (e.g. Version q ran x days,
but it was only doing y and had z hardware). Also it would be nice to
have even more information about changes to ReactOS that have/might make
things likely to break (bugcheck, freeze, not behave...). At least one
of the recent newsletters helped with that.
I'd love to use ReactOS to replace simple Windows XP Embedded images
(with many drivers and features stripped out).
Once again, thanks for all the ReactOS efforts. I'm sure I do not yet
fully appreciate the resources available to me because of ReactOS, but
the ones I've found have been extremely useful.
Drew Daniels
Resume: http://www.boxheap.net/ddaniels/resume.html