wine-devel October 2001

wine-devel@winehq.org

71 participants
173 discussions

InstallShield 6 - success
by Ove Kaaven 24 Oct '01

24 Oct '01

Apart from the two patches I just submitted to wine-patches, a stdole32.tlb from real Windows, and the registry entries in winedefault.reg, you need my interprocess com hacks, which I've now put on WineHQ: http://www.winehq.com/~ovek/install.diff The installation progress bar doesn't seem to display for some reason (might be a repaint issue or something else related to Alexandre's latest work, or something completely different, don't know), but anyway, even if it doesn't tell you its progress, … [View More]

6 5

Re: wine/memory virtual.c
by Ove Kaaven 24 Oct '01

24 Oct '01

On Tue, 23 Oct 2001, Alexandre Julliard wrote: > Modified files: > memory : virtual.c > > Log message: > Try to use read instead of mmap for files on removable media, so that > we don't need to keep the mapping handle open. OK, I see that you did this part too, which I hadn't submitted yet... but there's still one thing missing; the .exe file is still open inside the wineserver, still having two outstanding references: - main_exe_file in scheduler/process.c - … [View More]

1 0

Latest in the homeworld/wineoss saga.
by Simon Britnell 24 Oct '01

24 Oct '01

I've attacked homeworld for a couple of hours with IDA free and none of the places that set the value of the NULL pointer are remotely close to a waveOutWrite call. I've run -debugmsg +wave with and without the synchronous wodWrite patch. The results are fairly large so I won't send them unless you feel they're particularly useful. To summarise: Both have 2 wodOpen calls. Both produce "Oooch buffer underrun" messages. The synchronous wodWrite version does only one wodWrite and a large … [View More]

2 2

Lindows
by Uwe Bonnes 24 Oct '01

24 Oct '01

Hallo, does anybody know more about "Lindows" than the sparse information they annouce on their webpage and the press releases? I don't think they reimplemented the win32 api, so I guess they use wine code. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

datacache bug
by giorgian 24 Oct '01

24 Oct '01

hi all, as i wrote few days ago, there's a problem with the DataCache_GetAdvise function in dlls/ole32/datacache.c: the call (this->sinkInterface)->lpVtbl->QueryInterface(this->sinkInterface, &IID_IAdviseSink, (void**)ppAdvSink); crashes since this->sinkInterface is NULL. executing the program with the --… [View More]

1 0

Re: PATCH: revert version change
by Francois Gouget 24 Oct '01

24 Oct '01

On Tue, 23 Oct 2001, Marcus Meissner wrote: > Hi, > > There was following change to misc/version.c: > revision 1.44 > date: 2001/07/27 23:57:38; author: julliard; state: Exp; lines: +1 -1 > Bob Goodwin <goodie1(a)pacbell.net> > Fix the 16bit win95 version. > > This makes for instance InstallShield, that uses DOS3CALLs to check for win95, > report a Bad Windows Version. (Installer of Monkey Island 3) > > Reference wine-devel post … [View More]is: > http://www.winehq.com/hypermail/wine-devel/2001/07/0085.html > > If there is a testprogram, I can still boot Windows 95... Ladislav Sladecek <lsla(a)post.cz> posted a program to check the 16bit version back in august: http://www.winehq.com/hypermail/wine-devel/2001/08/0275.html I think the revert is the right thing to do. And this is what I get on the Win95 computers I have access to. I also recently found that quite a few installers are not happy with 0x0304. I attached Ladislav's 16bit test application and also attached a application I wrote that dumps what the 32bit GetVersion and GetVersionEx return. Bob, how did you come up with 0x07000304? Was it from the Daggerfall application or from a windows computer? If the latter, then could you run the attached tests and report what the results? Here are the result of the tests I have done here: * Win95 (the original version): It does indeed return 0x5f03 in 16bit mode. The CSDVersion does not seem to match in 32bit mode: GetVersion: version = 0xc0000004 GetVersionInfoEx: size = 148 major = 4 minor = 0 build = 0x40003b6 platform = VER_PLATFORM_WIN32_WINDOWS CSDVersion= "" vs. "Win95" in Wine I don't know if this could cause problems. * Win98SE: Returns 0x5f03 in 16bit mode, like Wine. No problem in 16bit mode. In 32bit mode I get some discrepencies, probably because this is SE and not the original 98: GetVersion: version = 0xc0000a04 GetVersionInfoEx: size = 148 major = 4 minor = 10 build = 0x40a08ae vs. 0x40A07CE in Wine platform = VER_PLATFORM_WIN32_WINDOWS CSDVersion= " A " vs. "Win98" in Wine * NT4: Everything is fine. Tonight I hope to get results for Win2000 and WinXP. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service [View Less]

1 1

Re: usleep in winmm/wineoss audio
by Simon Britnell 24 Oct '01

24 Oct '01

--- eric pouech <eric.pouech(a)wanadoo.fr> wrote: > after, rereading my old code, there's nothing wrong > (at first glance) here some invocations (like close, > reset) need to be synchronous > (the calling thread blocks until the rendering > thread is done with the message), some others (like > adding a wavehdr for play back) > are asynchronous, hence the difference I added a WaitForSingleObject late last PM as an experiment. The results were ... interesting. The … [View More]

3 8

Re: Shlwapi functions _29, _30, _31
by Alexandre Julliard 24 Oct '01

24 Oct '01

"Guy L. Albertelli" <galberte(a)neo.lrun.com> writes: > I assume that the differences may be due to revisions of the Unicode > standard, but that is an assumption only. Yes, there are some differences between our Unicode tables and the Windows ones. It shouldn't really matter, and if it does it's easy to fix. The important thing is to make sure everything uses the tables in libwine_unicode so that there is only one place to fix if necessary. -- Alexandre Julliard julliard(a)winehq.com

1 0

Shlwapi functions _29, _30, _31
by Guy L. Albertelli 24 Oct '01

24 Oct '01

Alexandre, Thank you for simplifing these functions when you committed them. I thought you might want to know that they do act slightly differently from the versions in the native shlwapi.dll (version 5.50.4807.2300): _29 (iswspace) - extra TRUE for 0x1680, 0x202f _30 (iswblank) - missing TRUE for 0x3000 _31 (iswpunct) - missing TRUE for 0x00aa, 0x00b5, 0x00bb, 0x0192, 0x05ba - extra TRUE for 0x02df, 0x02ea-0x02ee, 0x0346-0x034e, 0x0361, 0x0488-0x0489, 0x058a, … [View More]

1 0

Re: The big winsock patch
by Alexandre Julliard 23 Oct '01

23 Oct '01

Francois Gouget <fgouget(a)free.fr> writes: > Make winsock.h and winsock2.h independent from the Unix headers > Make them compatible with both the Unix C headers and the MSVCRT > headers > Ensure compatibility with the Unix headers via the USE_WS_PREFIX macro > Add WINE_NOWINSOCK: prevents winsock.h from being included > from windows.h when defined > Add ws2tcpip.h, move definitions to the right header I don't like the WS_API preprocessor abuse. It … [View More]

1 0

← Newer
1
2
3
4
5
6
7
8
...
18
Older →

Jump to page:

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