At 03:42 AM 22/05/2001 +0200, you wrote:
>In attachement WIN.3_11 you can see listing generated under windows 3.11.
>( Borland WinSight ) (If you want get a listing generated under win98/95 - no
>problem , but I'll have to format&reinstall ,because this copy of windows
>stopped functioning about 6 months ago )
>WINE_SETWINPOS ,WINE_NCALC- under wine with first and second version of
>patch.
>I think WINE_NCALC is more similar to WIN.3_11 .
There is nothing looking like a SetWindowPos call between
WM_INITMENU and WM_INITPOPUPMENU, yes.
But as Alexandre Julliard was pointing, it does not mean
that something like calling NC_HandleNCCalcSize is done.
>I'm wondering why menu->Height == 0. I'll investigate it.
height = 0 because at some point the menu has been changed; this
is a Wine flag to signal that the menu dimensions have to be calculated again.
The problem with my test app without my original patch is that the menu
sizes are not calculated at this point so the mouse clicks are ignored
Btw, I have downloaded several of the availables app on your web site
and I don't see anything wrong with menus; IIRC I have tried 7.5 for
Win3.11, and trial versions 8 and 9 (32 bits). Is it with the main menu
that you see this problem ?
Gerard
Fran=E7ois Gouget <fgouget(a)codeweavers.com> writes:
> I noticed that OPTIONS is not used anymore in 'configure.in'. I
> believe it may have been used to store the --enable-* stuff at one ti=
me
> but AFAIU this is now stored in 'config.h'. So I propose to remove it
> altogether. Or is it set as a side effect of some standard autoconf
> macro on some exotic system?
It's here so that you can specify extra flags that configure doesn't
know about, by doing OPTIONS=3D-Dfoo ./configure. This can be useful in
some cases.
--=20
Alexandre Julliard
julliard(a)winehq.com
Ian Pilcher <ian.pilcher(a)home.com> writes:
> I decided to put all of the data into dlls/wineps/agl.c, since changing
> the glyph list data without regenerating the font metrics data would
> cause things to break in extremely bizarre ways. (Well, it will once I
> actually use the glyph names.)
You should really split it into separate files, a 40,000 lines file is
a bit too much. Also all this data must be constant and in a read-only
section, it's eating 400k of data space right now.
I'm guessing that you have a script to generate all this; could you
please consider submitting it? This way other people can make changes
too.
--
Alexandre Julliard
julliard(a)winehq.com
That's the same kernel problem that plagues Lotus Notes (If I've understood
correctly the message in German ;-)
Lotus Notes will die with the same problem if you use a SuSE 7.0 with SuSE
kernel 2.2.18 (Mandrake kernels have the same problem, according to other people
here)
If you compile the kernel yourself starting from ftp.kernel.org's sources, all
is well (at least for Notes).
I didn't try SuSE Kernels 2.2.19 / 2.4.2 however.
Ciao,
Roberto.
"Marcus Meissner" <marcus(a)jet.franken.de> wrote:
> + /* This might be a DOS device we do not handle yet ... */
> + FIXME("(%) not detected as DOS device!\n",devname);
^^^
Seems a typo to me.
Hi,
I have some strange errors with wine the last few weeks. Everytime I try to
start an application (mainly Ultima Online and Baldur's Gate) wine crashes
(stops) with this errors:
>wine client.exe
For language 'german' several language ids were found:
de_DE - 0407; de_CH - 0807; de_LU - 1007; de_LI - 1407;
Instead of using first in the list, suggest to define
your LANG environment variable like this: LANG=de_DE
Protocol error:0x8071580: read : Die Ressource ist zur Zeit nicht verfügbar
fixme:dsound:IDirectSoundImpl_SetCooperativeLevel
(0x403938fc,00000138,3):stub
fixme:pthread_kill_other_threads_np
For language 'german' several language ids were found:
de_DE - 0407; de_CH - 0807; de_LU - 1007; de_LI - 1407;
Instead of using first in the list, suggest to define
your LANG environment variable like this: LANG=de_DE
Protocol error:0x8067660: read : Die Ressource ist zur Zeit nicht verfügbar
Beendet
Protocol error:0x8075258: read : Die Ressource ist zur Zeit nicht verfügbar
I don't know what the problem is. My first thought was that I have problems
with my sound drivers (Alsa 0.5.11) , so I tried the kernel emu10k1 driver
and after that I loaded no sound module. All with the same result. The only
other thing I did with my linux installation was upgrading to a 2.2.18
kernel.
My system specs:
Latest wine cvs
SuSE Linux 7.0
All updates from Suse.com (new glibc 2.1.3)
Kernel 2.2.18 (SMP)
Alsa 0.5.11
KDE 2.1.1
Xfree86 4.0.3 (Ximera on)
Dual PIII 500Mhz
384 MB Ram
Adaptec AIC-7880 Ultra SCSI host adapter
Matrox G400 Max Dualhead
SoundBlaster Live! Value
Regards
-Josef Wegner
Francois Gouget <fgouget(a)free.fr> writes:
> So according to the dll separation rules we must not make msvcrt
> depend on an API not exported by a regular windows dll. But in the case
> of ntdll I'm not sure. Can we use native ntdll in Wine? I don't think so
> since it also exports things like 'wine_dbgstr_[aw]n?'. So maybe we can
> bend the rules a little and export _vsnwprintf anyway.
A better solution would be to put the *wprintf functions inside
libwine_unicode.
--
Alexandre Julliard
julliard(a)winehq.com
I was just perusing through msvcrt and noticed that in wcs.c there is
an implementation of _vsnwprintf, which also exists, verbatim, in it's
entirety, in ntdll/wcstring.c. Unless I am misunderstanding the .spec
files there appears to be a method of "forward"ing a symbol to an
external implementation, such as:
@ forward -noimport wcslen ntdll.wcslen
Is there any particular reason this was not done for _vsnwprintf as well?
There is even a comment in the wcs.c copy saying to mirror any fixes in
the ntdll copy.
Also, on perhaps a style note, I've noticed some implementations are
prefixed by the dll name in all caps, such as MSVCRT_vfprintf, and some
are not, such as _wmkdir. Is this just personal style or is there more
to these differences?
--
TTFN
MikeB
with today's CVS commit (for those who stay up to date with
the latest developments), you'll have to modify your Wine
configuration to reflect the changes.
First of all, your Wine configuration file now needs a WinMM section
containing the following:
[WinMM]
"Drivers" = "wineoss.drv"
"WaveMapper" = "msacm.drv"
"MidiMapper" = "midimap.drv"
Not adding this will print the following message
> You didn't setup properly the config file for the Wine multimedia modules.
> Will use the hard-coded setup, but this will disapear soon.
> Please add a WinMM section to your Wine config file.
Note that the above configuration will be shortly required, so don't
wait before setting your configuration up
Next, you have also to add a key to your registry. To do so,
create a sample file (let's call it foo) containing the following text:
[HKEY_LOCAL_USER\Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap]
989041554
"AutoScheme"=dword:00000000
"CurrentInstrument"="#0"
"UseScheme"=dword:00000000
then goto the <wine>/programs/regapi and compile the program
the run:
regapi setValue < foo
that's it
Not applying the key in the registry will result in various errors in
MIDIMAP_ functions (mainly if Wine is set up to use a native
Windows system)
Maintainers are welcome to update theirs packages accordingly (default
values are in documentation/samples/config & winedefault.reg)
Detailed information is available in documentation/multimedia.sgml.
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
eric pouech <eric.pouech(a)wanadoo.fr> writes:
> First of all, your Wine configuration file now needs a WinMM section
> containing the following:
> [WinMM]
> "Drivers" = "wineoss.drv"
> "WaveMapper" = "msacm.drv"
> "MidiMapper" = "midimap.drv"
>
> Not adding this will print the following message
> > You didn't setup properly the config file for the Wine multimedia modules.
> > Will use the hard-coded setup, but this will disapear soon.
> > Please add a WinMM section to your Wine config file.
> Note that the above configuration will be shortly required, so don't
> wait before setting your configuration up
Please keep the defaults. There is no reason to force people to update
their configuration file when there are workable defaults that we can
use.
Ideally Wine should behave reasonably even with an empty configuration
file; this is not entirely possible because things like paths don't
have reasonable defaults, but forcing people to specify things that we
could guess is not user-friendly.
--
Alexandre Julliard
julliard(a)winehq.com
