July 2003 - Wine-devel - list.winehq.org

Re: Sync(20): ntdll/tests/rtlstr.c
by Alexandre Julliard 20 Jul '03

20 Jul '03

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > +/* Define the undocumented types we need here as there is no native header */ > +typedef struct _STRING { > + USHORT Length; > + USHORT MaximumLength; > + PCHAR Buffer; > +} STRING, *PSTRING; > +typedef const STRING *PCANSI_STRING; Actually there is a native winternl.h that defines these. You may need to upgrade your headers. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: just a suggestion (richedit.dll)
by Jonathan Wilson 20 Jul '03

20 Jul '03

Tom wrote: > Hello, > > You could look into riched20.dll and riched32.dll > as wine is in need of these in a bad way :) Unfortunatly, I have never programmed richedit stuff. But, if someone can provide 4 things, I might actually give it a go: 1.an existing control or library that can do the actual rendering of the text (with the colors, fonts, bold and so on) 2.an example program that shows the usage of RichEdit (something that has source code) and that will work just fine using MS richedit.dll under Wine that I can use as a test subject (something that uses straight C code and calls richedit directly, i.e. doesnt use libraries like MFC) 3.documentation on the programming interface of this dll. Having a working clone header and library file (perhaps the one from MingW32 if the licence of that file is ok) would be ideal as it would give me a place to start. and 4.details on anything I am not allowed to do to the MS dll in the corse of making this new one (I know copying stuff is forbidden because its a copyright violation but am I allowed to for example disassemble richedit.dll or step through it in a debugger to get a better idea of how it works or is that considered too legally risky?)

3 3

WINE programs question...
by Jonathan Wilson 20 Jul '03

20 Jul '03

Some of the WINE programs (for example, notepad) use resources for languages that arent present in the MingW headers, the Windows SDK or the visual C++ 6 header files (like LANG_WALON). Where did these definitions come from? Does windows actually use these definitions somehow? (Given that WINE is supposed to be a clone of the windows API, defining and using things that windows itself doesnt provide doesnt make sense) IANACWD (I Am Not A Core Wine Developer) but I would think that being able to compile the standard Wine programs and some of the non-core dlls under MingW with w32api would be a usefull test. Being able to replace e.g. comctl32.dll from MS with the wine version and seeing what breaks would be a good way to track down bugs (IMHO) Same for Wine programs (like notepad), being able to build & use em on win32 would help with bug tracking. (i.e. is this bug in WINE or in the app)

3 2

something I could work on, can someone tell me if this is something usefull or not?
by Jonathan Wilson 20 Jul '03

20 Jul '03

I could take the WINE implementation of notepad.exe (which is clearly a "clone" of an older version of notepad, probobly from Windows 98 or ME or 2000 or something) and add to it so it does the same things or similar things as the windows XP notepad. Some of the differences between XP notepad and Wine notepad: the file size limit is gone (because microsoft re-wrote the edit control to not have a size limit I guess) the "page setup" and "print setup" dialogs are combined into one dialog now with new code to handle that. A few slight differences between the UI of both (for example the Cut and Copy items are disabled if there is nothing selected, something wine notepad doesnt do) Wrap Ling Lines (in Wine notepad) is moved to a new Format menu in Windows XP notepad and is called Word Wrap. Also, the Font menu item is moved for the Format menu. Find and Find Next are moved to the Edit menu and renamed from Search and Search Next. Also, a Replace option and a Go To option (goes to a specific line) have been added. And, the Save and Save As dialogs have an "encoding" selection box that lets you select And, the print function has a "now printing" dialog. Also (obviously), the help system is better in Windows XP notepad. Basicly, I plan to implement some of these things (but I wont do the help system since thats something I know nothing about) to make wine notepad more like windows XP notepad (in particular, adding the Replace and Go To features) I am taking this on because I want to improve my skills at working with the Win32 API. Basicly, I want to know: 1.is this something usefull to the Wine project? and 2.is there anything I should avoid doing for whatever reason? (for example, are there things I cant do because they would violate MS IP or something)

4 3

RE: Web: Fix the WWN intros
by Brian Vincent (C) 19 Jul '03

19 Jul '03

> So why do we still say (the Un*x Windows emulator). ? If it's > *not* a emulator ? The only reason I ever left that in there is because that's the way Eric had it. (And he can always just blame it on being a native .fr speaker.) Maybe I'll change it this week to something more appropriate. I've always hated saying something like "an implementation of the Win32 API for Un*x", it sounds too technical. Emulator, while wrong in a technical sense, does get the point across. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

3 2

DirectSound problems
by Mike Hearn 19 Jul '03

19 Jul '03

Hi, Just trying out EV Nova (a game), I get lots and lots of errors like this: err:dsound:DSOUND_MixOne underrun on sound buffer 0x5579a110 fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=15872 < primary_done=21168) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=15872 < primary_done=17640) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=15872 < primary_done=17640) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=15872 < primary_done=21168) err:dsound:DSOUND_MixOne underrun on sound buffer 0x5579a110 and the soundy is choppy, drops out and is distorted. Yes, I am forcing HEL emulation. What sort of thing causes these errors? Any idea what I can do to fix it? thanks -mike

1 0

Re: just a suggestion (richedit.dll)
by Robert Shearman 19 Jul '03

19 Jul '03

> > You could look into riched20.dll and riched32.dll > > as wine is in need of these in a bad way :) I submitted a patch to enhance the functionality of richedit a while ago, although it wasn't accepted (probably because I hadn't finished it). I have abandoned it for the moment so feel free to continue with the work. If richedit doesn't appeal to you, maybe you could implement a few Var* functions in oleaut32. These are particularly important to VB users, and can be tested very easily since the functions have no side effects. Rob

1 0

2 questions about the WINE multi-line edit control
by Jonathan Wilson 19 Jul '03

19 Jul '03

1.does it handle UNICODE yet? and 2.is there any limit to the size of the data that can be stored in one?

1 0

Re: Locales with the same language
by Dmitry Timoshkov 19 Jul '03

19 Jul '03

"Marcelo Duarte" <wine-devel(a)bol.com.br> wrote: > If I understanded, people that have LANG=fr_CA or pt_PT, etc (non-default > SUBLANG), will have to use English? If there are no resources with SUBLANGE_DEFAULT, then yes. > Then the correct will be change all resources with SUBLANGE_DEFAULT to > SUBLANG_NEUTRAL until someone localize them? > I can modify this if is the correct. Actually there was a completely opposite patch committed recently: 2003-01-05 Shachar Shemesh <winecode(a)sun.consumer.org.il> Change the SUBLANG_NEUTRAL clause in all winelib applications to SUBLANG_DEFAULT, as they should be. I vote to revert that patch. -- Dmitry.

3 10

Re: Sync (32): winbuild msvcrt
by Alexandre Julliard 19 Jul '03

19 Jul '03

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > - Functions exported by name only should not be given ordinal numbers > in the .def output, so that link.exe can fill up empy ordinal slots > and create a valid export table. Not doing this leads to an incorrect > export table without any warnings or errors during the build. We use the ordinal to generate the proper hint in the import table, so this is not a good idea. > - We need the stub functions to be present in the final dll file, or > our ordinal functions cannot be accessed. This is because link.exe > requires that all ordinals be present in order to generate a correct > ordinal export table. > This in turn requires that the .spec.c files compile correctly under > msvc, in order to get the stub functions included in the link. > However, we obviously don't need the pe header or export tables that > winebuild generates, since link.exe (and any other PE linker, for > that matter) does this work for us. The .spec.c file must not be used on Windows IMO. If the MS linker is really that brain damaged then you'll need to make sure you have valid functions for all entry points, or use a better linker (mingw should work AFAIK). > - Several symbols are expected to be exported as private and by name > only, or they generate warnings when creating the .lib and .exp files > for the dll. This requires identifying said symbols, and correctly > generating and parsing the PRIVATE flag in .def files. I'd suggest specifying that in the spec file instead of hard-coding the symbols in winebuild. Also please try to split your patch, there are clearly different changes in there, it would be a lot easier to analyze them independently. -- Alexandre Julliard julliard(a)winehq.com

1 0