Ros-dev August 2007

ros-dev@reactos.org

38 participants
58 discussions

Re: [ros-dev] Will ROS and WINE still be steady be synchronized ?
by Aleksey Bragin 29 Aug '07

29 Aug '07

Wine, as every other project, is free to set their own rules for accepting patches. If members of our development team can do anything to help Wine - we are glad to. However, they seem to want to stick to only their own devs' contribution (mainly). With the best regards, Aleksey Bragin. On Aug 29, 2007, at 4:54 PM, theUser BL wrote: >> Personal preference. >> Wine are nearing to a 1.0 product and are very careful about what >> code >> enters their repository. >> ReactOS does not currently meet their strict policy. >> >> If you want to get code into Wine, you must submit your patches >> with test >> cases and if required, relevant links to documentation. > > I have also ask the question on the WINE-mailinglist. > The answer at > http://www.winehq.org/pipermail/wine-devel/2007-August/058929.html > looks like, that the test-suites are not the only reason. > > > Greatings > theuserbl

1 0

Re: [ros-dev] [ros-diffs] [hpoussin] 28603: qsort() prototype in stdlib.h doesn't specify that callback function must be __cdecl
by Alex Ionescu 29 Aug '07

29 Aug '07

O rly? _CRTIMP void __cdecl qsort(__inout_bcount(_NumOfElements * _SizeOfElements) void * _Base, On 8/27/07, hpoussin(a)svn.reactos.org <hpoussin(a)svn.reactos.org> wrote: > > Author: hpoussin > Date: Mon Aug 27 19:26:39 2007 > New Revision: 28603 > > URL: http://svn.reactos.org/svn/reactos?rev=28603&view=rev > Log: > qsort() prototype in stdlib.h doesn't specify that callback function must > be __cdecl > > Modified: > trunk/reactos/lib/rtl/bitmap.c > > Modified: trunk/reactos/lib/rtl/bitmap.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/bitmap.c?rev=28603… > > ============================================================================== > --- trunk/reactos/lib/rtl/bitmap.c (original) > +++ trunk/reactos/lib/rtl/bitmap.c Mon Aug 27 19:26:39 2007 > @@ -36,7 +36,6 @@ > > static > int > -__cdecl > NTDLL_RunSortFn(const void *lhs, > const void *rhs) > { > > > -- Best regards, Alex Ionescu

2 1

Wine-WordPad instead of ROS-WordPad?
by theUser BL 28 Aug '07

28 Aug '07

Hi! Yesterday I have downloaded and tried out the lastest vrsion of Wine. Version 0.9.44. In the annoncement of that release there stand "Improvements to the builtin WordPad". So I have also tried ot its WordPad and it looks better then the ROS-Notepad. So wouldn't it a trhought to use WINEs WordPad instead of ROS one? And will the sources of WINE and ROS steady be synchronized ? Seems, that WINE uses an old version of cards.dll. The notepad from ROS and WINE is different and so on. _________________________________________________________________ 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 3

Re: [ros-dev] State of 0.3.3
by carlo.bramix 28 Aug '07

28 Aug '07

Hello. If it's possible, I would ask to apply the patch posted at bug #2494 before releasing 0.3.3 (RC2 or Final), so I will be able to remove my backup copy of regedit... Sincerely, Carlo Bramini. Colin Finck wrote: > Hello, > > As you probably saw, I recently rebranched 0.3.3 and made some changes to > it. > Now I'm at the point, where *I* think that it's ready. > > I don't know if anyone else has any specific plans for 0.3.3, so I'm just > asking here now. > Otherwise, I think we could simply release the current branch as RC2 or even > REL. But also if we release it as RC2 now, what are the plans for the REL > version then? > > Please also think of our planned 2-month release cycle. > I know that these are just estimated dates, where users *can* expect a > release and I myself said this a couple of times as well, but we already > skipped 0.3.2, so we shouldn't miss the "deadline" for 0.3.3 now. > > Regards, > > Colin > > _______________________________________________ > Ros-dev mailing list > Ros-dev at reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

1 0

ENUMFONTDATAW structure
by Timo Kreuzer 27 Aug '07

27 Aug '07

I agree with the complete structure itself, but I have some issues with the way it is implemented atm. 1.) the member ulOffsetTM: If it is an offset one would guess it would be an offset from the beginning of the struct, but it isn't. It's relative to dwFontType. I would interpret it more as a cbSize member of an internal variable size struct., that comes before dwFlags (see below) / textmetric 2.) The current definition has a member enfdi, wich follows after a variable size struct. IMO this member should be removed, as it doesn't have a constant offset. It implies that you can simply access it, but you cannot, if the designvektor has any entries. It should be commented out to prevent misuse. 3.) The enfdi struct doesn't really make sense to me. The dwReserved members are not like axlReserved a constant. It looks more like some flags or it might be code page related. With this structure the OffsetTm member points to a substruct of a struct, that doesn't seem right to me. So here is my version: I also use INT versions of structs with a [0] array, so it matches the data, when no additional stuff is present But as we always have to consider our structs as variable length we do not really need them. In any case we have to parse through the struct. We can then typecast the pointers to the original structs and all's well. typedef struct _AXELISTINTW { DWORD axlReserved; DWORD axlNumAxes; AXISINFOW axlAxesInfo[0]; } AXELISTINTW, *PAXELISTINTW; typedef struct _ENUMTEXTMETRICINTW { NEWTEXTMETRICEXW etmNewTextMetricEx; AXELISTINTW etmAxesList; } ENUMTEXTMETRICINTW, *PENUMTEXTMETRICINTW; typedef struct { DWORD cbSize; DWORD dwFontType; ENUMLOGFONTEXW elfex; DESIGNVECTORINT dv; // variable position, might be dv.dvValues[0], if DESIGNVECTORINT was declared with dvValues[1] // I didn't yet manage to get info with dvNumAxes > 0 // DWORD dwReserved; } ENUMFONTDATAINTW, *PENUMFONTDATAINTW; typedef struct _ENUMFONTDATAW { DWORD cbSize; ENUMFONTDATAINTW efdi; // Those are not real members as they don't have a constant pos in the struct // DWORD dwFlags; // ENUMTEXTMETRICINTW etmi; } ENUMFONTDATAW, *PENUMFONTDATAW;

2 1

Re: [ros-dev] Open source drivers for (S)ATA and VESA
by Aleksey Bragin 27 Aug '07

27 Aug '07

Hi, Magnus already commented about the video driver (if his changes were good, he would send us patches). However, uniata is not that bad, I was going to review it some time after 0.3.3, and if the code is allright, it could be included. IIRC, scsiport needs some improvement in order to fully support the uniata driver. WBR, Aleksey Bragin. On Aug 27, 2007, at 8:42 PM, Timo Kreuzer wrote: > Hi, I just found some interesting stuff: > > Universal ATA driver (http://alter.org.ua/soft/win/uni_ata/) > - generic NT driver for DMA/UDMA ATA / SATA with source code > > Universal VESA driver > - based on ReactOS vbemp.sys > - works on all windows NT and ReactOS > the author has been working on this until very recently, so it > might be > better than our current driver > > Timo

1 0

Open source drivers for (S)ATA and VESA
by Timo Kreuzer 27 Aug '07

27 Aug '07

Hi, I just found some interesting stuff: Universal ATA driver (http://alter.org.ua/soft/win/uni_ata/) - generic NT driver for DMA/UDMA ATA / SATA with source code Universal VESA driver - based on ReactOS vbemp.sys - works on all windows NT and ReactOS the author has been working on this until very recently, so it might be better than our current driver Timo

2 1

State of 0.3.3
by Colin Finck 26 Aug '07

26 Aug '07

Hello, As you probably saw, I recently rebranched 0.3.3 and made some changes to it. Now I'm at the point, where *I* think that it's ready. I don't know if anyone else has any specific plans for 0.3.3, so I'm just asking here now. Otherwise, I think we could simply release the current branch as RC2 or even REL. But also if we release it as RC2 now, what are the plans for the REL version then? Please also think of our planned 2-month release cycle. I know that these are just estimated dates, where users *can* expect a release and I myself said this a couple of times as well, but we already skipped 0.3.2, so we shouldn't miss the "deadline" for 0.3.3 now. Regards, Colin

5 4

Megalithic subjects
by carlo.bramix 25 Aug '07

25 Aug '07

Hello, I don't want to make problems in any way but... is it possible to make the titles of the emails a bit shorter when it could be done? Some of them are really difficult to read and, in my opinion, the body of the email exists for writing more detailed explanations. Sincerely, Carlo Bramini

1 0

[ros-diffs] [cfinck] 28526: rbuild enhancements by Marc Piulachs
by James Tabor 25 Aug '07

25 Aug '07

Hi! r28526 broke bootcd Sorry, James

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev August 2007