Ros-dev

ros-dev@reactos.org

1 participants
5793 discussions

Re: [ros-dev] Introduction
by Aleksey Bragin 13 Nov '07

13 Nov '07

Hi, welcome. The best is to join #reactos on freenode and have a live talk with devs. The language used throughout ReactOS is mostly C, with very few exceptions to C++. And if you have WinAPI knowledge, it would be appreciated. WBR, Aleksey Bragin. On Nov 14, 2007, at 12:16 AM, James Holland wrote: > My name is James Holland. I am interested in helping with the > development of ReactOS. I am fairly adept with C++. I also have used > APL (not very well) and MS Visual Basic at past times. I am currently > using Java in my Computer Science class. > > For background, I am a Student at New Mexico Tech. My major is > Electrical Engineering. > > I am open for any suggestions as to what I should do. > > James Holland

1 0

Introduction
by James Holland 13 Nov '07

13 Nov '07

My name is James Holland. I am interested in helping with the development of ReactOS. I am fairly adept with C++. I also have used APL (not very well) and MS Visual Basic at past times. I am currently using Java in my Computer Science class. For background, I am a Student at New Mexico Tech. My major is Electrical Engineering. I am open for any suggestions as to what I should do. James Holland

1 0

Re: [ros-dev] About UNICODE<->ASCII support.
by carlo.bramix 13 Nov '07

13 Nov '07

Hello, Probably, you are right. It's better to close this discussion here. I will move my interests elsewhere, where your nice replies won't reach me. Greetings to all. Sincerely, Carlo Bramini. "unsubscribe"... <click> ---------- Initial Header ----------- >From : ros-dev-bounces(a)reactos.org To : "ReactOS Development List" ros-dev(a)reactos.org Cc : Date : Tue, 13 Nov 2007 15:07:35 -0000 Subject : Re: [ros-dev] About UNICODE<->ASCII support. > carlo.bramix wrote: > > > But, for an ascii-based OS, it's a compromise for getting the > > application working because that application, if compiled in that > > configuration, will work only on Win9x/ME. > > We have no interest in ascii-based OS's, we have no interest in 9x/ME. > > > And this is what I cannot understand: the ability to work in both > enviroment > > is an *added*value* to the software, not a defect. > > Why? ReactOS apps have no value in being built as ASCII. > ASCII is both rude and prehistoric. Move on, this is the 21st century, > ReactOS is a unicode operating system. > As far as we're concerned Win9x is dead. > > > Just another small bit: besides the functions with the 'W' suffix (while > the > > remaining part of the planet uses at least the unified function names), > > sometimes debugging directly unicode is a pain, at least for me... > > Well you stay on your prefered half of the planet and stop bothering us with > your > ASCII ranting... > > I'd hate to see you work with C#, you'd have a fit as it's unicode only. > I have visions of you p/invoking everything to make sure you can still build > your .NET apps as ASCII. > > > The strings into the debuggers are shown as a vector of words instead of a > > > clear string, same condition when declaring some constant strings into the > > > sources, as vector of single chars... > > Horrible (urgh!). > > Get yourself a decent debugger then, or close your eyes, or give up. > > > 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 Secure Communications Ltd > 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 > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

1 0

Re: [ros-dev] About UNICODE<->ASCII support.
by carlo.bramix 13 Nov '07

13 Nov '07

Hello, > > Athough you should also admit that two WideCharToMultiByte() > > calls are not exactly something we can call "drammatic" code > As I also said, WideCharToMultiByte() can cause data corruption if a Unicode > character isn't supported by the currently selected ANSI codepage. > MultiByteToWideChar() is no problem, but the other direction can be > problematic. > After all, we're coding for Windows Server 2003-compatibility here. > We don't have to care about compatibility with Win9x (ANSI-only) or previous > NT versions. That's right, it can cause corruption. But, for an ascii-based OS, it's a compromise for getting the application working because that application, if compiled in that configuration, will work only on Win9x/ME. If someone wants to make an object working on his old OS, he must also be ready to the drawbacks, this has never been a news. Afterall, unicows is doing the same job when wrapping the vaious widechar APIs. But for NT and later, everything just need to be compiled as UNICODE, no? And this is what I cannot understand: the ability to work in both enviroment is an *added*value* to the software, not a defect. I just wanted to clarify that I was not asking to release the accessories and/or other parts of ReactOS' binaries compiled for ASCII. Absolutely not, in no way! Read: I want the most flexible international support available. Just another small bit: besides the functions with the 'W' suffix (while the remaining part of the planet uses at least the unified function names), sometimes debugging directly unicode is a pain, at least for me... The strings into the debuggers are shown as a vector of words instead of a clear string, same condition when declaring some constant strings into the sources, as vector of single chars... Horrible (urgh!). Sincerely, Carlo Bramini

2 1

rbuild auto generated resources
by Marc Piulachs 13 Nov '07

13 Nov '07

>From all changes introduced on my rbuild branch auto generated resources seems to be the most controversial by far so I will try to explain here the design decision behind it One of my particular obsessions is trying to optimize and automate the maxium ammout of things, if something can be reasonably created automatically why do it by hand? CURRENT SITUATION ================= Currently the version common defines REACTOS_STR_FILE_DESCRIPTION , REACTOS_STR_INTERNAL_NAME and REACTOS_STR_ORIGINAL_FILENAME , localized resources and theme manifest are added to [modulename].rc , rsrc.rc or splitted between both. Problems: - Theme manifests files "manifest.xml" are architecture dependent (X86) - Duplicated content, we will have hundreds of identical manifest files for every aplication - No way to compile an aplication without manifest - No way to compile an aplication with only specified localizations - Duplicated work, rbuild has all the information required to automatically generate the defines - If we decide to rename or introduce a new define in the future we will have to edit all resources by hand. - Resource localizations are compiled with any control , the only way to check if they are included is by hand. Advantatges to my proposal: - It solve all the above problems. - Reduce man work - Allows future changes in the format (editing the resource generator source code (1 file) vs all resources files on SVN) - It's the base to other future enchancments , when a new feature is added to rbuild we have just to modify it and all modules will automatically inherit it. An most important of all , it represents a change of the model to a metadata oriented build process. You describe the content (source code , resources ...) rather than the build , rbuild uses that information to generate the apropiate image (as always) but this information can also be used for multiple other things, analitics , reports , web .... How does it work? ================= First of all IT'S OPTIONAL , you can decide to use it or not, your choice. We will use the eventvwr.rbuild as sample: <?xml version="1.0"?> <module name="eventvwr" type="win32gui" installbase="system32" installname="eventvwr.exe"> <include base="eventvwr">.</include> <include base="eventvwr" root="intermediate">.</include> ...  <automanifest>manifest.xml</automanifest> <autoresource>auto.rc</autoresource>  <developer>mpiulachs</developer> <translator>cfinck</translator> <translator>fireball</translator> <translator>mpiulachs</translator> <metadata description="ReactOS Event Log Viewer" />  <localization isoname="de-DE">lang/de-DE.rc</localization> <localization isoname="en-US">lang/en-US.rc</localization> <localization isoname="es-ES">lang/es-ES.rc</localization> <localization isoname="fr-FR">lang/fr-FR.rc</localization> <localization isoname="ru-RU">lang/ru-RU.rc</localization> </module> to turn auto resources on we have to add the <autoresource> element with the name of the resource that will be created in the INTERMEDIATE folder in this case it will be named "auto.rc". It will also automatically create the apropiate manifest.xml file for the architecture being build (x86 or PPC) and will reference it in "auto.rc" Also it will validate and include the localizations, even it has localizations for 5 languages it will only compile those specified on languages.rbuild See attached files for autogenerated content I tried to explain the motivation behind my changes and why I think they are positive , of course I'm open to your questions , ideas or comments but please be contructive and argument your point of view , "I don't like it , we won't use it" as someone said is not an expected opinion. /Marc

8 21

question
by David Johnson 13 Nov '07

13 Nov '07

How is it possible to tell XP what specific IRQ to put your audio card on in Standard PC mode? 1 In the motherboard BIOS. 2 In the Device Manager. 3 Put the card in the corresponding slot. 4 There are jumpers on most motherboards that you can change to direct IRQs. 5 None of the above. _________________________________ Dave Johnson http://www.davefilms.us DaveFILMS® San Diego, CA & Nashville, TN http://perditioncity.us/ Voice Talent Writer, Producer, Director Independent Audio Theater Producer Voice mail and Fax#:(206)350-2915 Voice (615)722-2249 Skype & Msn Live messanger "DaveFilms" AIM / iChat AV "DaveFilms2007"

1 0

vr IRQ in windows
by David Johnson 13 Nov '07

13 Nov '07

Please list all VR IRQ in NT 5.1 and VI IF my computer is not in ACPI m ode is it in Standard PC mode? Please reply.. It is vary important. _________________________________ Dave Johnson http://www.davefilms.us DaveFILMS® San Diego, CA & Nashville, TN http://perditioncity.us/ Voice Talent Writer, Producer, Director Independent Audio Theater Producer Voice mail and Fax#:(206)350-2915 Voice (615)722-2249 Skype & Msn Live messanger "DaveFilms" AIM / iChat AV "DaveFilms2007"

1 0

Re: [ros-dev] [ros-diffs] [arty] 30352: Add structures related to devtree.c
by Aleksey Bragin 12 Nov '07

12 Nov '07

Why not use a linked list structure in LOADER_PARAMETER_BLOCK, describing hardware device tree? (I implemented a bit of it in winldr). Or is it for a different purpose? WBR, Aleksey Bragin. On Nov 11, 2007, at 12:27 PM, arty(a)svn.reactos.org wrote: > Author: arty > Date: Sun Nov 11 12:27:07 2007 > New Revision: 30352 > > URL: http://svn.reactos.org/svn/reactos?rev=30352&view=rev > Log: > Add structures related to devtree.c > > Modified: > trunk/reactos/include/reactos/ppcboot.h

2 1

Re: [ros-dev] Tracking implementation API status
by Aleksey Bragin 12 Nov '07

12 Nov '07

Hi, no, I was speaking about something different. Take a look - http://www.reactos.org/wiki/index.php/Coding_Style there I mean this: /*++ * @name SomeAPI * @implemented NT4 * * Do nothing for 500ms. * * @param SomeParameter * Description of the parameter. Wrapped to more lines on ~70th * column. * * @param YetAnotherParameter * Bleh, bleh :) * * @return STATUS_SUCCESS in case of success, STATUS_UNSUCCESSFUL * othwerwise. * * @remarks Must be called at IRQL == DISPATCH_LEVEL * *--*/ NTSTATUS STDCALL SomeAPI( ... rgenstat-alike tool should be able to parse such header, not only the old-style simple /* @implemented */ WBR, Aleksey Bragin. On Nov 10, 2007, at 1:06 AM, Marc Piulachs wrote: > Hi Aleksey, > > > > I don’t know if I understood you completely, rgenstat works by > parsing c/cpp source files not header files. What do you mean with > “standard function header”? > > > > If we are seriously going to use it I would like to make some > slightly modifications to it to make it more powerful but would > require help from someone with more experience than me writing > parsers in C. > > > > Regards, > > /Marc

4 4

Re: [ros-dev] rbuild auto generated resources
by Aleksey Bragin 11 Nov '07

11 Nov '07

On Nov 12, 2007, at 1:56 AM, Timo Kreuzer wrote: >> Once again, the data extracted from parsing is not TRUE metadata just >> meaningless strings that you can guess or interpret : "author : >> jdoe" , >> "author : jhondoe" , "author : jhon doe" are 3 different persons and >> Jhon Doe just one , I think it's obvious. >> > I disagree here. IMO information about developers and translators > belong to svn. They should neither go into the sources nor into > rbuild files. If you want to find out about it, ask svn and it will > tell you the exact name. We also don't really have maintainers for > most modules, so most rbuild files would be spammed with the names > of lots of developers without saying anything about who wrote a > paticular piece of code. There is standard per-file header for ReactOS source code (if it's not used everywhere, it's a temporary problem), which lists programmers, and it's usually (almost always) maintained. Whenever our code is indexed by systems like Google codesearch, everyone can clearly see the license and authorship from the source file. Additionally, SVN holds exact per-line history of changes. What's the benefit of storing authoship in .rbuild too? (I agree it is logical, but if there is no benefit, then...) WBR, Aleksey Bragin.

2 1

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