wine-devel February 2009

wine-devel@winehq.org

143 participants
298 discussions

Re: [1/2]tools/winemaker: add project-file support(try3)
by Francois Gouget 23 Feb '09

23 Feb '09

Hi, I had a look at this patch and here are some comments. The case of the filenames in the dsp and dsw files may not match the case of the filenames on the filesystem. So you need to ajsut the names before you put them in the makefile. I believe search_from() can be used for that. I see that you're translating the Visual C++ compiler flags to gcc compiler flags. That's good. But I'm not sure about the following conversion from /GX to -fexceptions. Exception handling is pretty different between windows and Unix. Do you know if /GX is about structured exception handing? I really couldn't tell, but maybe some exception expert will know. I see you're converting the /Zp1 option which is very nice (packing being one of the disagreements between Visual C++ and gcc). But you don't do it for Zp(2|4|8|16). I believe you could do it by simply appending the packing size to the '-fpack-struct=' option. (But maybe I missed something) A bigger issue is that you're putting all the compiler options in CXXEXTRA which only applies to C++ code. But in the dsp file it looks like this applies to both C and C++ code. So it probably should be put in both (except -fexceptions which seems to be on by default in C++, but that's minor). About the commented out call to fix_file_and_directory_names(), I don't think winemaker should go and modify files outside of '.'. So I think it's safe to remove this call entirely. Also I have some questions about a couple of heuristics: if ($has_headers) { push @{@$project_settings[$T_INCLUDE_PATH]},"-I."; } Is this still needed? In source_scan_directory() it was needed because we had no idea what the include path was supposed to look like. But the project file should define it clearly enough for us. However I have a dsp file in a directory with a header file and I don't see a '/I.'. So maybe it is implied? Also this part seems wrong: # Finally if we are building both libraries and programs in # this project, then the programs should be linked with all # the libraries The project file should be explicit enough on this part for us not to have to do any guessing. Also do we really need to worry much about matching source file with a given target? Won't we always have a single target per dsp file? In which case the matching can probably be simplified. The end of source_scan_project_file() looks pretty similar to the end of source_scan_directory(). Maybe some code can be shared. To make the patch smaller you can first submit the dsp parser, then the dsw one, the vcproj one, and finally the sln one. And once that's done, it would be nice to integrate this all with the regular source_scan() function, so that if it detects one of these files in the subdirectories, it invokes the appropriate project parser for that directory and stops recursing. That can be done as a further separate patch. Style issues: The style issues are at least partly my fault as I used two-space indentation and braces on the same line when I first wrote winemaker. Nowadays I'd prefer 4-space indentation with braces on their own line but that's a bit tricky when maintaining a consistent indentation. In any case, in places your code is too incoherent. For instance: } elsif(/^# TARGTYPE/) { if (/[[:space:]]0x0101$/) { # Win32 (x86) Application $prj_target_type=1; This snippet has both 2 and 4 space indentation and it's all new code. There's also an indentation problem there: } } foreach my $source (@sources_misc) { if ($source =~ /^$basename/i) { Personnally I'd recommend to maintain a consistent indentation scheme at least per function (though the policy is more to be consistent per file normally :-/ ). Also, I'd prefer to have a space between 'if' and the prentheseses and braces. You can also simplify a some string concatenations. Replace: $prj_target_cflags=$prj_target_cflags."-D".$1." "; with $prj_target_cflags.="-D$1 "; In any case, thanks for taking this on. I think you're pretty close to the end (even if you don't feel that way after reading the above<g>). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.

1 0

Re: msctf: add internal function for handling TfClientIds
by James Mckenzie 23 Feb '09

23 Feb '09

Alexandre Julliard <julliard(a)winehq.org> wrote on Feb 23: > >Aric Stewart <aric(a)codeweavers.com> writes: > >> + /* If i understand this correctly at most a process should generate >> + * only a handful of these... But in case I am wrong */ >> + if (id_last == 65535) >> + { >> + ERR("TfClientIds generated exceeds USHORT limit\n"); >> + return 0x0; >> + } >> + id_last++; >> + id->id = MAKELONG(id_last, magic); >> + id->data = data; >> + list_add_head(&clientids,&id->entry); > >Using an array index would be cleaner than having to search through the >list everytime you use an id. > Also, aren't linked lists inefficient as well. Searching through them can be very intense, unless they are small (< 5 elements). Anything larger than this and an array would be more efficient. James McKenzie

2 1

Re: [7/7] setupapi/tests: start dialog.c test file with a test for SetupPromptForDiskA
by Paul Vriens 23 Feb '09

23 Feb '09

Ricardo Filipe wrote: > > > ------------------------------------------------------------------------ > > Hi, Could you turn that skip() into a win_skip()? Usually it's a good idea to do a SetLastError(0xdeadbeef or something like that) before calling the function, especially because you are relying on that last error for the ok() test. -- Cheers, Paul.

2 1

Re: ole32: change a pointer cast from DWORD to DWORD_PTR
by Rob Shearman 23 Feb '09

23 Feb '09

2009/2/22 Austin English <austinenglish(a)gmail.com>: > diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c > index b8ddba8..7360f66 100644 > --- a/dlls/ole32/compobj.c > +++ b/dlls/ole32/compobj.c > @@ -2007,7 +2007,7 @@ HRESULT WINAPI CoRegisterClassObject( > * Use the address of the chain node as the cookie since we are sure it's > * unique. FIXME: not on 64-bit platforms. > */ > - newClass->dwCookie = (DWORD)newClass; > + newClass->dwCookie = (DWORD_PTR)newClass; > > /* > * Since we're making a copy of the object pointer, we have to increase its Since dwCookie is of type DWORD this is just hiding the problem. The correct solution is to store a process-wide index and then to increase this every time a class object is registered and use it for the cookie. CoRevokeClassObject already looks through the list of registered classes to find the cookie so this doesn't need to be changed. -- Rob Shearman

1 0

Re: Win to Lin Library Wrapper
by King InuYasha 23 Feb '09

23 Feb '09

On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson <chris.kcat(a)gmail.com>wrote: > On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote: > > I had an interesting thought the other day, and that is to having some > > built in support for forwarding windows dlls to linux .so's. > > IIRC, this kind of thing is generally discouraged, except in cases where > needed (eg. opengl32). Part of the problem is internal differences.. for > example, what would a Linux .so do if it's given a Win32 filename path? > Other > problems would be if the Linux equivalent wants a Window for a function > argument and the DLL wants an HWND instead, or if the DLL has > more/different > functions (eg. CUDA on Win32 has functions for dealing with D3D objects; > CUDA > on Linux doesn't, and it wouldn't be straight forward to even implement > them > through wined3d). > > Something like OpenGL, and even OpenAL to some degree, would directly > benefit > from having the DLLs forwarded to their host equivalents as it provides > better > access to the hardware and better integration with the host system. > Something > like zlib or ogg/vorbis and stuff wouldn't though, since the code should > largely be the same, and save for some bugs/inefficiencies in Wine (which > should be fixed), would work identically. > > > Does Wine yet have the capability to interface with HAL for Win32 hardware access similar to NT? It looks like it doesn't from all this talk of forwarding DLLs. What we should do instead of trying to forward DLLs, which is asking for more trouble than its worth, is try to get the NT layer to connect to UNIX HAL so that DLLs can link directly to HAL and operate the hardware.

6 11

Re: msctf: add internal function for handling TfClientIds
by Alexandre Julliard 23 Feb '09

23 Feb '09

Aric Stewart <aric(a)codeweavers.com> writes: > + /* If i understand this correctly at most a process should generate > + * only a handful of these... But in case I am wrong */ > + if (id_last == 65535) > + { > + ERR("TfClientIds generated exceeds USHORT limit\n"); > + return 0x0; > + } > + id_last++; > + id->id = MAKELONG(id_last, magic); > + id->data = data; > + list_add_head(&clientids,&id->entry); Using an array index would be cleaner than having to search through the list everytime you use an id. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3d8: some 64-bit fixes
by Henri Verbeet 23 Feb '09

23 Feb '09

2009/2/23 Austin English <austinenglish(a)gmail.com>: > + STDMETHOD(ApplyStateBlock)(THIS_ DWORD_PTR Token) PURE; > + STDMETHOD(CaptureStateBlock)(THIS_ DWORD_PTR Token) PURE; > + STDMETHOD(DeleteStateBlock)(THIS_ DWORD_PTR Token) PURE; > + STDMETHOD(CreateStateBlock)(THIS_ D3DSTATEBLOCKTYPE Type,DWORD_PTR * pToken) PURE; Which version of the DXSDK does this match?

2 2

Re: user32: change a pointer cast from DWORD to DWORD_PTR
by Austin English 23 Feb '09

23 Feb '09

2009/2/22 Austin English <austinenglish(a)gmail.com>: > -- > -Austin > Ignore this patch please. -- -Austin

1 0

Greatings
by Piotr Skólski 22 Feb '09

22 Feb '09

Hi. I want help you. I know c glibc and svn. I don't know git(but i'm leraning) and winapi(i don't know how learn without windows). Where my skils will be usefull. I have StarCraft and i want help you with dib engine but my skils are still too low (i don't know how patch my git tree with max dib engine). Bye. Piotr Skólski (SQLek) <sql7(a)wp.pl>

2 1

Wine download page usability problem
by Dan Kegel 22 Feb '09

22 Feb '09

I got email from a friend who complained how hard it was to install wine. Turns out he assumed he had to go to winehq.org and follow the download instructions there, when all he needed to do was do Applications / Add/Remove and pick Wine. Can we add in a line at the top saying "Stable version 1.0.1 of Wine can usually be installed just like any other Linux application using your package manager (e.g. in Ubuntu, do Applications / Add/Remove, select Wine, and click Apply Changes). If that doesn't work, or if you need a newer version of Wine, here's how to get it." ? I know, that clutters things even more. Suggestions for achieving the same thing more concisely would be welcome. I think we should also move the text "This endorsement is the primary recognition that CodeWeavers has requested in exchange for hosting the Wine web site." to the bottom of the page, and change it to read "Thanks to CodeWeavers for hosting WineHQ.org". - Dan

17 30

← Newer
1
2
3
4
5
6
7
8
9
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel February 2009