Ros-dev

ros-dev@reactos.org

5790 discussions

0.33rc2?
by Bernd Blaauw 30 Aug '07

30 Aug '07

Is there going to be a new release candidate of ReactOS version 0.3.3? I tested it very shortly and was very impressed with how it looked in comparison to version 0.3.0. Is there a list of known bugs as feedback from 0.3.3rc1 testers? Searching through Bugzilla might be a bit too much :). Anyway, the issues I experience in VMware 6.00 on WinXP Pro x64 host so far are: * diskette drive not visible (and/or working). Ever since 0.2.8 or so? * shutdown does not close the virtual machine (might be improper shutdown). Screen goes all black and need to enter VMware menu to shutdown the ReactOS virtual machine. Is the AUTORUN.INF by now the only file on the root of the CD? icons and readme files can go in subdirectories I guess, which makes adding ReactOS to multi-installation CDs a lot easier (a CD/DVD containing setup or LiveCD of various operating systems, mostly using the Isolinux bootloader for a frontend menu and chainloading bootsectors). I've not extensively tested the RC1 on for example if it still can complete installation and bootup with 32MB or less RAM installed (VMware allows anywhere from 4MB to 8GB in increments of 4MB, Bochs/Qemu allow 1MB increases). A resolved item I noticed in this new release was the ability to enter digits for the computername, wasnt possible previously in 0.3.0 or 0.3.1. ReactOS is getting interesting by now..a Win32 operating system with a size of about 50MB and capable of playing huge games sooner or later. Looks like a blessing to my limited size (16GB) DRAM based solid state disk.

4 4

[ros-diffs] [jimtabor] 22523: GetGlyphOutline, large wine port. Still testing.
by James Tabor 30 Aug '07

30 Aug '07

Hi, I have it half way done. Run the test program and you can see. Program works in W2k, XP and Wine. mingw32-gcc -mwindows -Os GetGlyphOutline.c -o ggo.exe I stopped messing with it two weeks ago, I needed to work on something else. When testing you can select the alphanumeric character with the keyboard. The original program had "a" but I changed it to "L" something simple to draw at first. You will see the problem. The test program from Dr. Dobb's Journal http://www.ddj.com/184409154?pgno=12 Thanks, James Runs and hides~

1 1

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

29 Aug '07

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

3 2

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

29 Aug '07

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

1 0

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

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