- Wine-Devel - list.winehq.org

RE: LPT0 support with DOSFS_OpenDevice
by E Lea Sept. 8, 2003

Sept. 8, 2003

> If the code is essentially the same anyway, it might be a good idea just > to add a switch in server/serial.c and to the create_serial request to > tell the server whether the device is a serial port or a parallel port, > then change serial/parallel behaviour depending on that switch. You can > also use serial_get_info to return a flag saying that you're dealing > with a parallel port if necessary. > > It's probably better to avoid duplication of the code unless necessary. I perhaps worded my original mail badly. The code is the same only as far as I used the same function and variable names (but s/serial/parallel/). The actual functions themselves have some significant differences. Putting conditions all over the serial stuff doesn't seem the most elegant way of implementing this. But if that's what it will take to get my patch accepted then I'll get onto it.

1 0

Re: PATCH - Build wrc with MS_VC and PSDK
by Dmitry Timoshkov Sept. 8, 2003

Sept. 8, 2003

"Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > Changelog: > LanguageID Porting for WRC. > +#if !defined(_MSC_VER) && defined(__GNUC__) > +#ifndef __MINGW32__ > + , > + { LANG_BRETON, SUBLANG_NEUTRAL, 1252 }, > + { LANG_CORNISH, SUBLANG_NEUTRAL, 1252 }, > + { LANG_ESPERANTO, SUBLANG_NEUTRAL, 1252 }, > + { LANG_GAELIC, SUBLANG_NEUTRAL, 1252 }, > { LANG_WALON, SUBLANG_NEUTRAL, 1252 }, > { LANG_WELSH, SUBLANG_NEUTRAL, 1252 } > +#endif /* __MINGW32__ */ > +#endif /* !defined(_MSC_VER) && defined(__GNUC__) */ > }; I'd suggest to leave all the LANG_xxx on their appropriate places and instead of protecting them by ugly #if !defined(_MSC_VER) && defined(__GNUC__) #ifndef __MINGW32__ construct use simple #ifdef LANG_BRETON { LANG_BRETON, SUBLANG_NEUTRAL, 1252 }, #endif etc. -- Dmitry.

1 0

mine is better!
by Gregory M. Turner Sept. 8, 2003

Sept. 8, 2003

whee! another glibc mystery... greg(a)bad-penguin wine_bld_nat $ wine Segmentation fault greg(a)bad-penguin wine_bld_nat $ strace wine [[ snip ]] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4035e000 mprotect(0x4002e000, 729088, PROT_READ|PROT_WRITE) = 0 mprotect(0x4002e000, 729088, PROT_READ|PROT_EXEC) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0x4035e980, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0x40017000, 93917) = 0 brk(0) = 0x3c002000 brk(0x3c003000) = 0x3c003000 set_thread_area({entry_number:-1 -> 7, base_addr:00000000, limit:0, seg_32bit:0, contents:0, read_exec_only:1, limit_in_pages:0, seg_not_present:1, useable:0}) = 0 set_thread_area({entry_number:7, base_addr:0x400fee60, limit:4095, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:0, seg_not_present:0, useable:0}) = 0 open("/opt/wine/lib/wine/ntdll.dll.so", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\360\1"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=4166825, ...}) = 0 close(3) = 0 open("/opt/wine/lib/wine/kernel32.dll.so", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0000\2"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=3495695, ...}) = 0 mmap2(NULL, 949024, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4035f000 mprotect(0x4042f000, 97056, PROT_NONE) = 0 mmap2(0x4042f000, 98304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xd0) = 0x4042f000 close(3) = 0 mprotect(0x4035f000, 851968, PROT_READ|PROT_WRITE) = 0 mprotect(0x4035f000, 851968, PROT_READ|PROT_EXEC) = 0 mprotect(0x40227000, 5, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x40227000, 5, PROT_READ|PROT_EXEC) = 0 mprotect(0x402f7000, 5, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x402f7000, 5, PROT_READ|PROT_EXEC) = 0 mprotect(0x402f4000, 5, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x402f4000, 5, PROT_READ|PROT_EXEC) = 0 getcwd("/home/greg/src/wine/wine_bld_nat", 512) = 33 getuid32() = 1000 socket(PF_UNIX, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory) close(3) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ greg(a)bad-penguin wine_bld_nat $ gdb /opt/wine/bin/wine GNU gdb 5.3 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (gdb) run Starting program: /opt/wine/bin/wine Program received signal SIGSEGV, Segmentation fault. 0x4000bba7 in _dl_init_internal () from /lib/ld-linux.so.2 (gdb) bt #0 0x4000bba7 in _dl_init_internal () from /lib/ld-linux.so.2 #1 0x4027fdd0 in _IO_link_in_internal () from /lib/libc.so.6 #2 0x4027d546 in _IO_new_file_init () from /lib/libc.so.6 #3 0x40272d94 in __fopen_internal () from /lib/libc.so.6 #4 0x40272e0e in fopen@@GLIBC_2.1 () from /lib/libc.so.6 #5 0x402f5786 in nss_parse_file () from /lib/libc.so.6 #6 0x402f52a3 in __nss_database_lookup () from /lib/libc.so.6 #7 0x402f6f95 in __nss_passwd_lookup () from /lib/libc.so.6 #8 0x402b91cf in getpwuid_r@@GLIBC_2.1.2 () from /lib/libc.so.6 #9 0x402b8ad8 in getpwuid () from /lib/libc.so.6 #10 0x40109a10 in init_paths () at ../../../wine/libs/wine/config.c:112 #11 0x40109e25 in wine_get_server_dir () at ../../../wine/libs/wine/config.c:193 #12 0x4009ce8a in CLIENT_InitServer () at ../../../wine/scheduler/client.c:641 #13 0x4009e3f6 in process_init (argv=0xbffff444) at ../../../wine/scheduler/process.c:306 #14 0x4009ea28 in __wine_process_init (argc=1, argv=0xbffff444) at ../../../wine/scheduler/process.c:480 #15 0x4010bb99 in wine_init (argc=1, argv=0xbffff444, error=0xbfffeff4 "", error_size=1024) at ../../../wine/libs/wine/loader.c:428 #16 0x3c000540 in main (argc=1, argv=0xbffff444) at ../../wine/miscemu/main.c:33 #17 0x4022748e in __libc_start_main () from /lib/libc.so.6 (gdb) up #1 0x4027fdd0 in _IO_link_in_internal () from /lib/libc.so.6 (gdb) #2 0x4027d546 in _IO_new_file_init () from /lib/libc.so.6 (gdb) #3 0x40272d94 in __fopen_internal () from /lib/libc.so.6 (gdb) #4 0x40272e0e in fopen@@GLIBC_2.1 () from /lib/libc.so.6 (gdb) #5 0x402f5786 in nss_parse_file () from /lib/libc.so.6 (gdb) #6 0x402f52a3 in __nss_database_lookup () from /lib/libc.so.6 (gdb) #7 0x402f6f95 in __nss_passwd_lookup () from /lib/libc.so.6 (gdb) #8 0x402b91cf in getpwuid_r@@GLIBC_2.1.2 () from /lib/libc.so.6 (gdb) #9 0x402b8ad8 in getpwuid () from /lib/libc.so.6 (gdb) #10 0x40109a10 in init_paths () at ../../../wine/libs/wine/config.c:112 112 struct passwd *pwd = getpwuid( getuid() ); (gdb) list 100 95 { 96 int len = strlen( path ); 97 while (len > 1 && path[len-1] == '/') path[--len] = 0; 98 } 99 100 /* initialize all the paths values */ 101 static void init_paths(void) 102 { 103 struct stat st; 104 char *p; (gdb) list 105 106 const char *home = getenv( "HOME" ); 107 const char *user = NULL; 108 const char *prefix = getenv( "WINEPREFIX" ); 109 110 #ifdef HAVE_GETPWUID 111 char uid_str[32]; 112 struct passwd *pwd = getpwuid( getuid() ); 113 114 if (pwd) (gdb) 115 { 116 user = pwd->pw_name; 117 if (!home) home = pwd->pw_dir; 118 } 119 if (!user) 120 { 121 sprintf( uid_str, "%d", getuid() ); 122 user = uid_str; 123 } 124 #else /* HAVE_GETPWUID */ (gdb) q The program is running. Exit anyway? (y or n) y WTH is going on? Any ideas? I thought it might be my ati binary graphics drivers, (although this was never a problem before), so I put them in "wine TLS compatibility mode", or whatever, but no change. Maybe something with my new 260-test4 kernel? Running a simple test program which does getpwuid( getuid() ) works fine. I do not buy, in the final analysis, that this is anything to do with nss or nscd (which I don't even run, although running it doesn't fix anything)... in fact I have a wierd suspicion that it really has to do with the server socket thingy in /tmp/.wine-greg/... creepy, and frustrating... but disturbingly, kind of fun :) As usual, it's probably my fault, moronic and totally avoidable. -- gmt "We have to get basically voters to say 'I'd like to vote for the politician who thinks of global equity'" -- Bill Gates, World Economic Forum 2002

2 2

Question regarding development..
by Jon Brandenburg Sept. 7, 2003

Sept. 7, 2003

Hi, I've read many of the various articles/faq's etc posted on the winehq.com website, but I have not encountered any so far the really answer my question. My question is this, I have a Universal Subscription to MSDN which includes among other things, debug versions of the operating systems. Am I allowed to run debug os in connection with say a piece of test code, with the purpose of extracting the necessary api information/functionality so it can be rewritten into wine or must I treat it as a black box and ignore the debug versions that I possess? If my question isn't clear enough I'd be happy to restate it. Thanks! Jon PS: I did just have the idea to actually check the license included with the debug os version to see what if anything that it states.. hmm lets see...

2 1

Re: Latest CVS doesnt compile
by Rolf Kalbermatter Sept. 7, 2003

Sept. 7, 2003

Jon Brandenburg <jbrandenburg(a)yahoo.com> wrote: >On Sat, 2003-09-06 at 16:36, Ian Goldby wrote: >> >> and occurs 2-3 hours into the build. Thanks for any further suggestions. > >Speaking of compile times.. what are the average/min/max times for >compiling the complete system? I was surprise when it took my system 12 >minutes to do it do a full cvs 'make depend && make'. Now after seeing >this message I have much to be grateful for. On my Athlon 2000+ with standard Suse 8.2 AMD Athlon kernel 2.4.19, I get about 15 minutes or so for everything from ./configure until make, after a make clean. As to the original problem. I had some to. Turned out to be missing include statements in not yet committed source files after Fridays header include cleanup. Rolf Kalbermatter

1 0

Papers on legal aspects of reverse engineering
by Dan Kegel Sept. 7, 2003

Sept. 7, 2003

Somebody was asking about what is allowed with respect to using Microsoft SDKs when writing Wine code. I have no answer for his question, but did spend a few minutes digging up interesting bookmarks on reverse engineering in general. Maybe they'll be of some interest. http://reengineer.org/ http://www.chillingeffects.org/reverse/faq.cgi http://www.digital-law-online.com/lpdi1.0/treatise25.html http://www.digital-law-online.com/lpdi1.0/treatise48.html http://www.sims.berkeley.edu/~pam/papers/l&e%20reveng5.pdf http://www.law.cornell.edu/commentary/intelpro/chn95int.htm http://www.lawplusplus.com/column10.htm http://www.lgu.com/publications/softcopy/12.shtml http://research.sun.com/people/cristina/legal-computing-publications.html - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Porting radio driver from MS to Linux
by Arjen Verweij Sept. 7, 2003

Sept. 7, 2003

Hi, I am looking to port a MSVC++ driver to Linux. The recommended approach, to convert the Makefile and compile it didn't work for me, so I am trying to compile seperate cpp.files by implementing the winapi functions I need in a seperate linuxapi.cpp There are about 30 functions I have to port at the moment, and some of them are easier than others. Basically they are part of the DLL (so), thread/event/mutex, File*Find apis, with some miscellaneous ones. I think I could do myself a favor by asking if the MSVC++ code could use libpthread instead of the MS threads, so I'm not too worried about those, and simulating DLL with the dl* api seems easy enough as well. Still, there are problems with Find*File, FindClose, GetModuleFileName and so on. I'm not too familiar with winapi myself, because I learn C/C++ in a college environment, where most programming assignments are geared towards Linux. Can anyone comment sensibly on this? If you are of the opinion that I should just rewrite the app from scratch, I agree in part, but the assignment is to leave as much of the original code as it is, apart from isolated cases where g++ can't quite follow the MSVC++ compiler. At the end of the email is a list of prototypes included, that I ripped from winbase.h Looking forward to read your thoughts on this matter, Regards, Arjen Verweij Here is the list: DWORD GetModuleFileName(HMODULE, LPTSTR, DWORD); HANDLE FindFirstFile(LPCSTR lpFileName, LPWIN32_FIND_DATA lpFindFileData); BOOL FindNextFile(HANDLE hFindFile, LPWIN32_FIND_DATA lpFindFileData); BOOL FindClose(HANDLE hFindFile); BOOL SetEvent(HANDLE hEvent); FARPROC GetProcAddress(HMODULE hModule, LPCSTR lpProcName); HMODULE LoadLibrary(LPCSTR lpLibFileName); BOOL FreeLibrary(HMODULE hLibModule); HANDLE CreateMutex(LPSECURITY_ATTRIBUTES lpMutexAttributes, BOOL bInitialOwner, LPCSTR lpName); DWORD WaitForMultipleObjects(DWORD nCount, CONST HANDLE *lpHandles, BOOL bWaitAll, DWORD dwMilliseconds); BOOL CloseHandle(HANDLE hObject); BOOL ReleaseMutex(HANDLE hMutex); DWORD GetCurrentProcessId(VOID); HANDLE CreateEvent(LPSECURITY_ATTRIBUTES lpEventAttributes, BOOL bManualReset, BOOL bInitialState, LPCSTR lpName); VOID Sleep(DWORD dwMilliseconds); BOOL ResetEvent(HANDLE hEvent); DWORD _beginthread(void(__cdecl *start_address) (void*), unsigned, void*); VOID OutputDebugString(LPCSTR lpOutputString); DWORD WaitForSingleObject(HANDLE hHandle, DWORD dwMilliseconds); void _endthread(void); BOOL ReleaseSemaphore(HANDLE hSemaphore, LONG lReleaseCount, LPLONG lpPreviousCount); HANDLE CreateSemaphore(LPSECURITY_ATTRIBUTES lpSemaphoreAttributes, LONG lInitialCount, LONG lMaximumCount, LPCSTR lpName); BOOL UnmapViewOfFile(LPCVOID lpBaseAddress); HANDLE CreateFileMapping(HANDLE hFile, LPSECURITY_ATTRIBUTES lpFileMappingAttributes, DWORD flProtect, DWORD dwMaximumSizeHigh, DWORD dwMaximumSizeLow, LPCSTR lpName); DWORD GetLastError(VOID); LPVOID MapViewOfFile(HANDLE hFileMappingObject, DWORD dwDesiredAccess, DWORD dwFileOffsetHigh, DWORD dwFileOffsetLow, DWORD dwNumberOfBytesToMap);

4 3

Dynamically altering drive mappings at runtime
by Mike Hearn Sept. 7, 2003

Sept. 7, 2003

.... and on a slightly related note, I am wondering how hard it would be to allow wine to alter drive mappings at runtime. The reason I ask is that it'd be nice for the "add drive" dialog in winecfg to use the shell directory chooser that shows all directories on the system rather than forcing the user to type in a path manually, which is error prone. To do that, of course we need a few things: * the ability to map / if it's not already mapped (or maybe we should just force / to always be mapped to drive Z in the wine code) * the ability to switch off drive letters showing through in the directory chooser dialog, so it's less confusing to see this magic letter appear. Thoughts on how hard this is? thanks -mike

3 2

Using fontconfig
by Mike Hearn Sept. 7, 2003

Sept. 7, 2003

Hi to anybody who knows about fonts, It'd be nice to use fontconfig in future to locate font installation paths. There is a simple API: FcStrList FcConfigGetFontDirs (FcConfig *config); which should let us use a small part of it, even if we don't use all of it. It means we don't need to make the user manually configure font paths. Does anybody know how hard this would be? thanks -mike

2 1

Problems with libartsc.so
by jeff_latimer Sept. 7, 2003

Sept. 7, 2003

I have just upgraded to RedHat 9 and when I make wine it can't link in libartsc.so . Looking in /usr/lib there is a libartsc.so.0 not libartsc.so . Is this normal? Jeff ---------------- Powered by telstra.com

2 1