wine-devel

wine-devel@winehq.org

8 participants
84486 discussions

Re: unmanaged windows
by Alexandre Julliard 14 Sep '01

14 Sep '01

Bobby Bingham <uhmmmm(a)ameritech.net> writes: > I think there was a discussion a while back about possibly rewriting the > "unmanaged" mode (or adding a new mode, I don't recall which) to make it more > like XMMS, but I can't find it now. This would really help on my system, as > with KDE 2.2, wine windows are always on top and on every desktop and XMMS > fits in a little better. I was wondering what the result if any, of that > discussion was. I was planning to implement that as part of the new window management stuff. But this is on hold at the moment while I'm finishing the shared window handles. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Problem with specmaker
by Guy L. Albertelli 13 Sep '01

13 Sep '01

-----Original Message----- From: Patrik Stridvall <ps(a)leissner.se> To: 'eric pouech' <eric.pouech(a)wanadoo.fr>; Guy L. Albertelli <galberte(a)neo.lrun.com> Cc: Wine Devel <wine-devel(a)winehq.com> Date: Thursday, September 06, 2001 5:59 PM Subject: RE: Problem with specmaker > >Hmm. Thinking, modifying etc. > >What about this? > >Index: wine/tools/specmaker/function_grep.pl >=================================================================== >RCS file: /home/wine/wine/tools/specmaker/function_grep.pl,v >retrieving revision 1.1 >diff -u -u -r1.1 function_grep.pl >--- wine/tools/specmaker/function_grep.pl 2001/01/04 19:45:50 1.1 >+++ wine/tools/specmaker/function_grep.pl 2001/09/06 21:50:26 <snip> No the above patch merely resulted in an infinite loop. After much consultation with "Perl in a Nutshell", I came up with the following patch. The header file in question is "shlobj.h". The patch has two sections. First gets rid of the \n imbeded with the lookahead for preprocessor statements. The second gets rid of the ICOM_DEFINE statement (poorly I know) because it has no ";". This seems to make things work and generate correct headers. Thanks, Guy

1 0

dlls/advapi32/crypt.c
by Morten Welinder 13 Sep '01

13 Sep '01

Someone added code to CryptGenRandom so that it generates very bad random data (with <10 bits randomness in them). Don't do that. It's a known security risk. Read from /dev/urandom instead. If that does not succeed, just abort(). Linux and newer Solaris have /dev/urandom. I would guess the BSDs have it too. Morten

2 1

wcs* functions within Wine
by Huw D M Davies 13 Sep '01

13 Sep '01

Hi, I want to use wcsrchr and wcstrol in oleaut32.dll . If I just use them then we do indeed call the ntdll versions rather than libc which is all very nice. The question is, what include file am I supposed to use to get their protoypes? Huw.

1 0

unmanaged windows
by Bobby Bingham 13 Sep '01

13 Sep '01

I think there was a discussion a while back about possibly rewriting the "unmanaged" mode (or adding a new mode, I don't recall which) to make it more like XMMS, but I can't find it now. This would really help on my system, as with KDE 2.2, wine windows are always on top and on every desktop and XMMS fits in a little better. I was wondering what the result if any, of that discussion was. Bobby Bingham -- Microsoft Windows: Made for the internet The Internet: Made for UNIX

1 0

Re: negative listview column width in WinZip 8.0
by Malte Starostik 13 Sep '01

13 Sep '01

Am Thursday 13 September 2001 03:37 schrieben Sie: > WinZip 8.0 requests a negative column width for one of the columns in > the WinZip classic Zip file contents list. This stuffs up the list, > causing the other columns to be overwritten, and resulting in a blank > list. > > This patch prevents column widths from being negative. AFAIK, -1 and -2 and maybe others are special values that tell the list view to adjust the contents to the widest item and something else I cannot remember exactly (sorry, no Windows available ATM). -- Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787] http://malte.homeip.net/justice-not-war.html M0ò0ò0

1 0

winedump prints a strange export table
by Francois Gouget 13 Sep '01

13 Sep '01

If I run 'winedump dump ws2_32.dll -j export' I get a strange result: ... 00000000 125 <by ordinal> 00000000 126 <by ordinal> 00000000 127 <by ordinal> 00000000 128 <by ordinal> ... Are these really significant? It seems like they go all the way up to the highest ordinal of a 'real' exported function, here 500, WEP. Also if I run 'winedump dump msvcrt.dll -j export -C' winedump seems to crash. It looks like it tries to interpret mangled names as glibc mangled names? Hmm, '-C' seems to have trouble even with other dlls. Christian Jiresjö expressed interest in working on winedump (see bug #91), maybe these would be good bugs for him to takle. Btw eric, thanks for the thread patch in winedbg. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

1 0

HAVE_IPX cleanup
by Francois Gouget 12 Sep '01

12 Sep '01

This patch attempts to clean up the ws_sockaddr_ipx to sockaddr_ipx conversions (and vice versa). I would really like if people could try this out: I don't have a working IPX network here. At least my very rudimentary tests indicate that this should still work for the TCP/IP case. More details on the patch: * all ws_sockaddr structures must be considered to have a potentially different layout from their Unix counterparts. Sure for now we just borrow the Unix structs anyway but even sockaddr_in does not have the exact same fields on FreeBSD and Linux (although the binary layout is the same). And hopefully we will not borrow the Unix structs for long anyway. FreeBSD testing is another aspect I would appreciate help with (sin_len worries me). * the ws_sockaddr_ipx fields did not match those used by windows. Also ws_sockaddr_ipx was declared in the wrong header. * all conversions are now done in two functions: ws_sockaddr_ws2u and ws_sockaddr_u2ws. If there is a conversion to do then these are the only two places that should be affected. SUPPORTED_PF returns whether a given protocol family is supported or not. * the sockaddr* pointers may point to structures that are more than 16 bytes, typically 28 bytes for IP v6. I tried to take this into account, I hope I did not mess up (but I'm not sure Wine would support TCP/IP v6 anyway). * I modified WSOCK32_accept to call WSOCK32_getpeername thus avoiding the conversion issue entirely in WSOCK32_accept. * all other functions that were doing such conversions were modified to use the above functions. I also tried to make the error handling code more consistent wrt. WSAENOTSOCK, WSAEAFNOSUPPORT, etc. * removed ugly casts in the traces -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

1 0

Russian keyboard layout
by Andriy Palamarchuk 12 Sep '01

12 Sep '01

Hello everybody, I want to fix message about not found keyboard layout for my configuration. The FIXME message is not shown after I add a phantom key definition to russian keyboard layout main_key_RU in file windows/x11drv/keyboard.c I need your advise how to do it correctly. Should I change existing layout - main_key_RU or it is better to add a separate one with phantom key - main_key_RU_phantom, like it is presently done for US layouts? I could not suppress the FIXME message by changing keyboard model in XF86Config from "pc102" to "pc101". My system: Wine release 20010824, installed without Windows, gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) The layout, defined in XF86Config is "ru(winkeys)". Thank you, Andriy Palamarchuk

1 0

Solaris winsock support
by Robert Lunnon 12 Sep '01

12 Sep '01

Trying Eudora 4.3 on Solaris solicits this error err:winsock:WsControl Unable to open /proc filesystem to determine number of network interfaces! Looking about in the code WsControl grubs about in the /proc filesystem to get the names of, and count the number of network interfaces. Since /Proc only hosts processes on Solaris this constitutes a linux dependancy we don't need. Studying the ifconfig source gives another possibility instead which look like it may be more portable using ioctl SIOCGIFCONF on an arbitrary IP socket The return from this call is a structure containing the length of the reply buffer, which seems to contains an array of ifreq structures (one for each interface) which contains among other things the name of the interface. By dividing the size of the buffer by the size of the returned objects we know how many interfaces there are... Questions Anyone know if this is Is this workable ? Is this workable on linux, (I ask because I don't have linux and don't know linux ioctl implementation details)?

3 2

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