wine-devel

wine-devel@winehq.org

11 participants
84440 discussions

Re: WineLib with MSVCRT
by steve.lustbader＠philips.com 17 Sep '02

17 Sep '02

I noticed in regedit's Makefile.in that it lists msvcrt, advapi32, and kernel32 in it's IMPORTS variable and has no foo_DLLS variable, whereas Winemaker by default puts most of those in the foo_DLLS variable. What's the difference between the DLLS variable and the IMPORTS variable? -Steve Andriy Palamarchuk To: Steve Lustbader/ANR/MS/PHILIPS@AMEC <apa3a(a)yahoo.com wine-devel(a)winehq.com > cc: Subject: Re: WineLib with MSVCRT 09/16/2002 03:02 PM Classification: --- steve.lustbader(a)philips.com wrote: > What is the proper way to use the MSVCRT in WineLib? Check out how Wine programs (e.g. regedit) use MSVCRT. Andriy __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

2 1

SFU port part2
by Steven Edwards 17 Sep '02

17 Sep '02

ok got configure working but some of the porting definitions are hosed. When I try to build anything I get this: ../include/wine/port.h:49: Error: conflicting types for `mode_t' /usr/include/sys/types.h:45: Error: previous declaration of `mode_t' ../include/wine/port.h:52: Warning: redefinition of `off_t' /usr/include/sys/types.h:69: Warning: `off_t' previously declared here ../include/wine/port.h:55: Error: conflicting types for `pid_t' /usr/include/sys/types.h:55: Error: previous declaration of `pid_t' ../include/wine/port.h:58: Warning: redefinition of `size_t' /usr/include/sys/types.h:89: Warning: `size_t' previously declared here ../include/wine/port.h:61: Warning: redefinition of `ssize_t' /usr/include/sys/types.h:94: Warning: `ssize_t' previously declared here Any suggestions? Thanks Steven

2 2

Re: DefineDosDevice - ??
by Martin Wilck 17 Sep '02

17 Sep '02

Am Die, 2002-09-17 um 20.48 schrieb Mike McCormack: > Did you get my other mails? I'll include the text again... they don't > seem to have made it to wine-devel, so I'm wondering if they got > anywhere at all... No they didn't, at least not to me. Thanks for resending... > BTW. The PAM module you are talking about was a goal of Samba TNG. "Was" - does that mean the project is dead? I reckon that the "winbind" module of the current Samba release is pretty close to what we want in terms of host, user, and group lookup. > I think that can be done with a NetBIOS QUERY packet with "*" as the > name to query. You'll then get every machine on your local network > sending a QUERY RESPONSE packet back to you with the machine's name. > > The operation is similar to the code to resolve a NetBIOS name (see > NB_Lookup in files/smb.c) I need yet to understand how all these things relate. Winsock may use NetBIOS as a service provider, but NetBIOS seems to offer an independent interface to other APIs as well, right? If I understand you right, the Netbios stuff is then located somewhere in kernel32. Is the winsock provider an independent package or part of the NetBIOS core? > The named pipes code needs to be rewritten to work through SMB so that > we can support DCOM clients (computer to computer). Supporting a DCOM > server is a problem because Samba is usually in the way on the ports we > need to listen to... it would be nice to have some way for Samba and > Wine to work together... a Netbios kernel module perhaps? IMO this raises more fundamental questions about the role wine should play. Samba is a service offered by the Unix system on which wine is running. If wine were to grab the NetBIOS ports, it would take over this service functionality; I doubt that's a good approach. Wine could perhaps offer services on an IP alias instead, somewhat similar as described in http://www.deschner.de/gd/dual_samba.html > shell32 manages passwords and shares through MPR.DLL. We need to add > some code to show the Network Neighbourhood icon and probe any connected > shares, connect new shares, etc to shell32. > > If you need something specific, I'll see what I can do, but a full > implementation is probably a bit much for this weekend ;-) I think it needs to be clarified what we're actually heading for. As I said, I consider it potentially dangerous if wine offers services on the network bypassing the ordinary Unix security mechanism. Acting as a client is a different story, I guess we want maximum functionality in that area. When it comes to User authentication, I am strongly for wine communicating with the Unix system (e.g. PAM). Then if PAM supports NT domain authentication (through samba or whatever), Active directory AKA LDAP authentication, etc., wine would, too. We'd just have to ensure that we don't loose too much on our way through the Unix layer. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

WineLib with MSVCRT
by steve.lustbader＠philips.com 17 Sep '02

17 Sep '02

What is the proper way to use the MSVCRT in WineLib? I tried adding a -I/usr/local/include/wine/msvcrt to the list of includes and -nostdinc to CXXEXTRA, but then gcc can't find stdarg.h, which is included in windows.h via winbase.h. If I use -nostdinc++, gcc is able to find stdarg.h, but it runs into problems with other files, such iostream.h. Finally, if I don't use either -nostdinc or -nostdinc++, gcc complains about types being redefined, such as wint_t (as an unsigned short int in /usr/include/_G_config.h but WCHAR in /usr/local/include/wine/msvcrt/wctype.h). It seems like using -nostdinc would be the right way, but does that mean that Wine needs to include its own copy of stdarg.h and related files? -Steve

3 2

PATCH: workaround for ms typo
by Michael Stefaniuc 17 Sep '02

17 Sep '02

Hello, this email is CC'ed to wine-devel because it's controversial. MS made a typo in CHOOSECOLOR (commdlg.h) and kept it till today (at least that's what msdn says): the struct member hInstance is a HWND instead of a HINSTANCE. Until now it wasn't a problem in wine but with the conversions of the handles to void* a lot of casts are necessary. And this casts are looking just wrong: cast to HINSTANCE when using the hInstance member as rvalue and cast to HWND when using it as lvalue. The casts looks so wrong so that we would need comments like "Yes, this cast is needed, see struct CHOOSECOLOR in include/commdlg.h". The attached patch fixes the typo for wine (but keeps it for compatibility reasons for winelib) and removes the need of some ugly casts. License: LGPL, X11 Changelog: Michael Stefaniuc <mstefani(a)redhat.com> - workaround for MS typo bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Direct3D v8
by Ann and Jason Edmeades 16 Sep '02

16 Sep '02

Hello, What is the current state of affairs regarding DirectX (8) support in wine. With Transgaming producing a version which appears to work well from what I read on the Internet, what is happening about getting support for it in the wine tree - Is the intention to wait and see what Transgaming do? The reason I ask - Not to start a political debate with pros and cons of Transgaming, but more because as a learning exercise with regard to 3d graphics, I started fiddling with Direct X 8 support and have some sample code which runs some simple Direct3D samples and most of a sequence of tutorials. (9 out of 11 work reasonably well). I dont have a problem with the code remaining personal to me and probably archived, as I have learnt a lot by doing it (which was my original aim), but if it is agreed that adding directx 8 support completely different to the Transgaming code is ok, then I may try to submit some patches. Note the current code is nowhere near ideal, so dont get your hopes up. Specifically, it exports X11DRV_get_client_window from X11DRV as a means of getting the X window from the HWND, which is not clean. It does not use a HAL (which is where the current ddraw code was starting to head), it calls all the opengl calls inline. I have only tested on one machine with one level of mesa (tough! thats all I have). It also has all the c parts in the d3d8 directory, completely seperate (and in some cases duplicating code from the ddraw code), which may or may not be desired. I also dont have a clue about the configure tests and makefile.in, so I have just a basic structure which works enough for me. I'm also relatively certain I havent necessarily used the highest performing code everywhere, I have done the best I could with my limited knowledge. The way I look at it would be a starting point for others to work from. I could make a drop of the code on a website if anyone wants to see how bad it is first :-) Anyway, thoughts please? Jason

8 17

Re: memory/virtual.c: ROUND_SIZE() bugfix + .SYS loading
by Alexandre Julliard 16 Sep '02

16 Sep '02

Jan Kratochvil <short(a)ucw.cz> writes: > I had incorrect warnings "Section %.8s too large (%lx+%lx/%lx)" during loading > of some low-level system libraries. It got fixed by the attached > "wine-memory-virtual.c-too_large_section.diff" which changes (I think fixes) > ROUND_SIZE() behaviour. It also comments ROUND_ADDR() and ROUND_SIZE(), I hope > I guessed its intended description from the style of its usage around the code. No, ROUND_SIZE is supposed to return an aligned size, which you use together with an aligned address. The normal pattern is to use ROUND_SIZE and ROUND_ADDR together. We don't bother to round addresses in image mapping because all the code assumes the image has correct section alignment already. > Attached "wine-memory-virtual.c-mmap_cache-preliminary.diff" is just a RFC as > I found out that I was unable to load some .SYS files as they were being > attempted to be loaded with page-overlapping sections, unaligned offsets and > incompatible protections. Therefore I had to implement my own mapping cache and > handle the overlapping/merging myself. It would be more simple/clean to use > Linux /proc/$$/maps mmap map but it would be probably no-no as it is > Linux-dependent. I think this is complete overkill. Mapping unaligned binaries is a very unusual case and should be treated as such. There's no need to maintain such a complex structure, or add support for non page aligned mmaps, for such an exotic feature. Probably what you want is to create a separate map_image_unaligned function to map images that don't have a proper section alignment, using read() and not worrying about protections at all. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Replace static initializers with a proper #define in .h files
by Alexandre Julliard 16 Sep '02

16 Sep '02

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Alexandre, your patch committed at 02/08/14 16:09:55 (Builtin modules > must be aligned on 64K boundary) completely kills any attempts to > minimize sizes of winelib executables. Is it really necessary? Yes, some apps need modules to be properly aligned. Note that this stuff will never be paged in so it only wastes a bit of disk space. -- Alexandre Julliard julliard(a)winehq.com

1 0

Question about "undefined" functions
by Sylvain Petreolle 16 Sep '02

16 Sep '02

Hi, I have problems with the following functions: 17 0x4073bf2f (USER32.DLL.GetTaskmanWindow+0xdf in user32.dll.so) (ebp=405c24d0) 18 0x4073bfa3 (USER32.DLL.GetTaskmanWindow+0x153 in user32.dll.so) (ebp=405c2508) 19 0x40742936 (USER32.DLL.CallWindowProcA+0x136 in user32.dll.so) (ebp=405c253c) 20 0x4071c21b (USER32.DLL.DispatchMessageA+0xbb in user32.dll.so) (ebp=405c2570 In some programs this call stack appears when going to debugger and is causing 0x0 read acess.Digging in the source shows that these functions are only defined by a stdcall in the spec file of user32. the result is a return '0x0000' in the user32.spec.c: "\tjmp GetTaskmanWindow\n" "\tret $0x0000\n" Are these functions intended to return 0x0 ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: winedump: selective search also by name
by Eric Pouech 16 Sep '02

16 Sep '02

> > I am missing some general utility library such as GLib, Qt, NSPR or APR to > > provide general datastructures such as hashes etc. Maybe it is provided by W32? > > Therefore /* FIXME: Replace with some hash such as GHashTable */. it'll be a bad idea to use extra libs like Qt or Glib in Wine, just for that (note also, that in your case, a simple binary search would be enough IMO (compared to the current linear search) A+

2 1

Jump to page:

2025

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