wine-devel

wine-devel@winehq.org

84463 discussions

Why would Installshield want WINSPOOL.DRV
by David.Goodenough＠DGA.co.uk 24 Oct '02

24 Oct '02

I was asked by my son to install a couple of games for him on his Linux laptop. Wine is installed (at the current Debian unstable level) but when I try to run the installer, which says it is InstallShield, it gets to 99% and stops, and the console says that it can not load WINSPOOL.DRV. Firstly I can think of no good reason for InstallShield to want this (can anyone else, as far as I know this game - Star Trek Elite Force - does not have a print facility), and secondly what do you think is my best route fix the problem. There are some Windows machines (98/ME/NT4) in the house, I am using Win 98 mode in Wine, which machine should I copy WINSPOOL.DRV from if it will help? Thanks in advance David

3 2

Third listview status update
by Dimitrie O. Paun 24 Oct '02

24 Oct '02

Folks, With my latest W-series patches, the listview should now be a pleasure to work with: fast, *no* flicker, etc. It should be a lot better than before I started working on it. If this is not the case (there are regressions, there is nasty flicker *anywhere*, it's slow, or in general it's not a pleasure to interact with it, i.e. you don't get a warm and fuzzy feeling) let me know now. Internally, the code is a lot cleaner. I have started on Sep. 9, 2002, at revision 1.138. A month and a half, and almost 150 revisions later, most of the code has changed multiple times. Large number of visible, and mostly invisible bugs have been fixed, a lot of corner cases covered, features implemented, listview has been made scalable, flicker has been eliminated by redrawing the absolute minimum, etc. We are now on solid ground to implement more stuff. This has been an extenuating exercise. I am tired, and on top of it all, real life has knocked on my door. This does not mean I'll stop working on it, but it probably means that I will not be able to put as much time into it. For the above mentioned reasons, I think it's best for everybody if we stabilize the code as much as possible, before we start working on the large number of missing features. For this I need your help -- the few apps that I test with work just fine now. I would like to thank everybody that helped me with testing, patches, or reporting bugs. I couldn't have done the half of it without that support. This sounds like this is a done deal. It's not. There's a lot of stuff that remains to be done, but I needed some closure. :) -- Dimi.

2 10

Impressive success
by John K. Hohm 23 Oct '02

23 Oct '02

I just got an ATAPI Plextor PlexWriter 40/12/40A (which rocks), and Plextor's Win32-only firmware updater worked flawlessly in wine, a few months old CVS. Kudos to all involved in supporting that sort of access!

2 1

Re: wine not detecting CUPS printers
by Dan Fer 23 Oct '02

23 Oct '02

>From: "Dan Fer" <ezra_daniel(a)hotmail.com> >To: wine-devel(a)winehq.com >Subject: wine not detecting wine printers >Date: Wed, 23 Oct 2002 16:32:09 +0200 > > > > >Has anyone tried using cups under Wine in any of the latest builds? > >I tried to builds from this month and none detect any printer. > >Is there a patch? Anything I could use to fix it? > > > > > > >_________________________________________________________________ >MSN. Más Útil Cada Día http://www.msn.es/intmap/ _________________________________________________________________ Charla con tus amigos en línea mediante MSN Messenger: http://messenger.microsoft.com/es

1 0

Re: French resources
by Vincent Béron 23 Oct '02

23 Oct '02

Le mer 23/10/2002 à 16:09, Vincent Béron a écrit : > This brings some French resources up-to-date with the English ones. > There are 3 resources not yet done: dlls/avifil32/avifil32_Fr.rc, > dlls/comctl32/comctl_Fr.rc and programs/winefile/Fr.rc. > > Plus it corrects a small typo in Shell32_En.rc. > > License: X11 and LGPL, as usual > > Changelog > Bring some French resources in sync with English ones. > > Vincent > ---- > Alexandre, Forget the programs/progman/Fr.rc from this patch. The one you just commited is better. But the rest of the patch is meant to be applied. Do you want me to resend a new one without that file? Vincent

1 0

Re: Re: [linux-audio-dev] Fwd: Opinions on running VST or DirectX plugins
by chrismorgan＠rcn.com 23 Oct '02

23 Oct '02

Just so people don't think the code has fallen off of the face of the planet ;-) Currently I'm working on two things with the wine jack driver , one of which needs to be complete before I submit the patch, the other can wait until some ongoing jack support is complete. 1. The driver currently closes and opens jack connections synchronously with wodOpen and wodClose. The problem is that jack doesn't actually close the clients right away, sometimes it can take many seconds for this to occur. Apparently this is a known jack bug but I'm also wondering if this is a problem in wines pthread implementation of conditions(there is no support for them right now). Either way I've implemented a workaround that basically consists of opening jack connections and marking them as in-use or available as apps open or close audio devices. This behavior can be enabled/disabled via a define in the driver. This isn't complete yet but it should be soon and would prevent the lockups and delays that currently make things a pain. 2. I don't know of an easy way to do resampling so the input audio matches the sample rate that jack expects. What I want is to be able to do something along the lines of: set_sample_rates(input_rate, jack_output_rate); set_resample_algorithm(x); /* pick a reasonable algorithm based on the current cpu and latency requirements */ And then in the callback routine something like: resample(audio_data_in, *audio_data_out); I haven't found anything even close to this simple as of yet, if anyone has any suggestions feel free to mail me about them. There is someone on the jack mailing list working on a resampling library that is supposed to be easy to use and flexable. Either way, this isn't critical although your music sounds funny if your sample rates don't line up very well ;-) Otherwise I'm also looking into a crash with using the jack driver and directsound that might be due to the client process and memory allocation. After working on the arts driver I realized that the future of audio servers really is callback based. It is quite frustrating to see so little use of jack and so much use of poor solutions like direct hardware drivers(alsa/oss) or high latency servers like artsd. No offense intended to people that work on or use either of those audio solutions, it just doesn't make sense when you want to have multiple apps outputting audio at the same time or if you need low latency(high end audio, games?, etc). I'll see what I can do to get things cleaned up and a patch submitted in the next week, conditional of course upon Alexandre accepting jack support into wine. At least now I have someone other than myself with an interest in using jack and wine together ;-) Thanks, Chris > > From: "Kjetil S. Matheussen" <k.s.matheussen(a)notam02.no> > Date: 2002/10/23 Wed PM 12:18:13 EDT > To: linux-audio-dev(a)music.columbia.edu > CC: wine-devel(a)winehq.com > Subject: Re: [linux-audio-dev] Fwd: Opinions on running VST or DirectX plugins > on Linux in real time > > > > On Wed, 23 Oct 2002, Taybin Rutkin wrote: > > > On Wed, 23 Oct 2002, Kjetil S. Matheussen wrote: > > > > > Could it be possible to overcome all problems mentioned just by simply > > > adding jack-support to the wine-server? Then someone could make a simple > > > windows-program for chaining directx and vst plug-ins. > > > > Someone has done this, I believe: > > http://kt.zork.net/wine/wn20021011_139.html#2 > > > Wow, it allready exist. Hey, wine-people, this driver is really needed for > real-time audio-work, and for programs as sound-editors, multitrackers > and interactive dsp programs as pd, jmax, and a lot of others. Artsd > (f.ex) is not an alternative in its current form, and probably never will > be either. Its something else. I guess Paul or some other competant person > can explain a bit more why jack is so important. > > > -- > > > > >

2 1

Re: using native regedit
by Jeff Smith 23 Oct '02

23 Oct '02

I did some testing and found that *\\whatever.exe does not work, while *whatever.exe does. In case anyone thinks to themselves, "but that could cause problems for xwhatever.exe!", I tested further and found that it only affects programs with the name whatever.exe and not those such as xwhatever.exe. -- Jeff S. >We could add this to show different behaviours : > >; you can specify applications too >; This one will apply for all notepad.exe >;"*\\notepad.exe" = "native, builtin" >; This one will apply only for a particular file >;"C:\\regedit.exe" = "native, builtin" > >Is everyone ok ? _________________________________________________________________ Get faster connections -- switch to MSN Internet Access! http://resourcecenter.msn.com/access/plans/default.asp

3 2

Fixing OLE_GetFormatW
by Medland, Bill 23 Oct '02

23 Oct '02

I am just about to fix OLE_GetFormatW. (As far as I can see it can't have worked since rev 1.1). Before correcting the minor error I want to check something. Can anyone with access to NT answer this for me? If you pass a format string to GetDateFormatW that contains time-formatting characters I presume it just throws them away. Similarly if you pass a format string to GetTimeFormatW that contains date-formatting characters I presume it throws them away. Bill

1 0

fairly old wine regression: no$gmb no longer works
by Jonathan Gevaryahu 23 Oct '02

23 Oct '02

In wine builds from early? last year until January 29th, 2002, no$gmb (Nocash gameboy emulator) worked reasonably in wine (yes it would crash if you did 'animate trace' for too long, but that's a seperate issue). the commit which broke it was to wine/dlls/comctl32/status.c, on January 29th at 11:54 am. However, the fix that was done to status.c seems to be valid (later fixes to status.c do the same as what the fix did, I believe), so I suspect that the bug stems from some other issue which causes it to need the incorrect behavior in status.c in order to work. (personally I think it was something done during January that makes it need the incorrect status.c behavior, but I'm probably wrong) The nocash website is http://www.work.de/nocash/ or http://nocash.work.de/ Jonathan Gevaryahu

2 2

Bug tracked down in mci.c
by Erland Lewin 23 Oct '02

23 Oct '02

Hello, I just got the latest wine from cvs, and it crashed when I tried to run Half Life. The problem turned out to be in mci.c, in the mciSendStringA function. The variable lpCmd is set to point into the (in my case mciavi) driver's command table, at the word "open". However, towards the end of the mciSendStringA function, there is the following code: if (strcmp(verb, "open") == 0) { if ((dwRet = MCI_FinishOpen(wmd, (LPMCI_OPEN_PARMSA)data, dwFlags))) MCI_UnLoadMciDriver(iData, wmd); /* FIXME: notification is not properly shared across two opens */ } else { dwRet = MCI_SendCommand(wmd->wDeviceID, MCI_GetMessage(lpCmd), dwFlags, (DWORD)data, TRUE); } TRACE("=> 1/ %lx (%s)\n", dwRet, lpstrRet); dwRet = MCI_HandleReturnValues(iData, dwRet, wmd, lpCmd, data, lpstrRet, uRetLen); The problem is that MCI_UnLoadMciDriver is called, which causes the driver to be removed from memory, which means that lpCmd points to invalid memory. When MCI_HandleReturnValues then tries to use its lpCmd parameter, a segmentation fault will occur, becuase it tries to read from unmapped memory. I did a quick hack to work around the problem (lpCmd = strdup( lpCmd )) before the MCI_FinishOpen. I'd appreciate it if someone else could add a better permanent fix... Thanks for the good work on Wine!

2 1

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