wine-devel July 2001

wine-devel@winehq.org

62 participants
189 discussions

Wine doesn't seem to like TrueType fonts.
by David Hagood 21 Jul '01

21 Jul '01

Has anybody else seen this behavior: I have a directory of TrueType fonts that I can point xfs to. When I have that directory in the fontlist, wine ALWAYS regenerates the font cache on every start (thus slowing Wine down immensely). Remove the TrueType directory from the font table, and all is well: Wine will regenerate the font cache once, and then use the font cache from there on.

1 0

Marshaling
by Daniel Walker 21 Jul '01

21 Jul '01

From what I've read when someone creates a custom interface for COM, an IDL file is generated, then the MIDL compiler uses the IDL file to create proxy and stub code that works with the standard COM RPC functionality.. So under some (most) circumstances wine's COM implementation would only have to facilitate the sending and recieving of the marshaled data .. Not to minimize the work involved .. The standard marshaling would have to do all the generic COM interfaces like IUnknown, IStorage, IStream (I think). Even though full implementations of those would be available . But most components would have custom interfaces so they would also have their own marshaling code .. If I'm 100% correct then , I guess, there wouldn't be a need for the type information. Yet it exists .. Unless the type info is used for something other than marshaling. Daniel Walker

2 1

Re: more misc fixes
by Alexandre Julliard 20 Jul '01

20 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > OK. So what you really what is exactly the opposite of what I tried to do? Yep ;-) > You want all 16-bit exported function prototypes moved from the .h > files to the implementing .c file in all cases that is is possible (ie Wine > compiles without errors or warnings)? Exactly; but note that in most cases the prototype is not even needed at all. I don't want all 16-bit C files to start with a bunch of prototypes either, this would just be unnecessary duplication; only the functions that are actually called from elsewhere in the file should be prototyped IMO. > Do you also want the types and structures moved as well? > That will often not be possible, but do you want it > despite this in the cases where it is possible? Wherever possible it would be a good thing yes. -- Alexandre Julliard julliard(a)winehq.com

3 2

UNC
by Bill Medland 20 Jul '01

20 Jul '01

Is anyone doing anything on UNC filenames? (In particular I am interested in GetFileAttributes) Bill

2 1

Re: attempting to load mIRC32 5.91 using latest wine cvs
by mdew 20 Jul '01

20 Jul '01

On Thu, 19 Jul 2001 11:05:55 +0200 Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > >>>>> "mdew" == mdew <rpbrown(a)xtra.co.nz> writes: > > mdew> mdew@storm:~$ /usr/local/bin/wine fake_windows/mIRC/mirc32.exe > mdew> FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock > mdew> FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock > mdew> err:module:BUILTIN32_dlopen failed to load .so lib for builtin > mdew> x11drv.dll: /usr/lib/libwine_tsx11.so: undefined symbol: > mdew> XF86DGAGetViewPortSize Could not load graphics driver 'x11drv' > > Either get an newer X-Server with DGA capabilities, or configure and compile > on your system. i do...in fact, i downloaded an older version of wine (20010510) which works fine... Im running Debian Sid which comes with XFree86 4.0.3 and using the Nvidia openGL drivers.. dga works in all apps i use (mplayer, quake3, MAME) just not the latest cvs of wine.

1 0

Re: COMM16: use overlapped I/O not service thread
by lawson_whitney＠juno.com 20 Jul '01

20 Jul '01

On Fri, 20 Jul 2001, Mike McCormack wrote: > > Hi, > > i've tested this patch a little... with wfw3.1 terminal, i can type AT > and receive OK from my modem, but i'm not supremely confident about > it. If somebody :-) could test it and review it a bit i'd be > grateful... > > Mike > > ChangeLog: > Replace service thread with ReadFileEx/WriteFileEx for COMM16. > > So as not to damn it with faint praise, my 16 bit app sent a response, and received 0 messages successfully. I _think_ it is OK, there shouldn't have been any messages for it to receive. Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: COMM16: use overlapped I/O not service thread
by lawson_whitney＠juno.com 20 Jul '01

20 Jul '01

On Fri, 20 Jul 2001 12:33:23 +1000 Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a multi-part message in MIME format > > ------=_NextPart_000_53222353 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > > Hi, > > i've tested this patch a little... with wfw3.1 terminal, i can type > AT > and receive OK from my modem, but i'm not supremely confident about > it. If somebody :-) could test it and review it a bit i'd be > grateful... > > Mike > > ChangeLog: > Replace service thread with ReadFileEx/WriteFileEx for COMM16. > > If you get this, my 16 bit comms app can at least send mail with your patch. It aint much, but it is a bit more than terminal.exe talking to a modem. Lawson --- Somebody, somebody has to, you see, So she picked out two somebodies, Sally and me. - T.S.G. ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

RE: more misc fixes
by Patrik Stridvall 19 Jul '01

19 Jul '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Ah. You are right, I orginally meant to add it in a > > different file (wine/obj_base16.h perhaps) but I didn't > > think it would matter since other 16 bit interface like > > IStream16 and IStorage16 is in wine/obj_*.h already. > > Perhaps they should be move out as well? > > > > If so to where? wine/obj_*16.h or perhaps the DLLs > directories if possible? > > The DLL directories definitely; and if possible in the .c file where > they are needed, to make it clear they must not be used from the > outside. Ah, yes. The implementing .c file, thats an idea. Like in dlls/lzexpand/lzexpand_main.c, I guess you mean? > > In addition (as I hinted in 5.) requiring all non-static functions > > to have a .h file declaration is good policy for any application > > including Wine. Hint, if a function isn't static somebody else > > should use it otherwise some else is wrong, ie it really should > > be static after all. > > All 16-bit API functions must be treated as if they were static. Well we could actually make them truely static with a little trickery and a corrensponding change of winebuild. Idea: #define DECLARE_ENTRY_POINT16(module, function) \ void *module##_p##function = (void *) &function /* After the includes */ static void Foo(void *, int); DECLARE_ENTRY_POINT16(BAR, Foo); /* ... */ static void Foo(void *, int) { /* ... */ } It is probably not worth the trouble though. > They > cannot be because of the spec file reference, but ideally no code > should ever call a 16-bit API, it should use the corresponding 32-bit > API. Adding prototypes and a header file is only going to encourage > using these functions which is not what we want. OK. So what you really what is exactly the opposite of what I tried to do? You want all 16-bit exported function prototypes moved from the .h files to the implementing .c file in all cases that is is possible (ie Wine compiles without errors or warnings)? Do you also want the types and structures moved as well? That will often not be possible, but do you want it despite this in the cases where it is possible?

1 0

RE: Lots of #defines OK?
by Patrik Stridvall 19 Jul '01

19 Jul '01

> Patrik Stridvall wrote: > > Not really, but as an alternative solution you could has a structure > > instead of an array like: > > > > typedef struct { > > GLYPHNAME A; > > GLYPHNAME AE; > > GLYPHNAME AEacute; > > GLYPHNAME AEsmall; > > /* ... */ > > } GLYPHNAMES; > > > > Perhaps this is better since it doesn't use the preprocessor. > > I not thought of that -- neat idea. What is the downside of using the > preprocessor, however? Well, the preprocessor "pollutes" the namespace in a way that is sometimes bad and my solution gives IMHO a slightly nicer syntax. Is this case in don't think it matters so much though, your orginal solution is fine, in fact is the standard solution in C to the problem you have AFAIK. My suggestion is really just brainstorming to give you hopefully a different perspective of the issue. Also note that your solution is not possible with languages that don't have pointer aritmetics that C, fortunately or unluckily depending on how you see it, have.

2 1

Re: more misc fixes
by Alexandre Julliard 19 Jul '01

19 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > Ah. You are right, I orginally meant to add it in a > different file (wine/obj_base16.h perhaps) but I didn't > think it would matter since other 16 bit interface like > IStream16 and IStorage16 is in wine/obj_*.h already. > Perhaps they should be move out as well? > > If so to where? wine/obj_*16.h or perhaps the DLLs directories if possible? The DLL directories definitely; and if possible in the .c file where they are needed, to make it clear they must not be used from the outside. > In addition (as I hinted in 5.) requiring all non-static functions > to have a .h file declaration is good policy for any application > including Wine. Hint, if a function isn't static somebody else > should use it otherwise some else is wrong, ie it really should > be static after all. All 16-bit API functions must be treated as if they were static. They cannot be because of the spec file reference, but ideally no code should ever call a 16-bit API, it should use the corresponding 32-bit API. Adding prototypes and a header file is only going to encourage using these functions which is not what we want. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: more misc fixes
by Patrik Stridvall 19 Jul '01

19 Jul '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Index: wine/include/wine/obj_base.h > > =================================================================== > > RCS file: /home/wine/wine/include/wine/obj_base.h,v > > retrieving revision 1.40 > > diff -u -u -r1.40 obj_base.h > > --- wine/include/wine/obj_base.h 2001/05/07 18:15:40 1.40 > > +++ wine/include/wine/obj_base.h 2001/07/19 14:50:28 > > @@ -34,6 +34,8 @@ > > #include "wtypes.h" > > #include "guiddef.h" > > > > +#include "wine/windef16.h" > > This is wrong; Win32 header files must not include 16-bit ones. Ah. You are right, I orginally meant to add it in a different file (wine/obj_base16.h perhaps) but I didn't think it would matter since other 16 bit interface like IStream16 and IStorage16 is in wine/obj_*.h already. Perhaps they should be move out as well? If so to where? wine/obj_*16.h or perhaps the DLLs directories if possible? > Also please avoid adding more 16-bit headers in include/wine, there > are already too many of them. Well that was the idea at first but at least of the new ones are was needed in more that one directory some I ended up adding all of them there. But sure I can move the ones that are not use in more of one directory to that directory, I'm just a little worried that since the wine/*16.h header are 16-bit "mirrors" of the corresponding 32-bit files that functions from other DLLs happends to end up there as well. Microsoft seems have mixed headers and DLLs without much thought especially as far as OLE is concerned. Sure we can have several .h files with the same name in different DLL directories as far as functions are concerned since 16-bit functions shouldn't call across different DLLs anyway, but duplicating types and such are not a very good idea. But sure I can examine the files more carefully and see if it is possible and of course we can add it to a DLL directory first and then move it to include/wine if is because nessary in the future. > These headers (when they are really > necessary) belong in their respective dll directory. And BTW your new > lzexpand16.h is an example of a header file that is *not* necessary. Nessary for compiling Wine no, clearly not since it already compiles. However IMO all exported functions whether they are 16-bit or 32-bit and whether they are actually uses by other files or not should have declarations in some header file. For 32-bit it must obviously be so because of Winelib. The undocumented functions is of course not strictly nessary but I see not reason not to have them as a Wine extension that can be ported to Windows eventually in order to have the same source on both Unix and Windows. For 16-bit is seems that you disagree. Well, the advantages that I can think of for doing it for 16-bit as well is the following. 1. It makes it much easier for developer to add calls across files between 16-bit functions or move functions between files if the infrastructure is alreay in place. 2. It makes it possible to see related 16-bit functions together in a .h file instead of having to search the .c files. 3. It makes it possible go through each 16-bit .h file compare it with Windows and add the missing functions in the .h files and when somebody in the future runs winapi_check (or whatever) it is possible to present a list of what is not yet implemented. Sure the .spec contains that information as well in some meaning but it misses which functions that are actually listed in the 16-bit header files and thus likely to actually be used by real applications. 4. Since some of the 16-bit exported functions must be declared in some .h since it is used in some of file than it was declared, it is be much easier to require all 16-bit export function to be declared since it is difficult to tell which that are (or will be) really needed. 5. There is nothing unreasonable to require every non-static function let alone functions that are exported by either Win16 or Win32 to have a declaration in some .h files. Indeed tools like lint (at least on Solaris) have flags to check for this. In short trying to only add the 16-bit functions that are stricly nessary to .h files is more trouble than it is worth, especially compare to the advantages that having all of them .h files. In addition (as I hinted in 5.) requiring all non-static functions to have a .h file declaration is good policy for any application including Wine. Hint, if a function isn't static somebody else should use it otherwise some else is wrong, ie it really should be static after all. But OK. You think that there are too many 16-bit files in include/wine. No problem. I will try to avoid it if at all possible.

1 0

Re: more misc fixes
by Alexandre Julliard 19 Jul '01

19 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > Index: wine/include/wine/obj_base.h > =================================================================== > RCS file: /home/wine/wine/include/wine/obj_base.h,v > retrieving revision 1.40 > diff -u -u -r1.40 obj_base.h > --- wine/include/wine/obj_base.h 2001/05/07 18:15:40 1.40 > +++ wine/include/wine/obj_base.h 2001/07/19 14:50:28 > @@ -34,6 +34,8 @@ > #include "wtypes.h" > #include "guiddef.h" > > +#include "wine/windef16.h" This is wrong; Win32 header files must not include 16-bit ones. Also please avoid adding more 16-bit headers in include/wine, there are already too many of them. These headers (when they are really necessary) belong in their respective dll directory. And BTW your new lzexpand16.h is an example of a header file that is *not* necessary. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Lots of #defines OK?
by Patrik Stridvall 19 Jul '01

19 Jul '01

> I would like to get rid of the "hardcoded" offset into the glyph name > array and replace it with a macro ('GN_exclam', for example). > Each font > data file could then simply include a header that gets > regenerated when- > ever the glyphlist is changed -- eliminating the current > requirement to > regenerate all the font data. > > Anyone see any problems with this? (There are currently 1258 built-in > glyph names.) Not really, but as an alternative solution you could has a structure instead of an array like: typedef struct { GLYPHNAME A; GLYPHNAME AE; GLYPHNAME AEacute; GLYPHNAME AEsmall; /* ... */ } GLYPHNAMES; Perhaps this is better since it doesn't use the preprocessor. However I'm not sure if all C compilers supports 1258 structure members. Another possible problem is alignment on some platforms if you must be able for iterate over it and use it as and array. Of course you can simply have a seperate array of pointers like: GLYPHNAMES glyphnames = { /* ... */ }; GLYPHNAME *pGlyphnames[] = { &glyphnames.A; &glyphnames.AE; &glyphnames.AEacute; &glyphnames.AEsmall; /* ... */ };

2 1

Lots of #defines OK?
by Ian Pilcher 19 Jul '01

19 Jul '01

I'm giving some thought to cleaning up the data structures used by the PostScript driver. Any significant change here will require that the glyph list and font data be regenerated. This is not particularly difficult, but it would be easier if I could remove the dependency of the font data on the glyph name array. Each glyph's metrics include a pointer to its name, and all of the built-in glyph names are in a single array named PSDRV_AGLGlyphNames (in dlls/wineps/data/agl.c). So the metrics for a glyph look like this: { 33, 0x0021, 600, PSDRV_AGLGlyphNames + 907, { 236, -15, 364, 572 }, NULL /* exclam */ } I would like to get rid of the "hardcoded" offset into the glyph name array and replace it with a macro ('GN_exclam', for example). Each font data file could then simply include a header that gets regenerated when- ever the glyphlist is changed -- eliminating the current requirement to regenerate all the font data. Anyone see any problems with this? (There are currently 1258 built-in glyph names.) Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

attempting to load mIRC32 5.91 using latest wine cvs
by mdew 19 Jul '01

19 Jul '01

mdew@storm:~$ /usr/local/bin/wine fake_windows/mIRC/mirc32.exe FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/lib/libwine_tsx11.so: undefined symbol: XF86DGAGetViewPortSize Could not load graphics driver 'x11drv' err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found fixme:console:SetConsoleCtrlHandler (0x546e60,1) - no error checking or testing yet FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/lib/libwine_tsx11.so: undefined symbol: XF86DGAGetViewPortSize Could not load graphics driver 'x11drv' FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/lib/libwine_tsx11.so: undefined symbol: XF86DGAGetViewPortSize Could not load graphics driver 'x11drv' err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! spews this message out many times (then quits)..., using the same wine config ..as always.. Using Debian Sid x86 (gcc-2.95.4-XFree86-4.0.3)

2 1

Re: glibc bug mmap/malloc
by Gerard Patel 19 Jul '01

19 Jul '01

At 10:15 PM 18/07/2001 +0200, you wrote: <snip about glibc> >> > This is a BUG. While this glibc question is slightly offtopic here, I think that maybe a few people on this list could be interested in glibc, since the subject comes back on a regular basis... the following web page : http://sources.redhat.com/glibc is definitely the place to go. I feel that maybe this information could help someone, since I have wasted more than one hour searching www.gnu.org for the glibc mailing list archive :-) Also http://www.suse.de/~aj/Projects.html#glibc where it's said that Andrea Jaeger is responsible for glibc bug reports. Reading the archive gives me the impression that the whole glibc is written by no more than half a dozen programmers, btw. What's more, I have also the impression that these few are not even contributing full time to glibc :-/ Gerard

1 0

Problem with 'GetPrivateProfileString'
by Lionel Ulmer 18 Jul '01

18 Jul '01

Hi all, I have an installer crashing in 'GetPrivateProfileString' because of an NULL section pointer : 3 0x40076161 (GetPrivateProfileStringA+0x31(section=0x0, entry=0x40391efc, def_val=0x4039a394, buffer=0x403b0410, len=0x3e7, filename=0x4039a4e8) [profile.c:1232] in libntdll.so) (ebp=40586748) When looking at the code, there is the following comment (and code) : /* * undoc_feature means: * return section names string list if both section and entry are NULL. */ (...) if ((undoc_feature) && (section == NULL) && (entry == NULL)) /* undocumented; both section and entry are NULL */ But if I look at the entry for 'GetPrivateProfileString' in the MSDN, I get this : pAppName [in] Pointer to a null-terminated string that specifies the name of the section containing the key name. If this parameter is NULL, the GetPrivateProfileString function copies all section names in the file to the supplied buffer. lpKeyName [in] Pointer to the null-terminated string specifying the name of the key whose associated string is to be retrieved. If this parameter is NULL, all key names in the section specified by the lpAppName parameter are copied to the buffer specified by the lpReturnedString parameter. This is not in sync. with what Wine does.... It seems that only pAppName needs to be NULL to return a section name list. And there is another behaviour not done by Wine yet : copy all the keys of a section to the output buffer. So who is the author of this 'undocumented' feature in the Wine code ? Do you all agree that I should code it according to the (now) documented feature ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 1

Re: glibc bug mmap/malloc
by Alexandre Julliard 18 Jul '01

18 Jul '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > You can clearly see that malloc() is able to squeeze up to 10232 bytes > into the memory range just before the mmap()ed area, but when it gets > slightly larger, it is NOT capable of switching to an entirely different > memory area, throws its arms up in desperation and simply returns a shabby > NULL. > It only uses a new memory area in case the values get *much* larger, > i.e. at least 131060 bytes. > > This is a BUG. > (IMHO) > What else should it be ? This is more a limitation of the malloc implementation than an actual bug. malloc uses brk() to allocate memory, but brk() cannot grow past an mmapped area, so malloc fails. With a standard Linux app shared libraries are mapped high in memory (usually from 0x40000000) so the malloc limit is about 1Gb; but if stuff is mapped lower, malloc capacity is reduced. The reason it works for mallocs larger than 128Kb is that glibc uses anonymous mmaps to reserve space for these instead of brk(). All in all, it's probably one more good reason for avoiding malloc in Wine. -- Alexandre Julliard julliard(a)winehq.com

2 1

Reaktivate
by Daniel Walker 18 Jul '01

18 Jul '01

Are the reaktivate patches going to be put in the CVS eventually? Daniel Walker

3 5

Re: use GetCommState16 to save state in OpenComm16
by lawson_whitney＠juno.com 18 Jul '01

18 Jul '01

On Wed, 18 Jul 2001, Mike McCormack wrote: > > with this patch, all use of unix fds has been eliminated from the > 16bit comm code. Next step is to remove use of the service thread... > > ChangeLog: > use GetCommState16 to save state in OpenComm16 > merge comm16 globals into one structure gcc -shared -Wl,-soname,libkernel32.so kernel32.spec.o comm.spec.o kernel.spec.o stress.spec.o system.spec.o toolhelp.spec.o windebug.spec.o win87em.spec.o wprocs.spec.o comm.o debugger.o format_msg.o kernel_main.o stress.o string.o sync.o thunk.o time.o toolhelp.o utthunk.o win87em.o windebug.o wowthunk.o utthunk.glue.o -o libkernel32.so -L../../dlls -lntdll -L../../library -lwine -lm -lutil -ldl /usr/i386-slackware-linux/bin/ld: warning: type and size of dynamic symbol `CALL32_Regs' are not defined make[2]: Leaving directory `/oof/Wine-20010629/dlls/kernel' Is this right, or are my binutils getting long in the tooth? Seems to work OK though. Lawson ---cut here--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

2 1

Re: use GetCommState16 to save state in OpenComm16
by lawson_whitney＠juno.com 18 Jul '01

18 Jul '01

On Wed, 18 Jul 2001 12:08:51 +1000 Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a multi-part message in MIME format > > ------=_NextPart_000_33334807 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > > with this patch, all use of unix fds has been eliminated from the > 16bit comm code. Next step is to remove use of the service thread... > > ChangeLog: > use GetCommState16 to save state in OpenComm16 > merge comm16 globals into one structure Okay, if you get this, it does no harm to my 16 bit comms app. Does throw a little ld warning though. Well, let's see. Lawson ---cut here--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: How to unsubscribe
by Antonio Augusto Todo Bom Neto 18 Jul '01

18 Jul '01

Begin forwarded message: Date: Wed, 18 Jul 2001 08:31:30 -0300 From: Antonio Augusto Todo Bom Neto <antonio(a)xultz.wox.org> To: wine-devel(a)winehq.com Subject: Re: How to unsubscribe On Wed, 18 Jul 2001 07:48:03 -0300 (ADT) tlegge(a)fundy.net wrote: > Hi > > How do I unsubscribe from this list? > > Regards > > Tim > > try it: http://www.winehq.com/mailman/options/wine-devel/tlegge%40fundy.net ;)

1 0

How to unsubscribe
by tlegge＠fundy.net 18 Jul '01

18 Jul '01

Hi How do I unsubscribe from this list? Regards Tim

1 0

Announcement : SynCE project
by Ludovic LANGE 18 Jul '01

18 Jul '01

Hello, First of all sorry for the intrusion, but I think this may be of interest for some of you. SynCE project's ambitious goal is to provide a mean of synchronising handhelds devices with a (desktop) computer. By handheld, we mean any portable / embedded / PDA.... device, that needs to synchronize its data with a less mobile computer. (An exemple would be any PDA/PocketPC running Windows CE, or any PDA running Linux, etc...) The first step of this project is to provide a full (client & server) implementation of Microsoft's RAPI protocol, which is the low-level protocol used in ActiveSync synchronisation. This will allow, when completed : - a Windows CE device to communicate with any (non-Microsoft) computer, - A Linux device to communicate with a Microsoft computer and benefits from the existing tools, - etc, etc... The second step will be to provide a set of tools to synchronize data with 'standard' open or closed source application : Mozilla, KMail, etc.... Right now, the project is in its early, early stages ( we don't even have an alpha release ! ), but yet there are some bits that allow an implementation of the client part of the RAPI protocol, to query informations (registry, filesystem, databases,...) from a WindowsCE device. One tool (DBBackup) allows a full dump of the databases of the device. I won't interfere more with the list, and I invite all people interested to have a look on the project page ( http://www.sourceforge.net/projetcs/synce & http://synce.sourceforge.net ) and to subscribe to the mailing-list. We currently are looking for developper, and for testers having mobile devices still under Windows CE (PDA, PocketPC, etc...) and an unix-like desktop environment. Best regards, Ludovic LANGE

2 1

how to add a new language wine?
by jerry.zhang 18 Jul '01

18 Jul '01

hello,everyone: I want to add a new language to wine,but I found the document about this is out of date, so,I want to know how to add a new language to the latest version of wine. In additional,I want to know how to define the value of many parameters in the file "/dlls/kernel/nls/youlanguage.nls". Best regards Jerry Zhang Redflag Software Co. Ltd E-mail: wenlongzhang(a)redflag-linux.com

2 1

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 July 2001