August 2004 - Wine-Devel - list.winehq.org

Re: iostream and msvcrt?

by Dimitrie O. Paun

On Wed, Aug 18, 2004 at 11:32:33AM +0300, Boaz Harrosh wrote: > >I have used STLport before > >so the idea sounds feasable to me. I imagine I have to change the > >gcc-linux.mak by: > > > >replacing the call to gcc with winegcc, > >removing references to GLIBC, > > > > > Better go with gcc-mingw.mak, as threading and OS is more Windows than > Linux. See if they have a -nocygwin variant. Yes, it should work with the gcc-mingw.mak by changing gcc -> winegcc g++ -> wineg++ > >adding a path pointing to /include/wine/MSVCRT. > > > > > > > Yes exactly. You'll see that you end up with a complete xxx-wine set of > makefiles and headers. No, you shouldn't need that. You just need to make sure you pass the -mno-cygwin flag to winegcc/wineg++. -- Dimi.

Aug. 19, 2004

Re: Wine Status - User Interface

by Dimitrie O. Paun

On Tue, Aug 17, 2004 at 07:31:33AM -0400, Tom wrote: > I haven't done the changelog so just view this againt > http://www.winehq.org/site/status_ui for changes or diff. > > commits, suggestions, and flames are welcomed Looks good! -- Dimi.

Aug. 19, 2004

Re: gethostbyname on local host returns 127.0.0.1 for address

by Juan Lang

Robert wrote: > On windows gethostbyname for the local host returns > the addresses of the available network interfaces. > On wine and unix, it only returns the localhost > 127.0.0.1. > > Any ideas on how to get the windows behavior? I assume you're referring to gethostname (as in your sample code), not gethostbyname (as in your email). Well, I guess you'd have to modify winsock/socket.c's WS_gethostname function, maybe to call GetAdaptersInfo or some such. That'll get you the addresses, anyway. If you want a name other than localhost you may want to call GetNetworkParams too. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

Aug. 19, 2004

gethostbyname on local host returns 127.0.0.1 for address

by Robert Reif

On windows gethostbyname for the local host returns the addresses of the available network interfaces. On wine and unix, it only returns the localhost 127.0.0.1. Any ideas on how to get the windows behavior? #include <stdio.h> #ifdef _WIN32 #include <winsock2.h> #include <ws2tcpip.h> #else #include <netdb.h> #endif int main(int argc, char* argv[]) { char host_name[1024]; char ** alias; struct hostent * host; unsigned int i = 0; #ifdef _WIN32 WSADATA wsaData; WORD wVersionRequested = MAKEWORD(2, 2); int error = WSAStartup(wVersionRequested, &wsaData); if (error != 0) { fprintf(stderr, "WSAStartup failed\n"); return 1; } // Confirm that the Windows Sockets DLL supports 2.2. // Note that if the DLL supports versions greater // than 2.2 in addition to 2.2, it will still return // 2.2 in wVersion since that is the version we // requested. if (LOBYTE(wsaData.wVersion) != 2 || HIBYTE(wsaData.wVersion) != 2) { fprintf(stderr, "couldn't find dll\n"); return 1; } #endif if (gethostname(host_name, sizeof(host_name)) != 0) { fprintf(stderr, "gethostname failed\n"); return 1; } printf("host: %s\n", host_name); host = gethostbyname(host_name); if (host == 0) { fprintf(stderr, "gethostbyname failed\n"); return 1; } printf("name of host: %s\n", host->h_name); for (alias = host->h_aliases; *alias != NULL; alias++) printf("alias: %s\n", *alias); printf("length of address: %d\n", host->h_length); while (host->h_addr_list[i] != 0) { struct in_addr n_addr; memcpy(&n_addr, host->h_addr_list[i], sizeof(struct in_addr)); printf("%d: %s\n", i, inet_ntoa(n_addr)); i++; } return 0; }

Aug. 19, 2004

Re: Fixed some ref handling

by Alexandre Julliard

Jacek Caban<jack(a)itma.pwr.wroc.pl> writes: > I attached two test. The first is simple and shows a problem > that the patch fixes but the second one is a more complex test. Could you please merge the test into the existing test framework? -- Alexandre Julliard julliard(a)winehq.org

Aug. 18, 2004

Re: Removed slovenian translation

by Alexandre Julliard

Jacek Caban<jack(a)itma.pwr.wroc.pl> writes: > Changelog: > Removed slovenian translation If the translation is not complete it should be fixed, or at worse commented out. Removing it doesn't make sense, we'll need to add it back someday anyway. -- Alexandre Julliard julliard(a)winehq.org

Aug. 18, 2004

Re: KERNEL: pull WINDIR and WINSYSDIR from config before using hardcoded defaults (possible fix for WWN #234, #235 c:\\windows is not accessible Error)

by Alexandre Julliard

Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > Changelog: > * if windir or winsysdir environment vars are undefined, pull values > from config file before falling to hardcoded values This of course defeats the whole purpose of the use of environment variables, which is to get rid of the config file. If the environment variables are not set it's because the user's config is wrong, they should be set in HKLM\System\CurrentControlSet\Control\SessionManager or (preferably) in HKCU\Environment. The code is supposed to migrate them automatically, but this may not always work if the registry already contains other values, in which case it needs to be fixed by hand. Going back to the config file is definitely not the right way. -- Alexandre Julliard julliard(a)winehq.org

Aug. 18, 2004

bug

by Ivan Leo Puoti

Since futimes is used instead of utime the installer of word viewer 97 has had a few installation issues. For a start, when the setup looks for installed components, it goes into a non infinite loop that lasts a few minutes. This only took a few seconds previously. I don't know what is causing this slow performance. The changelog of the patch that caused this regression says "so that it can be done on the client side.", maybe doing the call on client side makes it slow because the call has to go trough wineserver? I don't know. Also the graphics aren't redrawn until the loop ends. A relay log of the loop follows. I'm not very confident that I'll be able to fix this myself, but any help/hints are welcome. Interestingly the loop doesn't occur during a call to kernel.dll.SetFileTime() that's the function modified by the patch. The patch that causes the problem is http://cvs.winehq.org/patch.py?id=11722 Subsequent patches have obviously modified the function, but this hasn't solved the problem. MAybe the subsequent patches avoid an infinite loop (I don't remember the loop finishing with wine from a few months ago). Ivan.

Aug. 18, 2004

Re: Backtrace Dumps

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Alexandre Julliard wrote: > >>Well, I can also imagine a lot of cases where the in-process backtrace >>won't work right, the main one being that since the code will never be >>used unless you want a backtrace, when you try to use it you'll >>realize that it no longer works, or doesn't even compile anymore. If >>we call the debugger instead, it will use the standard backtrace code >>which is always compiled in, and regularly used by a lot of people. > > Do you want me to write a unit test that uses it then? No, the backtrace should be done by the debugger. -- Alexandre Julliard julliard(a)winehq.org

Aug. 18, 2004

New Fun Project - Winelib port of Allegiance

by Steven Edwards

Hi all, Microsoft Research has released a Shared Source version of the game Allegiance. This is a hefty 512 meg download and of course the license that it is under would prevent anyone from sharing the changes but this would really allow us to improve Winelib by porting such a massive game. http://research.microsoft.com/research/allegiance/ Grab your copy quick before they pull it down. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

Aug. 18, 2004