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
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!
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
>
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;
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
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
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
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
