Ros-dev

ros-dev@reactos.org

1 participants
5793 discussions

Re: [ros-dev] [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 / poppack does not do anything if there a
by Alex Ionescu 30 Mar '07

30 Mar '07

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 /

1 0

Some Questions
by Daniel Nikolić 29 Mar '07

29 Mar '07

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?

2 1

Letting adding to Scan.Coverity.com
by theUser BL 28 Mar '07

28 Mar '07

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!

3 2

Re: [ros-dev] Some Questions
by Daniel Nikolić 28 Mar '07

28 Mar '07

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

1 0

About BUG 2093/2078
by João Jerónimo 27 Mar '07

27 Mar '07

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/

1 0

SVN upgraded to 1.4.3
by Aleksey Bragin 26 Mar '07

26 Mar '07

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.

1 0

Re: [ros-dev] Interest in ReactOS and some requets
by Aleksey Bragin 26 Mar '07

26 Mar '07

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

5 4

Thanks. ReactOS helped me develop and debug Windows drivers.
by Drew Scott Daniels 24 Mar '07

24 Mar '07

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

2 1

replacement for winecalc
by Timo Kreuzer 23 Mar '07

23 Mar '07

Hi, Someone from the forum has written a replacement for winecalc and asks, if we would want to use it. I think it deserves some attention: http://www.reactos.org/forum/viewtopic.php?t=3585 - The code is smaller than winecalc. - It seems to (almost, see below) work correctly as far as I have tested (type 2+3*4 in winecalc and you will get 12 as result....) - brackets are working (not implemented in winecalc) - inv is working (not implemented in winecalc) - It looks a little better than winecalc "bugs" found so far: - there's an issue with foucs, that is put on a button when switching to another app - grad calculates with 200 instead of 400 = 360° - modulo and hyp seem unimplemented - you can't use and, xor, ... in dec mode Greetings, Timo

1 0

Re: [ros-dev] [ros-diffs] [janderwald] 26147: - fix makefiles to depend on TOOLS_OUT_ value than directly hardcoding it to $(OUTPUT)
by Aleksey Bragin 21 Mar '07

21 Mar '07

This breaks the very beginnings of the compile process. WBR, Aleksey Bragin. On Mar 20, 2007, at 11:12 PM, janderwald(a)svn.reactos.org wrote: > Author: janderwald > Date: Tue Mar 20 23:12:10 2007 > New Revision: 26147 > > URL: http://svn.reactos.org/svn/reactos?rev=26147&view=rev > Log: > - fix makefiles to depend on TOOLS_OUT_ value than directly > hardcoding it to $(OUTPUT) >

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev