wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

RE: Winapi_check warnings
by Patrik Stridvall 29 Nov '02

29 Nov '02

> On November 29, 2002 01:53 pm, Patrik Stridvall wrote: > > Not really, you haven't run ./configure on that tree have you? > > winapi_check assumes that this is done, but I can fix it if > > it irritates you. > > Oh, I have separate src/build trees, and I was running it in > the source tree. In fact, I _have_ to run it in the source > tree, and then I get the errors... OK. I will fix winapi_check to support that.

1 0

Re: somebody help me identify this bug please
by Jeff Smith 29 Nov '02

29 Nov '02

Is it only characters with the acute accent? Is it that your are attempting this using 'dead key' entry on a Spanish keyboard? If this is the case, the problem may be in a recent correction to the Spanish keyboard layout. I will work on this some more when I get a chance, but hopefully someone else will find something sooner. -- Jeff S >From: "ezra daniel" <ezra_daniel(a)hotmail.com> > >Hello, > >At work I use Lotus Notes under Wine. > >I downloaded compiled and installed the new wine version 20021125 and I am >no longer able to type accecented valves, like á é í ó ú. > >Ñ can be typed though correctly. > >With the other version 20021031 I could type accented valves.In fact I went >back to using the older version and worked again so it is obvious it is a >problem in the new wine version. > >Though I am a newbie and know nothing of developing, but I would like to >submit the bug to the proper person so it fixes it back again but I dont >know which section of wine or person deals with this character typing >problem. > >Can anyone point me in the right direction? Thanks in advance. > >-daniel >http://www.debian-gnu.com _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

1 0

RE: Winapi_check warnings
by Patrik Stridvall 29 Nov '02

29 Nov '02

> Hi Patrik, > > I get these hundreds of warnings about "config.h": [snip] > First of all, I think they are bogus. Not really, you haven't run ./configure on that tree have you? winapi_check assumes that this is done, but I can fix it if it irritates you. > Second, if I specify the > --cross-call-win32-win16 flag, I expect to see only the problems > I am asking for, no? Shouldn't we silence all other warnings, if > we ask for something in particular? There is a --none option. winapi_check --none --cross-call-win32-win16 It doesn't always work though. Beware. However I fixed --cross-call-win32-win16 to support with my last patch, since I assumed somebody would ask. I was right it seems. Presumably you want the --progress option on as well: winapi_check --none --progress --cross-call-win32-win16

2 1

Winapi_check warnings
by Dimitrie O. Paun 29 Nov '02

29 Nov '02

Hi Patrik, I get these hundreds of warnings about "config.h": [dimi@dimi wine.src]$ tools/winapi_check/winapi_check --cross-call-win32-win16 dlls/d3d8/d3d8_private.h: #include "config.h" is not a local include dlls/ddraw/d3ddevice/main.h: #include "config.h" is not a local include dlls/ddraw/direct3d/main.h: #include "config.h" is not a local include controls/desktop.c: #include "config.h": file not found controls/desktop.c: #include "config.h" is not a local include controls/edit.c: #include "config.h": file not found controls/edit.c: #include "config.h" is not a local include controls/icontitle.c: #include "config.h": file not found controls/icontitle.c: #include "config.h" is not a local include controls/menu.c: #include "config.h": file not found controls/menu.c: #include "config.h" is not a local include dlls/advapi32/advapi.c: #include "config.h": file not found First of all, I think they are bogus. Second, if I specify the --cross-call-win32-win16 flag, I expect to see only the problems I am asking for, no? Shouldn't we silence all other warnings, if we ask for something in particular? -- Dimi.

1 0

RE: [RFC] Wine headers
by Patrik Stridvall 29 Nov '02

29 Nov '02

> Alexandre, > > Patrik brought up the header location sometime ago, in this thread: > http://www.winehq.com/hypermail/wine-devel/2002/10/index.html#540 > > At the time, I thought it is a bit premature, that we have other > things to do. Now I realize that this is one of those highly visible > external things, that would be a _lot_ better to fix before people > start using Winelib. Otherwise will piss people off when we change, > or we will not change because people are already using the headers. True. > Both versions are not good, and I think we can fix them now without > too much pain. > > Here is my proposal: > ${prefix}/include/win32 -- standard Win32 headers > ${prefix}/include/msvcrt -- MS Visual C Runtime library > ${prefix}/include/wine -- Wine specific headers > > It is simple (to understand & implement), clean, and pretty. > And I think it solved Patrik's problem (even if I can't quite > understand what the problem is from the first message :)), It not easy to mix different flavours of the Win32 headers because of include problems. The problem is that is you have since we include wine specific files like: #include "wine/debug.h" we need to have a include path like -I${prefix}/include However now since the Wine version of the standard Win32 header are in ${prefix}/include we get them included as well if we do -I${prefix}/include So if we do for example -I/opt/microsoft/windows/include we get header include collisions. Sure with GNU C on Linux (and presumably) on Windows we can fix that by specifing a correct include order. However with Microsoft C++ we can't do it in a portable way. With your suggestion above we can, so I like it. :-) > plus a bunch of other things (like making it easy to use other > headers for the Win32 API, etc). And best of all, it seems to > be easily implementable, no? "mv" is your friend however the CVS versioning doesn't like it though...

2 1

wglCreateLayerContext?
by Mike Hearn 29 Nov '02

29 Nov '02

Hi, This OpenGL method is currently a stub, looking at the MSDN documentation I can't see why this is the case given the fairly complete GL implementation Wine has. Is it that we cannot handle layering properly in X or something? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 4

somebody help me identify this bug please
by ezra daniel 29 Nov '02

29 Nov '02

Hello, At work I use Lotus Notes under Wine. I downloaded compiled and installed the new wine version 20021125 and I am no longer able to type accecented valves, like á é í ó ú. Ñ can be typed though correctly. With the other version 20021031 I could type accented valves.In fact I went back to using the older version and worked again so it is obvious it is a problem in the new wine version. Though I am a newbie and know nothing of developing, but I would like to submit the bug to the proper person so it fixes it back again but I dont know which section of wine or person deals with this character typing problem. Can anyone point me in the right direction? Thanks in advance. -daniel http://www.debian-gnu.com _________________________________________________________________ MSN. Más Útil Cada Día http://www.msn.es/intmap/

1 0

Re: final int21 move
by Jukka Heinonen 29 Nov '02

29 Nov '02

This patch series starts to look more like what it should be. Previous bugs seem to have been fixed and dependencies between winedos and other dlls have been reduced close to minimum. However, I still find some things that I don't particularly like: - The series is actually one big patch divided into multiple files and not a series of incremental changes. The first patch in series breaks DOS3Call and error reporting of some functions and these are only fixed in later patches. - Old int21 functions contain some obvious bugs that really should be fixed at the same time the code is migrated to winedos. - Move to winedos should not only migrate code but it should also try to rewrite code so that it has better comments, it is more readable and it uses simpler constructs. This patch series really messes up already complicated code. Intendations are irregular and weird. Many newlines are missing. Some internal functions use INT21_ prefixes and some don't. Functions that were implemented as separate helper functions are moved inside int21 main switch case. Three nested levels of switches are used without even proper indentation. And that comment about shooting people is tasteless and really doesn't belong to Wine. I just don't find the quality of this patch acceptable. I don't decide these things but my personal opinion is that I would rather rewrite this patch series than see it accepted in its current state. I wouldn't mind if Nog or someone else works on int21 migration (that's why I haven't posted int21 patches already) but I don't see why I ought to lower my quality requirements due to this fact. -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: cabinet.dll broken?
by Tapio Kautto 29 Nov '02

29 Nov '02

Could cabinet be set to: "cabinet" = "native,builtin" automatically by wineinstall as long as it does not work the way expected? Tapio On Thursday 28 November 2002 12:59, Patrik Stridvall wrote: > > I'm trying to install MS Office 2000 on wine-20021125. > > > > I get an error from Office installer: > > > > Internal error 2352. Please contact Product support. > > > > I found an advice to repair my cabinet.dll in Microsoft Support pages. > > > > The file is in ~/c/windows/system, and it's readable. Does > > anyone else have > > problem with this? > > Well. It might be that since very recently, Wine has builtin > stub implementation of cabinet.dll. > > Of course it shouldn't be used automatically if have a cabinet.dll, > since I guess most people (including you) have a: > > [DllOverrides] > ; default for all other dlls > "*" = "native, builtin, so" > > entry in their config file. > > You can force cabinet to native with > wine --dll cabinet=n > though.

1 0

Doc Build, Diablo II Regression Test, and TreeView Patch Test Updates
by Dustin Navea 29 Nov '02

29 Nov '02

Vincent, Alexandre, and Dimi Grrr, Im really starting to not like Linux's PPPoE support... I have tried every version of pppd and pppoe that is available besides CVS (and thats because I cant get online in Linux to get it) in order to get my DSL workin in Linux and I am giving up until I can afford to get a DSL Router (hopefully next week). So until then, I will be unable to do any regression testing on Diablo II and will be unable to test out any of the most recent patches to verify that they fix problems with my setup... so until next Wednesday I will probably just lurk on the lists -Dustin

2 2

SIGSEGV in IDirectDrawImpl_EnumDisplayModes
by Matthew Bloch 29 Nov '02

29 Nov '02

Apologies for needing some more hand-holding: from Alexander's advice I now have the game linking and beginning to execute. It now gets stuck while executing this piece of C++: --------------------------------------------------------------------------- void tDirectDrawScreen::destroy() { DDSURFACEDESC ddsd; memset(&ddsd,0,sizeof(DDSURFACEDESC)); ddsd.dwSize = sizeof(DDSURFACEDESC); ddsd.dwFlags = DDSD_CAPS; ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; HRESULT hr = mp_directDraw->CreateSurface(&ddsd, &mp_primarySurface, NULL); // crashes here ... } --------------------------------------------------------------------------- This being the segfault that occurs: --------------------------------------------------------------------------- #0 0x40c92c4c in ?? () #1 0x40f56f5f in User_DirectDraw_EnumDisplayModes (iface=0x403acc00, dwFlags=1086925740, pDDSD=0x808c678, context=0x40c92be8, callback=0x40f55dfc <EnumDisplayModesCallbackThunk>) at ddraw/user.c:373 #2 0x40f55e81 in IDirectDrawImpl_EnumDisplayModes (This=0x40c92be8, dwFlags=1086925900, pDDSD=0x808c678, context=0x40c92a94, cb=0x40c92a94) at ddraw/thunks.c:348 #3 0x4080f9b2 in tDirectDrawScreen::setUpWindowedSurfaces (this=0x808c668) at Source/tDirectDrawScreen.cpp:852 #4 0x4080cf1f in tDirectDrawScreen::initialise (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:88 #5 0x4080caac in tDirectDrawScreen::tDirectDrawScreen (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:55 #6 0x4082d76f in InitApp (hInst=0x40620000, nCmdShow=1) at Source/Main.cpp:289 #7 0x4082d8fc in WinMain (hInst=0x40620000, hPrevInst=0x0, lpCmdLine=0x403708ad "", nCmdShow=1) at Source/Main.cpp:322 #8 0x4062509c in __wine_exe_main () from /home/mattbee/Work/Nemesis/LSNClient.exe #9 0x400b3799 in start_process () at ../../scheduler/process.c:564 #10 0x400b76c9 in call_on_thread_stack (func=0x400b3558) at ../../scheduler/sysdeps.c:112 --------------------------------------------------------------------------- Any ideas why this might be happening? -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

9 22

Re: Last one for today :-)
by Vincent Béron 28 Nov '02

28 Nov '02

Le jeu 28/11/2002 à 17:24, Lionel Ulmer a écrit : > re-reHi... > > This patch implements the 'GetRenderTarget' method for the IDirect3DDevice > COM object. It is independant from all previously submitted patches (but to > prevent 'fudging', it is better to commit after the GetDirect3D AddRef fix). > > With this series of patch, the Boids demo from the DX6 SDK is now running > (it's not working because we are lacking some D3D code, but at least it does > not crash :-) ). > > Changelog: > - implement GetRenderTarget A bit too much work on your part I bet, as you forgot to attach the patch ;-) Vincent

1 0

wine & preempt patch (fwd)
by Matthias Rieber 28 Nov '02

28 Nov '02

Hi, is there are known issue with the preempt patch for the kernel? When I apply that patch, non-open-gl games doesn't run smooth, without the patch they run nearly smooth (especially StarCraft & BaldursGate). OpenGL games are alway fine. matthias

1 0

How to debug wineserver
by Rajesh Akkineni 28 Nov '02

28 Nov '02

hi, is there any way we can debug the wineserver? thanks Rajesh __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

3 2

Modifying registers
by Fabian Cenedese 28 Nov '02

28 Nov '02

Hi Is there already a possibility to view/set the actual program counter in winedbg? I couldn't find anything in the manual. And it's not possible to work with EIP. This would be useful e.g. to jump over some unwanted code or call a function a second time. Generally, is there a way to modify registers? Must be obvious but I'm blind. Thanks bye Fabi

3 3

Chronic crash on Photoshop
by Robert North 28 Nov '02

28 Nov '02

Can someone look at the bug I raised about Photoshop crashing wine, (and potentially the whole of X11 and Linux) http://bugs.winehq.com/show_bug.cgi?id=1165 It's probably the most extreme bug I've seen on Linux ever. I wasn't sure if this was the appropriate place to post this request, so feel free to correct me. Cheers -Rob.

1 0

compiling wine under cygwin - status
by David Fraser 28 Nov '02

28 Nov '02

Hi all This is a brief indicator on what parts of wine compile successfully under cygwin and what give errors. Almost all the source code compiles successfully, but lots of things have linking problems. Note that I haven't yet tested the resulting parts that did link successfully. The significant compilation problem is in server/context_i386.c: You must implement get/set_thread_context for your platform. Basically there's some code that does the threading stuff which is platform-specific. There are Linux and BSD and Sun variants, none of which work under cygwin ... Basically sys/ptrace.h is what's missing. This lets the process interrupt a child process and get/set its registers. Does anyone have any idea what the best way to write a replacement for cygwin would be? Maybe I need to ask the cygwin list. My plan is to go through each one that doesn't link, look at all the errors, and categorize them (many are the same problem spread accross various dlls), so that we can tackle the more widespread problems first... Any help with this appreciated :-) David dlls/ advapi32 has errors avicap32 has errors avifil32 has errors cabinet has errors comcat links comctl32 links commdlg has errors crtdll has errors crypt32 links d3d8 has errors dciman32 links ddraw has errors devenum links dinput links dinput8 links dplay links dplayx links dsound has errors gdi has errors glu32 links icmp links imagehlp links imm32 links kernel has errors lzexpand has errors mapi32 links mpr links msacm has errors msdmo links msimg32 links msisys has errors msnet32 links msvcrt has errors msvcrt20 has errors msvideo has errors netapi32 links ntdll has errors odbc32 links ole32 has errors oleaut32 has errors olecli has errors oledlg links olepro32 links olesvr has errors opengl32 has errors psapi has errors qcap links quartz links rasapi32 links richedit has errors rpcrt4 links serialui links setupapi has errors shdocvw links shell32 has errors shfolder links shlwapi links snmpapi links sti links tapi32 links ttydrv has errors twain has errors url links urlmon has errors user has errors version has errors win32s has errors winaspi has errors winedos has errors wineps has errors wininet has errors winmm has errors winnls has errors winsock has errors winspool has errors wintrust links wow32 links wsock32 links x11drv has errors library/ libwine.dll links successfully miscemu/ requires ntdll.dll ole/ libwine_uuid.a links successfully programs/ avitools/aviinfo.exe links avitools/aviplay.exe links clock/clock.exe links cmdlgtst/cmdlgtst.exe links control/control.exe links expand/expand.exe links osversioncheck/osversioncheck.exe links progman/progman.exe links regapi.exe/regapi.exe links regsvr32/regsvr32.exe links regtest/regtest.exe links uninstaller/uninstaller.exe links view/view.exe links wcmd/wcmd.exe links winefile/winefile.exe links winemine/winemine.exe links winepath/winepath.exe links winhelp/winhelp.exe links winhelp/hlp2sgml.exe links winver/winver.exe links winhelp.exe links server/ context_i386.c has compile error (You must implement get/set_thread_context for your platform) tools/ bin2res.exe links fnt2bdf.exe links makedep.exe links widl/widl.exe links winebuild/winebuild.exe links winedump/winedump.exe links wmc/wmc.exe links wpp/libwpp.a links wrc/wrc.exe links unicode/ libwine_unicode.dll links libwine_unicode.a links

2 3

RE: Missing SignalObjectAndWait
by Sean Mitchell 28 Nov '02

28 Nov '02

> I think that the first problem is that if foo.exe.so links with > libpthread.so, then libpthread.so gets loaded and initialized before > ntdll.dll.so is loaded and overrides the pthread functions in the C > library -> big trouble. > > This migh conceivable be worked around using a wrapper like I > described > for libmfc.so except this time the wrapper would just load libntdll.so > and the wrapped executable would link with libpthread.so. > > Then I guess it should work since threaded opengl libraries > are supposed > to work. > > But is there really an advantage to using pthread rather than > the Win32 > threading functions when porting a Windows application? After all one > should not have to change the code when porting with Winelib... Without SignalObjectAndWait() I imagine that many medium sized to large apps would have to consider alternative threading libraries... the app I'm trying to port uses it quite a bit to prevent race conditions. As an interested party rather than a developer I'd suggest that the effort would be best spent implementing SignalObjectAndWait() before worrying about pthread compatibility, but I don't know the extent of the work involved. For my own porting project I'm now considering at a "clean" port without any Windows calls - fortunately we only use the thread calls and some file system calls from the Win32 API - but I suspect that this might present a roadblock to other projects hoping for a painless port. In any case, you folks have done a great job with Wine and winelib, and I thank you for it. Cheers, Sean

1 0

Access Database
by Fabian Cenedese 28 Nov '02

28 Nov '02

Hi My app works with an Access mdb. Opening and reading goes fine. The problem comes with writing. There is a table called "Nodes". I delete it and then create a new one to fill in my data. For some strange reason the table gets created but with a name "Node", the s was munched. Even more strange that it works with other tables after this one. I already stepped through the MFC.dll and checked critical places (strlen, SysAllocString etc) but it always looked fine. Did anyone ever had something similar? Or can work with mdbs without problems? Thanks bye Fabi

1 0

SystemTimeToTzSpecificLocalTime()
by Martin Fuchs 28 Nov '02

28 Nov '02

Hello, what has happend with my patch for SystemTimeToTzSpecificLocalTime() and TzSpecificLocalTimeToSystemTime()? It has not been commited yet, and I didn't see any comments on it. Are there any problems with it? -- Martin Fuchs martin-fuchs(a)gmx.net

1 0

RE: Missing SignalObjectAndWait
by Sean Mitchell 28 Nov '02

28 Nov '02

> Sent a patch to wine-patches for this one and the _set_error_mode() > constants. With the patch applied your application should > compile fine. > > However note that _set_error_mode() and SignalObjectAndWait() are both > stubs currently, which means that functionality is not implemented. So > if your application calls either of them it will crash... Ah... gotcha. I may just port the thread object to pthreads and be done with anyway. Thanks. Sean

3 4

What about the MONITORINFOEX fix?
by Dimitrie O. Paun 28 Nov '02

28 Nov '02

Alexandre, What happened with this patch by Patrik: http://www.winehq.com/hypermail/wine-patches/2002/11/0241.html I still have an ugly hack in my tree, and I was curious what you have in mind for that? -- Dimi.

2 2

Doc building update, finally
by Dustin Navea 28 Nov '02

28 Nov '02

Vincent, I finally got SGMLtools installed and went to build the doc. Only problem is that instead of it outputting to files it prints the output on screen. Is there a flag that I may be missing or what? I'm using SGMLTools pre-compiled and built.. Downloaded from ftp://ftp.slackware.com/pub/slackware/slackware-current/extra/sgml-tools-1.… and installed using pkgtool which comes with slackware.. -Dustin P.S. Any outputs you need say from man or --help on docbook2html?

4 4

Re: A few trivial Unicode-Ascii fixes
by Dmitry Timoshkov 28 Nov '02

28 Nov '02

"Matthew Davison" <m.davison(a)virgin.net> wrote: > changelog: > A few Trivial Unicode-Ascii cross-call fixes Actually, since our loader code is not using unicode internally at all and therefore your "fixes" just add superfluous conversions from ANSI to Unicode and back, I think that real fix would be to convert loader to unicode first and only then clean things up. -- Dmitry.

1 0

Re: Again Warcraft 3 - Wine CVS 20021125
by Sylvain Petreolle 28 Nov '02

28 Nov '02

I say to you it isn't the case. :) > Do not hate me, please. > > After download of CVS snapshot I compiled it from a dir in my home > (/home/leo/wine). There is winedefault.reg, but I do not understand > if wine > reads it or the user.reg and system.reg in my .wine/ dir The emulation of registry is based on .wine/system.reg =>HKEY_LOCAL_MACHINE and user.reg => HKEY_CURRENT_USER. At the very start of wine these 2 files are empty/nonexistent => the registry is empty. To initiate it, you must import values into it via the program regedit. Default values that works well are in winedefault.reg. When you issue 'regedit winedefault.reg', this file is read and its values are imported into system.reg and user.reg. Now your debugger problem : you have installed a previous version some months ago and wine architecture changed. winedbg isn't at the same place as before. You have the old value in system.reg so wine doesn't find it anymore. running 'regedit winedefault.reg' will update your old values with new ones and set the correct location for the debugger. (and many others) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

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