Ros-dev

ros-dev@reactos.org

5788 discussions

Re: [ros-dev] Will ROS and WINE still be steady be synchronized ?

by theUser BL

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

17 years

Re: [ros-dev] Will ROS and WINE still be steady be synchronized ?

by Aleksey Bragin

As I already said, the difference between ReactOS and WINE, as it's written in that Wine mailing list, is that ReactOS "is known" [by some] for reversing MS binaries, and Wine is not known for reversing MS binaries (though it does not imply ReactOS is always doing it, and Wine did [does] not reverse engineer). Also, Wine is not "Open Source community", it is *part* of Open source community, as are thousands of other projects, which somehow form the general perception of projects. WBR, Aleksey Bragin. On Aug 29, 2007, at 7:01 PM, Marc Piulachs wrote: > > Does it mean ReactOS is not respected/trusted among the Open Source > community for disassembling Microsoft binaries? > > I don't know if this accusation is really true or not but if it's > not I > think it's even worse because that means that something is failing > (probably > communication) between the project and the OS community. Doing > nothing about > that is IMHO a very bad idea. > > I think it deserves some deep reflection and a *serious* strategy > to change > that general opinion. Earn respect is a KEY thing to do if the > project wants > to attract new developers. > > My two cents, > Marc

17 years, 1 month

Re: [ros-dev] Will ROS and WINE still be steady be synchronized ?

by Aleksey Bragin

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

17 years, 1 month

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

by Alex Ionescu

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

17 years, 1 month

Wine-WordPad instead of ROS-WordPad?

by theUser BL

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!

17 years, 1 month

Re: [ros-dev] State of 0.3.3

by carlo.bramix

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 >

17 years, 1 month

ENUMFONTDATAW structure

by Timo Kreuzer

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;

17 years, 1 month

Re: [ros-dev] Open source drivers for (S)ATA and VESA

by Aleksey Bragin

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

17 years, 1 month

Open source drivers for (S)ATA and VESA

by Timo Kreuzer

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

17 years, 1 month

State of 0.3.3

by Colin Finck

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

17 years, 1 month

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev