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
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)
>
Hi,
I am from Berlin, Germany and really interested in joining the ROS
project as a developer.
I started as proposed with digging into the code a little bit and wrote
some patches. So my first question is, which developer (with svn write
access) do i have to contact so that he can help my to review and
(hopefully) apply some of my patches?
Second thing is that i read that you are already planning a complete
rewrite of the explorer code. I would really like to be a part of the
explorer project but others are also welcome.
If you have any idea how to start just let me know.
With best regards,
Tim Taubert
Hi,
I tried to build the ReactOS main trunk, but I've run into some problems.
'make all' fails with the message:
mkdir: cannot create directory
`obj-i386\\lib\\inflib_host': No such file or directory
Up until now, I've got the 'trunk' directory from SVN (using TortoiseSVN), I
exported the sources to a directory in the ros Build Environment (I was
asked for that directory on install) and attempted to build from there. I
also looked at the Makefile and set the '-mi' flag (ROS_RBUILDFLAGS = -mi),
but that didn't help.
Just for the record, I'm building on a WinXP SP2, using ReactOS Build
Environment 0.3.5b2. I also tried the 0.3.4 version, but I run into the same
issues.
Do you have any ideas?
Thanks,
Radu
>Sorry for waiting until now to reply.
It's all good. : )
>What do you think?
I think we should convert to BE, but not away from PE-COFF. There are too
many differences between them, and while it would be less work in the short
term to switch to ELF, in the long term, implementing all of the features of
PE would be very troublesome. Not the least concern is that information
such as import data and file headers aren't even mapped into a process's
address space with ELF. As I understand it, when you get an IHANDLE to a
linked in DLL it's just a pointer to the mapped in PE file header. I'm sure
there are programs that require this on a source level to run (which, for
quite some time will be the only thing that affects us on the PowerPC side
of things).
That being said, a proper pe-powerpcbe target in gcc should then be the
first priority. Binutils already more or less properly creates pe-powercbe
files (with what I assume are your patches on the wiki, and a little
monkeying to make sure that the MZ header and PE signature are always
written as little-endian regardless of the target architecture). What kind
of issues had you had on the EABI side of things, and what was your plan in
more detail for emulating the features of PE in ELF?
Also how much progress had you made in the port up to now?
~Tristan Miller
(monocasa)
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 Guys
I have recently discovered ReactOS through my research for Linuxforums.org,
I have written an article on ReactOS, which should show up online in the
near future. Basically I like your work and I would be keen to contribute
some of my (unfortunately limited) time and skills to your project. I cant
code but I can write ok.
Could I be of any use to you guys?
Cheers
Sam
--
Did you know that if you play a Windows XP cd backwards, you
will hear the voice of Satan?
That's nothing! If you play it forward, it'll install Windows XP.
Hey,
Sorry, having problems with internet or else I'd ask this on IRC. I was
curious as to why the emphasis on little-endian mode in powerpc. Mac G5's
don't even have le-mode, and it definitely seems that (although im not
totally sure, as theres not much info out in the wild yet) that the XBox360
lacks le-mode as well. Also, on the processors that support le-mode, it
seems in all cases (although theres probably some embedded guy that I'm
missing : P) that do support it, it's selectable at the minimum at the
user/supervisor level with only a bit of work. Perhaps eventually a
thunking layer (maybe a part of NTVDM, would it need to be that complex?)
that would translate the calls from le usermode to a be kernel could be
written, allowing one to run NT-PPC applications that are out there. We
wouldn't be able to load drivers (or any le kernel code), but are there
actually any PPC drivers out in the wild? Plus, it seems that it would
definitely be a good thing for the kernel source to be tested on multiple
endians as early as possible in its development to ease porting later on.
~ Tristan Miller
(monocasa)
It's all about re-thinking what rosapps is. Initially it was supposed
to be a place for various "app"lications. Right now it turned out to
become a kind of a trashcan, where stuff unapplicable for trunk goes.
Since this is wrong, it's perfectly fine to "force" devs to build
with rosapps (and rostests, if they are interested in thorough
testing) module.
Otherwise, with make/make all, we again end up with rudimentary rosapps.
Also there will be some kind of "unmaintained" module (undecided yet
- discussions are welcome) where some stuff from rosapps is going to
be moved (which is not currently maintained, and not interesting for
devs).
WBR,
Aleksey.
On Mar 9, 2007, at 2:38 AM, Ged Murphy wrote:
> Upon thinking about this, I'm not sure it's such a good idea with
> respect to usermode stability as it will get less testing now from
> non-included apps.
>
> This would allow us to have the best of both world.
> Many of the tests we run at application level rely on the apps which
> have just been moved being easily accessable.
> If these are gone, I suspect less feedback will be collected about the
> status of usermode.
>
> Ged.
Hi,
yes definately. Our project would certainly benefit from a good PR
and spread the word, because it eventually brings new developers and
thus development speed rises.
Thanks a lot, and feel free to email here or me.
With the best regards,
Aleksey Bragin.
On Mar 8, 2007, at 3:20 AM, Sam Banks wrote:
> Hi Guys
>
> I have recently discovered ReactOS through my research for
> Linuxforums.org, I have written an article on ReactOS, which should
> show up online in the near future. Basically I like your work and I
> would be keen to contribute some of my (unfortunately limited) time
> and skills to your project. I cant code but I can write ok.
>
> Could I be of any use to you guys?
>
> Cheers
>
> Sam
ion(a)svn.reactos.org wrote:
> Author: ion
> Date: Thu Mar 8 21:59:45 2007
> New Revision: 26032
>
> URL: http://svn.reactos.org/svn/reactos?rev=26032&view=rev
> Log:
> - Tree cleanups proposed on the mailing list. Move all non-Core OS modules to rosapps. Tests were already moved by Fireball to rostests.
>
This will break 'make bootcd'
Upon thinking about this, I'm not sure it's such a good idea with
respect to usermode stability as it will get less testing now from
non-included apps.
Another idea, instead of moving everything out of the main trunk would
be to give each component a new tag in rbuild.
This tag could be something like core="yes|no". Everything which has
been moved to rosapps could be labeled with a core="no"
2 new build commands would be available, make core and make corebootcd.
This would allow us to have the best of both world.
Many of the tests we run at application level rely on the apps which
have just been moved being easily accessable.
If these are gone, I suspect less feedback will be collected about the
status of usermode.
Ged.
I forgot to mention that I used Ged Murphy's .ppt as a base (design
mostly), and I used some parts of information about the kernel given
by Alex Ionescu.
WBR,
Aleksey Bragin.
On Mar 3, 2007, at 4:18 PM, fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Sat Mar 3 16:17:47 2007
> New Revision: 25971
>
> URL: http://svn.reactos.org/svn/reactos?rev=25971&view=rev
> Log:
> ReactOS FOSDEM 2007 talk slides
Setting autoreply while being subscribed to a mailing list - that's
something not good to do.
Unsubscribed...
WBR,
Aleksey Bragin.
On Mar 2, 2007, at 2:02 PM, tim-sobolev wrote:
> В связи с седлительностью сервера ящик обьявлен закрытым
> Адресат переехал на tim тточчка sobolev сссоббаккка gmail ттточчка ком
> _______________________________________________
Hi,
thanks for your interest. Yes, Arty is indeed The Man to contact
regarding the PPC port, but anyway post your questions here if you
can't catch him on irc, and they will be answered sooner or later.
WBR,
Aleksey Bragin.
On Mar 2, 2007, at 12:15 PM, Tristan Miller wrote:
> Hey everyone,
> I'm interested in becoming a kernel developer, especially with
> the PowerPC port. Almost all of my experience comes from
> supervisor code (or embedded systems without MMU's), or from type-
> safe byte-code (and ironically enough, a weird combination of the
> two). However, this would be the first project that I've worked
> with others on. Any idea's where I should start. Those on IRC
> specifically pointed out Arty in regards to the PowerPC.
>
> ~Tristan Miller
Hey everyone,
I'm interested in becoming a kernel developer, especially with the
PowerPC port. Almost all of my experience comes from supervisor code (or
embedded systems without MMU's), or from type-safe byte-code (and ironically
enough, a weird combination of the two). However, this would be the first
project that I've worked with others on. Any idea's where I should start.
Those on IRC specifically pointed out Arty in regards to the PowerPC.
~Tristan Miller
On Feb 27, 2007, at 3:04 AM, dgorbachev(a)svn.reactos.org wrote:
> Author: dgorbachev
> Date: Tue Feb 27 03:04:43 2007
> New Revision: 25911
>
> URL: http://svn.reactos.org/svn/reactos?rev=25911&view=rev
> Log:
> Indonesian translation by Zaenal Mutaqin
>
> -= skip =-
> trunk/reactos/ntoskrnl/mm/npool.c
>
I don't think that was intended, so please undo the change.
WBR,
Aleksey Bragin.
Hi,
Just a quick email to let you know that I am a kernel programmer working
with Alex.
I am now working on the fsrtl lib. I am almost done with fastio.c at this
point.
Thanks
--Dom
> Nevertheless the fonts should look fine with default settings. But it
may look better with all features enabled.
Fonts look fine, yes, but don't expect them to look better by adding
bytecode which is IGNORED.
Sigh,
mf
Thomas Weidenmueller wrote:
> No, the disabled functionality doesn't affect the output in any way
> except speed. Only the byte code interpreter is affected by patents, but
> the hinting is still done correctly, although slower.
Exactly. This byte code is the hinting that Ged suggests embedding in
our Marlett font. Of course freetype still hints, but it ignores the
bytecode and works around it. Hence embedding hints in the TTF would
be rather useless. Ask wierd_w, he's been having a lot of trouble with
hinting and freetype. The only solution we could come up with is
adding a hack for greyscale bitmap fonts that substitute the outlines
for certain font sizes.
mf
Hi,
> Another area that will need attention is adding hints to all the glyphs and
> making it a TTF.
Patent pansies have disabled hinting in ReactOS' freetype. So hinting
will do us no good, as hints are not parsed by the font engine.
Regards,
mf
Begin forwarded message:
> From: "Microsoft US Developer Team" <developer(a)response.microsoft.com>
> Date: February 22, 2007 11:54:45 AM CST
> To: <davidjohnson.johnson(a)gmail.com>
> Subject: Important Daylight Savings Time Update for Developers
> Reply-To: "Microsoft US Developer Team"
> <developer(a)response.microsoft.com>
>
>
>
>
> Dear Valued Microsoft Customer,
>
> In 2005, the United States government passed the Energy Policy Act
> of 2005. This act changes the start and end dates for Daylight
> Saving Time (DST) as of spring 2007. These changes may impact the
> way applications run. Microsoft is releasing an update for Windows
> through Microsoft Update that reflects these changes.
>
> Developers who use the .NET Framework may find their applications
> affected if the application uses the time zone information for
> historical purposes or if they have derived custom classes from
> System.TimeZone to provide custom time zone information. The
> standard System.TimeZone class provides a managed wrapper for the
> underlying Windows Operating System time zone functions.
>
> In addition, developers who use Visual C++ may find their
> applications affected if they use the CRT time functions, or the TZ
> environment variable. Microsoft is currently working on a fix for
> this issue and will post information about its availability on the
> Visual Studio Support page.
>
> Most applications that use these affected classes will not need to
> be modified as this update will ensure that the correct data is
> provided seamlessly to the application. However, applications that
> use these classes or the underlying Windows API to perform
> historical time look-ups will need to be modified.
>
> In most cases, developers who have extended the .NET Framework’s
> time zone support by creating custom time zone classes derived from
> System.TimeZone, or by direct access to the Win32 API, will not
> have to update their applications as long as the available updates
> to the operating system are applied. However, solutions that rely
> on private time zone data, or that retrieve system time zone
> information by accessing the registry directly, may need to be
> updated. Applications that deal with historical time zone data may
> also need to be updated.
>
> Microsoft advises all developers who make use of time zone data to
> test their applications against this update to ensure that their
> applications function correctly.
>
> For more detailed information and the latest updates please visit
> http://msdn2.microsoft.com/en-us/vstudio/bb264729.aspx, Preparing
> for daylight saving time changes in 2007, and KB928388: 2007 time
> zone update for Microsoft Windows operating systems.
>
> Further Assistance
>
> Microsoft values your business. For more information visit http://
> www.microsoft.com/dst2007, or contact Microsoft for assistance. A
> list of phone numbers is located at http://support.microsoft.com.
> Microsoft Premier Customers may engage their Technical Account
> Manager directly.
>
> Please DO NOT REPLY to this email as this is not a monitored inbox.
> If you have questions/inquiries please visit http://
> www.microsoft.com/dst2007
>
> This e-mail is intended for distribution within the United States.
> Please contact your local Microsoft subsidiary for similar
> offerings outside the US.
>
> Thank you,
>
> Microsoft US Developer Team
>
>
>
>
>
>
>
_________________________________
Dave Johnson
http://www.davefilms.us DaveFILMS®
San Diego, CA & Nashville, TN
http://thevoicezone.us The Voice Zone™
Voice Talent
Writer, Producer, Director
Independent Audio Theater Producer
Voice mail and Fax#:(206)350-2915
Skype & Msn Live messanger "DaveFilms"
I have a patch to move all the functionality of DrawFrameControl over to the
Marlett font, but before I add it I think the font needs a bit more work.
We have the outlines for all the glyphs in trunk under
media/fonts/marlett.ttf, but they need some TLC.
One thing which stands out are the caption buttons. Drawn at 10pt, which is
what is used for regular caption bars, they don't appear as clearly as they
should.
Another area that will need attention is adding hints to all the glyphs and
making it a TTF.
I have no experience with fonts, hence me writing this mail to ask if any
font designers are willing to help make our Marlett font complete.
Cheers,
Ged.
Registered Office: PO Box 1 Salford Road, Over Hulton, Bolton, BL5 1DD.
Registered in England: No. 2375355
The information contained in this message or any of its attachments is
confidential and is intended for the exclusive use of the addressee. The
information may also be legally privileged. The views expressed may not be
company policy, but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other dissemination
or use of this communication is strictly prohibited. If you have received
this message in error, please contact postmaster(a)eu.exide.com
<mailto:postmaster@eu.exide.com> and then delete this message.
Exide Technologies is an industrial and transportation battery producer and
recycler with operations in 89 countries. Further information can be found
at www.exide.com <www.exide.com>