wine-devel

wine-devel@winehq.org

2 participants
84470 discussions

Re: readme update
by Andreas Mohr 18 Jan '04

18 Jan '04

Hi, On Sun, Jan 18, 2004 at 08:44:19PM +0100, Ivan Leo Murray-Smith wrote: > This patch improves the italian version fo the README file, and uniforms it > layout to the one of the English README. It also updates the links to the faq, > the forums and the cvs to the urls currently used at winehq in all versions of > README. Alexandre, I think it would be a good idea to move these files to the root > source directory, so that non-English speakers can spot them immediately. It may > also be a good idea to rename them something more obvious, for example from > README.it to LEGGIMI.italiano (README.italian), shall I send in a patch that > does this? And then we do the same for French, Russian, German, Spanish, Chinese, Polish, Bavarian ;-), Portuguese, Norvegian, Danish, Raeto Romanian, Kiswahili? Don't think so ;-) I'd say as the very first part in the README file, we write something like *********************************************************** Foreign languages (language, langue, Sprache, lingua, ...): ---> open documentation/README.<country_domain> *********************************************************** Sounds better than polluting the Wine root directory with many different localized versions. (also, if people still haven't learned to look at a file called "README" first, then they're not supposed to use Wine anyway) I still think that someone should put a system in place to make sure that all localized content gets kept current properly. (otherwise we might just end up deleting more modern versions of installation-und-konfiguration.german again and again...) That file once was a beautiful piece of documentation... and then it died... horribly even. ;-) Anyway, thanks for your docu maintenance! Andreas Mohr

1 0

Re: I'm off to Cuba!
by Brian Vincent 18 Jan '04

18 Jan '04

> I hope it's going to be sweet, but I'll be off the web > until next Sunday. Until then, hasta la vista amigos! :) Excelente! Just in time to bring us souvenirs at Wineconf. -brian

2 1

Re: Regression tests and Paul Millars WRT
by Paul Millar 18 Jan '04

18 Jan '04

On Sat, 17 Jan 2004, Mike Hearn wrote: > On Sat, 17 Jan 2004 18:40:01 +0000, Paul Millar wrote: > >> 3) Is the source to WRT available anywhere? [...] > > http://www.astro.gla.ac.uk/users/paulm/Code/wrt-0.1.tar.gz > Cool, thanks! :) No problem. Of course, any feedback/bug-fixes would be appreciated :) BTW, I should have pointed out that wrt-0.1 isn't what the live version is using. I'm still testing v0.1 before switching over. > Good to know you're tracking these things anyway, though I don't recall > seeing you forward a build failure in a year of me hacking on Wine so I > guess failed tests don't get through these days.... >From April through to October last year it wasn't working: http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php?start=400 Some server juggling broke the (even more hacky) way the old code worked. At the same time, things at work got a bit hairy, taking up nearly all my time. Eventually got it up again... ---- Paul Millar

1 0

Re: bin2res - Make adding resources work on Windows.
by Dmitry Timoshkov 18 Jan '04

18 Jan '04

"Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > I dont know if anyone else has tried this but when I try to add > resources to a *.rc I get a error. This patch fixes it. What kind of error do you get? I just tried to change an .rc and to rebuild resources of commdlg under cygwin and I don't see any problem with it. -- Dmitry.

2 2

Re: ntdll / kernel32 #39-2
by Dmitry Timoshkov 18 Jan '04

18 Jan '04

"Eric Pouech" <pouech-eric(a)wanadoo.fr> wrote: > +DWORD WINAPI GetFullPathNameW( LPCWSTR name, DWORD len, LPWSTR buffer, > + LPWSTR *lastpart ) > +{ > + LPWSTR dst = HeapAlloc(GetProcessHeap(), 0, len * sizeof(buffer)); > + DWORD ret; > + > + if (!dst) return 0; > + ret = RtlGetFullPathName_U(name, len * sizeof(WCHAR), dst, lastpart) / sizeof(WCHAR); I don't quite understand the above bit of code: 1. HeapAlloc(GetProcessHeap(), 0, len * sizeof(buffer)) when buffer is a pointer 2. Why you don't pass buffer directly to RtlGetFullPathName_U without allocating an intermediate storage. -- Dmitry.

2 1

Alsa 1.0 patch for audio.c
by Brett I. Holcomb 18 Jan '04

18 Jan '04

In November Sylvain Petreolle posted a patch to audio.c to make it work with the new Alsa 1.0 version. What is the license on that patch? I ask because I'd like to pass it on to the winex-devel list so they can include it. Is it possible to send it on? If not that's fine - I want to check first. Thanks.

2 1

Debugger doc pages
by Jason Edmeades 18 Jan '04

18 Jan '04

Is it something about my machine but when I go to the online debugger docs, eg: http://www.winehq.com/site/docs/wine-devel/wine-debugger I can see absolutely nothing in the text boxes. I can highlight the text and it appears to be in a minute font, and cut+paste into an editor shows me the text is there, its just too small to be visible. I tried with mozilla and IE (both from a Windows machine). Jason

4 3

Re: Need help debugging ...
by Jason Edmeades 18 Jan '04

18 Jan '04

Hope you dont mind, I was bored and its a small download (DK1). The disassembly of the failure shows we have written to eax, and info regs shows eax of 0x00. dis 0x4e4a20 shows the routine where the return value is set up in eax, and some debugging shows the initial problem is a path problem. The routine parses the input path which inder windows is c:\path\to\KEEPER95.exe and under wine is KEEPER95. It searches backwards for the last backslash and returns a pointer to the backslash or 0x00. If 0x00, the trap occurs... Now the question is where does the full path come from. Jason

8 16

Re: Add iccvid.spec to winapi_check
by Hans Leidekker 18 Jan '04

18 Jan '04

On Thursday 15 January 2004 16:07, Vincent Béron wrote: > Changelog: > Yet another new spec file added to winapi_check/modules.dat, this time > iccvid.spec. After DLL separation is complete, adding these will no longer be necessary, right? -Hans

3 4

I'm off to Cuba!
by Dimitrie O. Paun 18 Jan '04

18 Jan '04

Si señor, I'm off for a week to Varadero, Cuba! Given the terrible temperatures we had here lately (-39C with the windchill), I am happy beyond words to bask in the sun for a week. I hope it's going to be sweet, but I'll be off the web until next Sunday. Until then, hasta la vista amigos! :) -- Dimi.

1 0

Re: PATCH: tools/winewrapper and memory limits
by Marcus Meissner 18 Jan '04

18 Jan '04

On Sun, Jan 18, 2004 at 02:11:22AM +0100, Gerald Pfeifer wrote: > This would have saved me a _lot_ of time late last year. With a > memory limit set too low, I would simply get an Abort, both when > running Wine itself and `ldd wine-binary`. :-( > > This is not really FreeBSD-specific, for Marcus Meissner encountered the > problem on SUSE Linux as well; feel free to remove the first condition! This does not really help, since winewrapper is only used for in-source-tree startup. Once installed, 'wine' is no longer this shellscript, but an ELF binary. Ciao, Marcus

2 1

Re: Need help debugging ... Ddraw issue
by Jason Edmeades 17 Jan '04

17 Jan '04

Wow, lots of updates, and rather than reply to each let me try to summarize. >> The one thing I couldnt answer is how the game 'gets' the command line. >int WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ); Perhaps this way? No, I noticed the difference between the exe hdrs, (console vs gui) and I ran some tests on this, and the value in lpCmdLine seemed to be just the parms and not the "command line" / executable name. Thats why I then went on to try GetCommandLine and spotted that issue. Nice idea though, thanks >Ok, that here is exactly the problem (dlls/kernel/environ.c), it's explained in the remark of the func: >GetCommandLineA (KERNEL32.@) >* * WARNING: there's a Windows incompatibility lurking here ! >* Win32s always includes the full path of the program file, >* whereas Windows NT only returns the full file path plus arguments >* in case the program has been started with a full path. >* Win9x seems to have inherited NT behaviour. I read that as saying Win32s just provides the path and probably exe name and Winnt provides the full path, exe and parms. You may be correct, I didnt investigate this further. >> With some experimentation with a GUI pgm I think I stumbled upon the / >> an answer: > Bug#1 - GetCommandLine() returns a full path on Windows but no path on Wine Doh. >Well this should definately be fixed anyway (with a regression test), and it does sound a lot like the problem doesn't it? >I expect we use this API (or similar) to set the parameters to WinMain Yes, but I didnt see any evidence it was being called. I may have missed it.. However I think this is also a red herring... > * Note that both Start Menu Execute and Explorer start programs with > * fully specified quoted app file paths, which is why probably the only case > * where you'll see single file names is in case of direct launch > * via CreateProcess or WinExec. This may be the real issue - I was running it from within msdev.exe which works, but launching it from the command line does trap the same way. "Windbg keeper95.exe" traps on run, but windbg, ctrl+e (open exe) doesnt, and I think thats because the file dialog returns fully qualified paths (at a guess). >I wonder if when a program is invoked directly from the wine loader app we should pretend >it's been run from Explorer and pass it the full path. Alexandre, would that be an acceptable >solution (subject to more thorough testing of course). I'd be worried this may cause more problems than it solves. This is an interesting one in that wine *does* correctly emulate windows behaviour, but the app is broken to only expect a full path. Aside from an app specific option (perhaps we could add in app specific config options into a central compatibility ini file), I think the only way to capture this is to document in eg. the appDB. >"Some debugging" is a bit vague but I'll let you off that ;) I guess I just need to get better at reading disassemblies. It certainly helps as I frequently drop down to assembler when things get confusing (my 'real' job involves lots of debugging!). I wish I was better with eg. gdb syntax as I really am mostly a Windows person so far (Boo Hiss...)! Jason

3 2

Re: winecfg: a patch to review
by Ivan Leo Murray-Smith 17 Jan '04

17 Jan '04

> Windows actually does have a few settings like this (Well, XP does) Windows server 2003 and longhorn have the same functionality, and blackcomb probably has it too. Ivan.

1 0

winecfg: a patch to review
by Kirk Ruff 17 Jan '04

17 Jan '04

Hello, I have started to work on winecfg a little in attempt to get used to some workings of WINE. This is the first real open source project I have actually tried to submit a patch to. I have started to work on a few functions that were not implemented yet and before I forget to try to submit a patch again I thought I would do it now. The only part I have included in this patch is the ability to remove an application from the "Application" tab. The way I assumed that this was to do is remove the appropriate key from the registry and update the listview. I realize this is a pitiful patch since it really doesn't add much but I thought I would see if I am doing it correctly and to see if does what it should. Any help is appreciated(I hope this patch is inline, my first try at it. Kirk

7 14

Re: GetShortPathName broken
by Stefan Leichter 17 Jan '04

17 Jan '04

Am Samstag, 17. Januar 2004 22:31 schrieb Eric Pouech: > > Thanks Eric, > > > > this was the right tip. My Problem is that i have two directories. The > > first one is "C:\Program Files" but the second one is C:\Programme. After > > i renamed (first character) the second one the test program works for me > > too. So what changed is the behavoir if two directories will match the > > short path. > > So, this shouldn't impact GetShortPathName. The short name should be > unique (as the long path). So, your test should work even with your two > directories. Something is wrong somewhere. > > This patch should help ? > Yes, thanks it works fine here Thanks Stefan

1 0

Re: Try using the Mozilla Active X control in MSHTML
by Dimitrie O. Paun 17 Jan '04

17 Jan '04

On January 16, 2004 01:06 am, Mike McCormack wrote: > Since some people have been complaining that MSHTML is a useless > distraction in it's current form (there's some element of truth in > that), here's a small patch to redirect calls to Mozilla's Active X > control. You need to add a "mshtml"="builtin,native" override in the > config file and download and install the control before this patch can > try to use it: > > http://www.iol.ie/~locka/mozilla/control.htm Very nice Mike! I guess this requires a Win32 build of Mozilla, no? Anyway, if the patch goes in, it would be nice if our good packagers can come up with a binary package (say, wine-mozilla?) that just installs alongside with the wine package and provides this capability. -- Dimi.

4 4

Running Wine under MS SFU under Wine ... ?
by Dan Kegel 17 Jan '04

17 Jan '04

I recently posted with problems running Microsoft's Services for Unix under Wine. I only tried it out of morbid curiosity, actually, and because MS was offering it for free. The free offer expired, but it's back again for a little while; slashdot.org seems to be running banner ads for it. I'd encourage any of you who even *might* be tempted to try this out to go order the CD-ROM. It would be way bitchin' cool if we could nest Wine and MS SFU (I seem to recall we can't nest Wine in Cygwin for some technical reason, but who knows, maybe SFU won't have the same problem). - Dan

3 3

GetShortPathName broken
by Stefan Leichter 17 Jan '04

17 Jan '04

Hello, The function GetShortPathName is broken in current cvs. This short program exhibits the problem: ------------------------------------ #include <stdio.h> #include <windows.h> #include <version.h> int main(int argc,char **argv[]) { char buffer[0x104] =""; DWORD retval; retval = GetShortPathName("C:\\Program Files", buffer, sizeof(buffer)); printf("%08x, %08x, %s\n", retval, GetLastError(), buffer ); return(0); } ----------------------------------------- On win2k and wine "2004-01-14 CST" i get 0000000b as retval and 00000000 from GetLastError() starting with wine "2004-01-14 18:21:00 CST" up to current cvs i get 00000000 for retavl and 00000002 from GetLastError(). So for my understanding the patch http://cvs.winehq.com/patch.py?id=10682 broke the function. Bye Stefan

2 2

Re: Debugger doc pages
by Jason Edmeades 17 Jan '04

17 Jan '04

>> Is it something about my machine but when I go to the online debugger >> docs, eg: http://www.winehq.com/site/docs/wine-devel/wine-debugger I can >> see absolutely nothing in the text boxes. I can highlight the text and >> it appears to be in a minute font, and cut+paste into an editor shows me >> the text is there, its just too small to be visible. >> I tried with mozilla and IE (both from a Windows machine). >WORKSFORME with Firebird 0.7 on Fedora... and >It looks fine for me in Konqy, under Linux (RH9). >Is the font setup on that machine odd in any way? Not that I know of! Its a relatively new (<2months) old WinXP install, but its something weird as my other machine (win2k partition) can see them fine. If it was 'just' IE or just Mozilla, I wouldnt mind, but for both to be broken does make it look like a machine wide issue. Debugging this further, the style sheet has as font for <pre> 'Fixed'. I changed this to PRE { FONT-SIZE: 10pt; FONT-FAMILY: Courier, Fixed } and it works, so it implies my 10pt Fixed family font is wrong? On my 2k(working) box, I ran character map, and in the font dropdown I had Fixedsys but not fixed. On my XP box I actually had listed an entry for 'fixed', which sure enough had small fonts. Any idea how to get from charmap -> font? I dir a dir *fixed* /s on my machine, no luck. Anyone else with XP who could try that page and see if they suffer the same way please? Jason

1 0

Problem with configure/config.cache
by Dominik Strasser 17 Jan '04

17 Jan '04

Hi, I am running into a problem, each time I rerun tools/wineinstall: wineinstall calls configure; configure finds a valid config.cache. On detction of the aRTS sound server it does the following: if test "${ac_cv_c_artsserver+set}" = set; then echo $ECHO_N "(cached) $ECHO_C" >&6 else # check for aRTS ... so if configure is called repeatedly, the else clause is not executed. But only in this else clause, ARTSC_CFLAGS and ARTSC_LIBS are set, which results in an uncompilable wine alsa driver because ARTSLIBS and ARTSINCL is set to those vars. Something similar happens in the detection of the asm keywords to be used in the stabs generation. I am not an autoconf guru, so I have no clue how to fix this. Regards Dominik

2 1

Re: Partial MDI rewrite
by Alexandre Julliard 17 Jan '04

17 Jan '04

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Merge the MDI and common window creation code. Change a way > MDI children are managed in MDIClient. > Add support for MDICREATESTRUCT A<->W conversions. > Add support for WM_MDIREFRESHMENU. The critical section thing worries me, especially since you are doing things that may require sending messages in there. I think you should use the normal USER lock when locking is really necessary; note that anything that is only accessed from the window procedure doesn't need locking at all. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Implement LockWindowUpdate [take 3]
by Alexandre Julliard 17 Jan '04

17 Jan '04

Mike Hearn <mike(a)theoretic.com> writes: > I hit Google and found a page describing how to reduce flickering in > FrontPage by writing a utility VB app using LockWindowUpdate and > FindWindow, so clearly my initial implementation was wrong and this does > need server support. The resultant code is also cleaner I feel. Yes it's much better. Now the problem is that the rest of the code won't be able to cope with it: in order to make sure painting always happens correctly, you will need to invalidate all the DCEs concerned by the window, to make sure all the update regions are recomputed correctly. Unfortunately this can't be done inter-process at the moment... -- Alexandre Julliard julliard(a)winehq.com

3 6

Regression tests and Paul Millars WRT
by Mike Hearn 17 Jan '04

17 Jan '04

So, I saw in WWN mention of this website which I stumbled across by accident a few weeks ago, and had another look. I couldn't believe how useful it was, yet nobody seemed to use it and it's not a part of WineHQ. A few questions, therefore: 1) Firstly, to Paul - could you hook things up so that when we get new red/purple builds an email is sent to wine-devel? I just sent a patch to fix the http tests that started failing but I wouldn't have seen it if it was not for your system. I think Alexandre runs the test suite before checking in each patch, but it's still possible that there are ones he misses (like this). If it was being done automatically perhaps AJ would not need to run the whole test suite before each commit, so he could work faster as well (and alexandre-cycles are waaaaay more valuable than cpu-cycles :) 2) Why is this not running on a WineHQ machine? Too expensive? Not needed? 3) Is the source to WRT available anywhere? thanks -mike

2 1

A question about winehq options
by Kirk Ruff 17 Jan '04

17 Jan '04

I am trying to work on a multimedia tab, unless someone else is doing this already. I am wondering what options should go on this tab. A select for the audio driver, wave mapper, and midi mapper is what I was thinking so far. The wave/midi mapper seem to each only have 1 option so what should I do for that? Is there any plan to add any more options to these two? The dsound options seem too obscure to be in winecfg, and I didn't see any other obvious options to put on. Hopefully someone else hasn't started on such a tab yet. Any help is appreciated.

3 3

Re: Need help debugging ... Ddraw issue
by Jason Edmeades 17 Jan '04

17 Jan '04

>I was following your posts here in real time and you almost found solutions faster than I could try them out, LOL! To be honest these things come down to luck sometimes, depending on what direction you start debugging! I was very lucky with this one - I ran them side by side on 2 machines, one under windows and one under wine, put breakpoints at the point of failure and worked backwards comparing the two. >I can confirm that the screen switches and a picture shows up when using full win-path and the mouse acts weird. >Haven't tried commenting out anything yet. Weird. Mine trapped as soon as the splash screen was removed, so I had to do that commenting before I could get to the main menu. >I'm trying to investigate that GetCommandLine thing. The one thing I couldnt answer is how the game 'gets' the command line. It doesnt (didnt!) appear to use any API to do it, although I didnt spend long looking into this. I hit it in wine when i tried to think of what possible ways you could get to the command line and tested some of them. This would probably need some more work to find out exactly how this game does it (I doubt it accesses the PEB directly). As to the mouse problem, I dont know - I've had other games where the mouse behaviour is weird and jumpy, but never quite like that. Does turning on (or off) dxgrab make a difference? (Not booted into Linux just now). Does DK2 suffer from the same thing, or is there another problem? Jason

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