wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: edit: no not use LOCAL_*() functions
by Alexandre Julliard 16 May '05

16 May '05

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > @@ -426,19 +425,21 @@ static LRESULT WINAPI EditWndProc_common > { > EDITSTATE *es = (EDITSTATE *)GetWindowLongW( hwnd, 0 ); > LRESULT result = 0; > + STACK16FRAME *stack16; > + HANDLE16 oldDS; > > TRACE("hwnd=%p msg=%x (%s) wparam=%x lparam=%lx\n", hwnd, msg, SPY_GetMsgName(msg, hwnd), wParam, lParam); > > if (!es && msg != WM_NCCREATE) > return DefWindowProcT(hwnd, msg, wParam, lParam, unicode); > - else if (msg == WM_NCCREATE) > - return EDIT_WM_NCCreate(hwnd, (LPCREATESTRUCTW)lParam, unicode); > - else if (msg == WM_DESTROY) > - return EDIT_WM_Destroy(es); > > + if (es && (msg != WM_DESTROY)) EDIT_LockBuffer(es); > + > + /* Make sure DS points to hInstance for 16-bit apps */ > + stack16 = (STACK16FRAME*)MapSL((SEGPTR)NtCurrentTeb()->WOW32Reserved); > + oldDS = stack16->ds; > + stack16->ds = GetWindowLongPtrW( hwnd, GWLP_HINSTANCE ); It seems dangerous to set DS for the whole window procedure, it will be calling a lot of other functions that may end up depending on DS. It's especially dangerous here since the window instance won't be a valid DS for 32-bit windows. I think you really want to set it only around the Local* calls and restore it as soon as possible. -- Alexandre Julliard julliard(a)winehq.org

2 1

Unknown stab type in crashes
by James Hawkins 16 May '05

16 May '05

Hey, Whenever wine crashes, I get a long stream of err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e Does everyone else get that too? Does anyone have info on this? It's understandable to output an unknown type, but it does make the backtrace pretty much useless. After a couple parts of the bt, the error message files a couple hundred lines, then another couple lines of the bt, so I can't see the whole bt at once. Sometimes parts of the bt are scrolled up past my history limit. I don't mean to complain, but it is hampering debugging a bit. -- James Hawkins

4 6

Re: comctl32: Move TrackMouse handling to MouseMove
by Alexandre Julliard 16 May '05

16 May '05

James Hawkins <truiken(a)gmail.com> writes: > This patch also fixes the WM_LBUTTONUP bug, and the new behavior with > listview is even better. The logic behind this is that we only want > to track the mouse by calling TrackMouse when the mouse moves. What you really want is to only start tracking if it moves by more than a certain amount, which is what LISTVIEW_TrackMouse already tries to do in a very inefficient way. So you should probably move all the logic from LISTVIEW_TrackMouse to the MouseMove handler. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: test-and-dereference: a common problem?
by Alexandre Julliard 16 May '05

16 May '05

Paul Millar <paul(a)astro.gla.ac.uk> writes: > Anyway, I noticed that the dlls/advapi32/crypt.c tests were bombing out > for me. This turned out to be due to dlls/advapi32/crypt.c:1649 > > > if (!key || !pbData || !key->pProvider || key->pProvider->dwMagic != MAGIC_CRYPTPROV) > > CRYPT_ReturnLastError(ERROR_INVALID_PARAMETER); > > [...] > So, this makes sense. Its that old chestnut of compiler being free to > evaluate if clauses in any order it chooses (for optimisation). The && and || operators in C are short-circuit operators, meaning they are always evaluated left to right, and further tests are not executed if the first ones fail. I'm afraid you wasted your time with that patch, there's nothing to fix here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Make winelib resource data writeable
by Dmitry Timoshkov 16 May '05

16 May '05

"Felix Nawothnig" <felix.nawothnig(a)t-online.de> wrote: > For PE files there is a hack in kernel/except.c which does COW for > resource data - but winelib apps crash when they try to write to it. > (If this is a design-decision please tell me) As it's clearly indicated in the error message in kernel/except.c only broken apps try to write to the resources. What your application is trying to do? -- Dmitry.

3 2

Re: PATCH: hglobalstream static
by Dmitry Timoshkov 16 May '05

16 May '05

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: > /*** > + * This implements the IUnknown method AddRef for this > + * class > + */ > +static ULONG WINAPI HGLOBALStreamImpl_AddRef( > + IStream* iface) > +{ > + HGLOBALStreamImpl* const This=(HGLOBALStreamImpl*)iface; > + return InterlockedIncrement(&This->ref); > +} I understand that this is an existing code, but calling InterlockedIncrement for a 'const' pointer looks very suspicious. Same for HGLOBALStreamImpl_Release, HGLOBALStreamImpl_Read and other interfaces which actually change the pointed data. -- Dmitry.

2 1

Re: Extending File Dialog to include unix file paths [4/4]
by Steven Edwards 16 May '05

16 May '05

Hi Michael, --- Michael Lin <mlin(a)corvu.com.au> wrote: > If your target platform is windows, don't define the WINE_UNIX_PATHS > flag when you compile and it will all behave > the same as before. It's only when you define WINE_UNIX_PATHS flag that > GetOpenFileNameW() will be mapped > to UnixFSGetOpenFileNameW() for example. Else it will call the same > function as before and shouldn't break on Windows. > WINE_UNIX_PATHS is currently not defined anywhere in WINE, so no one > should see any difference. To see the change, > you have to define that flag in your winelib application's makefile. But your defining UnixFSGetOpenFileNameW in the spec file so the import library will still have that function listed so if I link a dll to that import library its going to fail on Windows even if I am not calling that function. The Windows Linker/Loader is not forgiving like the Unix loader if the symbol is not found in the import table. It seems like Winebuild will need some magic as well if you don't want these function exported all the time. Thanks Steven Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html

4 3

Game sound problem with wine 20050310 (Debian testing)
by J. Grant 15 May '05

15 May '05

Hello, I have been trying to get audio working in sync with the game I am playing (Activision Call of Duty) I get this error: err:wave:DSDB_MapBuffer Could not map sound device for direct access (Input/output error) err:wave:DSDB_MapBuffer Use: "HardwareAcceleration" = "Emulation" in the [dsound] section of your config If I use the suggestion i get 1sec lag on in-game sounds. Someone #winehq gave me some tips. I added these extra lines to my ~/.wine/config file, pasted them to me on #winehq. I could not find these in the config documentation, could they be added somewhere please? [dsound] ;"Drivers" = "wineoss.drv" ; default for most common configurations ;"Drivers" = "winearts.drv" ; for KDE "Drivers" = "winealsa.drv" ; for ALSA users ;; HEL only: Number of waveOut fragments ahead to mix in new buffers. "HELmargin" = "5" ;; HEL only: Number of waveOut fragments ahead to queue to driver. ;"HELqueue" = "5" ;; Max number of fragments to prebuffer ;"SndQueueMax" = "28" ;; Min number of fragments to prebuffer ;"SndQueueMin" = "12" ;; Forces emulation mode (using wave api) "HardwareAcceleration" = "Emulation" ;; Sets default playback device (0 - number of devices - 1) ;"DefaultPlayback" = "0" ; use first device (/dev/dsp) ;"DefaultPlayback" = "1" ; use second device (/dev/dsp1) ;"DefaultPlayback" = "2" ; use third device (/dev/dsp2) ;; Sets default capture device (0 - number of devices - 1) ;"DefaultCapture" = "0" ; use first device (/dev/dsp) ;"DefaultCapture" = "1" ; use second device (/dev/dsp1) ;"DefaultCapture" = "2" ; use third device (/dev/dsp2) Unfortunately these did not really change anything. I uncomment them and changed them around to see if anything changed, but I had to go with eh "Emulation" bit uncommented as above to get the game to work at all. (Gave a sound error while loading otherwise) I wonder if this is a known problem (bug)? Is there a work around? Or a fix please? I am not on this list, so please include my email address in any replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio

4 8

Re: dlls/msvcrt/time.c build breakage
by Juan Lang 15 May '05

15 May '05

Oops, I mistakenly assumed daylight and timezone were available in FreeBSD too. I'll take a look this week when I get a crack at my FreeBSD box. --Juan --- Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> wrote: > The following change to dlls/msvcrt/time.c > > revision 1.22 > date: 2005/05/14 11:07:10; author: julliard; state: Exp; lines: +31 > -4 > Juan Lang <juan_lang(a)yahoo.com> > - move _timezone to time.c, and correct its type > - implement _tzset, and initialize _daylight, _timezone, and _tzname > from libc values > > breaks the build on FreeBSD 4.10: > > time.c: In function `MSVCRT__tzset': > time.c:351: error: `daylight' undeclared (first use in this function) > time.c:351: error: (Each undeclared identifier is reported only once > time.c:351: error: for each function it appears in.) > time.c:352: warning: assignment makes integer from pointer without a > cast > > Would you mind fixing this? > > Gerald > Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

1 0

dlls/msvcrt/time.c build breakage
by Gerald Pfeifer 15 May '05

15 May '05

The following change to dlls/msvcrt/time.c revision 1.22 date: 2005/05/14 11:07:10; author: julliard; state: Exp; lines: +31 -4 Juan Lang <juan_lang(a)yahoo.com> - move _timezone to time.c, and correct its type - implement _tzset, and initialize _daylight, _timezone, and _tzname from libc values breaks the build on FreeBSD 4.10: time.c: In function `MSVCRT__tzset': time.c:351: error: `daylight' undeclared (first use in this function) time.c:351: error: (Each undeclared identifier is reported only once time.c:351: error: for each function it appears in.) time.c:352: warning: assignment makes integer from pointer without a cast Would you mind fixing this? Gerald

1 0

Debugging remotely from Visual studio
by David Hemmo 15 May '05

15 May '05

Hello, After reading a mail exchanges about ptrace on Linux, I decided to switch to a newer Linux kernel to see how it modified my problem. Things got worse. Restarting a program from Visual studio stopped working. Is there anyone that can explain me how things are supposed to work ? I think I know the basics. To start, the debugger set the bit 0x100 in EFlags ot the current context, then wine test this bit to check what parameter to send to ptrace to restart the process. It gets blurry after that ... What happens after the traced instruction executes ? At least three parts are involved: - Linux that handle the first part of the exception - Wineserver - msvcmon. It is the visual C++ remote debugging program, but I think it could be any debugger. There may be a 4th player with the exception handling part of the debugged application but I am not sure. Thanks David

2 5

Re: comctl32: Move TrackMouse handling to MouseMove
by Dimi Paun 15 May '05

15 May '05

On Sat, 2005-05-14 at 11:12 -0500, James Hawkins wrote: > + LVHITTESTINFO lvHitTestInfo; > + INT nItem; > + > + if (infoPtr->bLButtonDown) { > + lvHitTestInfo.pt = infoPtr->ptClickPos; > + nItem = LISTVIEW_HitTest(infoPtr, &lvHitTestInfo, TRUE, TRUE); > + > + if (LISTVIEW_TrackMouse(infoPtr, infoPtr->ptClickPos)) { > + NMLISTVIEW nmlv; > + > + ZeroMemory(&nmlv, sizeof(nmlv)); > + nmlv.iItem = nItem; > + nmlv.ptAction.x = infoPtr->ptClickPos.x; > + nmlv.ptAction.y = infoPtr->ptClickPos.y; > + > + notify_listview(infoPtr, LVN_BEGINDRAG, &nmlv); > + > + return 0; > + } Please use 4-space indentation for new code. Currently listview is a mixture of 2/4 space indentation, but we should be moving towards 4 spaces if it's not a problem. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 1

Re: Video Capturing under Wine
by Maarten Lankhorst 14 May '05

14 May '05

> Basically applications have two obvious ways to use video capture > services in Windows. One is avicap32.dll which is basically the Video > for Windows way of doing this and the other one is > ActiveMovie/DirectShow, soon to be obsoleted by Microsoft as well, as it > seems. > Avicap32 implements two functions, one is for the enumeration of the VfW > devices registered in the system. For this it does enumerate all entries in > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MediaResources\msvideo > and for compatibilty reasons with 16bit Windows also in the Drivers32 > section in system.ini. I have an untested version of this code already. > The enumeration function does not try to detect any devices other than > what it finds in above mentioned places. I assume that a webcam driver > installation would have to do that. > The second function in Avicap32.dll creates a (hidden) window which > handles the actual interaction with the video device as well as being an > optional user interface for the video data. The communication with the > video device is always by so called installable drivers, like wineoss, > etc. is used for audio devices. The interface to these installable video > drivers is for the video device specific parts declared in a header file > msviddrv.h which is really part of the DDK. (How would we add that to > the Wine headers?) > In modern Windows systems there is one MS provided installable driver > vfwwdm32.dll, which is basically a translation layer between the > installable interface and modern WDM stream based video drivers. We are not windows, using HKLM/SYSTEM/.../msvideo would not be an option imho, because when should we write it? And what if you just connected your webcam and modprobe'd the drivers for it, it would make things too difficult. I think the best way is to use winmm like dsound/etc uses, and add a configure option in ~/.wine/config so you can select what video driver you want to use. Since I don't exactly know how winmm works, some insight in how (for example) the sound drivers in winmm are called/used would be more then welcome, since, unlike the rest of the stuff I worked upon until now was well documented, but I doubt winmm is... Maarten Lankhorst

2 2

Video capturing under Wine, some overview
by Rolf Kalbermatter 14 May '05

14 May '05

Prompted by the recent work by Maarten Lankhorst on getting his video cam to work in Wine, I did some in depth investigations on how Windows actually does this stuff. This is a summary of what I found and some thoughts about it. I would like some comments on how to progress. Basically applications have two obvious ways to use video capture services in Windows. One is avicap32.dll which is basically the Video for Windows way of doing this and the other one is ActiveMovie/DirectShow, soon to be obsoleted by Microsoft as well, as it seems. Avicap32 implements two functions, one is for the enumeration of the VfW devices registered in the system. For this it does enumerate all entries in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MediaResources\msvid eo and for compatibilty reasons with 16bit Windows also in the Drivers32 section in system.ini. I have an untested version of this code already. The enumeration function does not try to detect any devices other than what it finds in above mentioned places. I assume that a webcam driver installation would have to do that. The second function in Avicap32.dll creates a (hidden) window which handles the actual interaction with the video device as well as being an optional user interface for the video data. The communication with the video device is always by so called installable drivers, like wineoss, etc. is used for audio devices. The interface to these installable video drivers is for the video device specific parts declared in a header file msviddrv.h which is really part of the DDK. (How would we add that to the Wine headers?) In modern Windows systems there is one MS provided installable driver vfwwdm32.dll, which is basically a translation layer between the installable interface and modern WDM stream based video drivers. Devenum uses the avicap enumeration function to find all registered VfW video sources and provide them to an application. Presumably there are other possible video source objects which would provide a direct interface to WDM stream class devices somehow and could be enumerated by devenum as well. DirectShow seems to be somwhat complicated. Video sources can be provided from VfW again, which is provided by the "VfW Capture Filter" class in qcap.dll. This is basically a DirectShow filter wrapper around the same installable driver interface as is used in avicap32.dll (and through above mentioned vfwwdm32.dll driver an application can also access WDM stream class video capture sources indirectly. How the direct interface to WDM stream class devices is provide I haven't found out yet but according to MSDN it should be possible somehow. For Wine purposes the VfW path seems the most interesting one. Separating the Video4Linux interface into an installable multimedia driver such as winev4l would cleanly separate platform specific code from the rest of the Wine DirectShow and Avicap implementation. Trying to emulate direct access to WDM based drivers would not be possible anyhow, as that would seem to require kernel driver support, which is mostly absent in Wine. I could probably hack an experimental winev4l driver together based on the work already done by Maarten Lankhorst, but would first want to make sure that this is considered the way to go, before investing more time into this. While the current implementation by Maarten is not as clean and nice because of the direct V4L dependency in standard Wine DLLs, it is something which already works somehow and could be integrated into Wine in quite a short time. What are the thoughts about this? Rolf Kalbermatter

5 4

sonicstage
by wino＠piments.com 14 May '05

14 May '05

Hi , I have just bought a NH900 and wanted to try to get it to communicate with linux, I did a quick search before buying and found a ref to someone who reckoned to have got this working. I believe sonicstage2 under wine. Seem to have lost the link and google is not helping today. Anyone got any info on this ? TIA

1 0

Re: [WINEDOCS] Add French translation for Wine's FAQ
by Dimi Paun 14 May '05

14 May '05

On Thu, 2005-05-12 at 16:49 +0200, Francois Gouget wrote: > This patch adds the framework for translating Wine's documentation and > adds a translation of the FAQ to French as a demonstration. No compressed patches, please. Also, the patch is big, and some things are cleaner than others. Let's break it down a bit. > Here is what the framework does: > > * first it moves most of en/Makefile.in to Make.rules.in so that this > code can be shared across the various translations. Well, the reason I didn't do that is for cases like incomplete translations. We can move to Make.rules.in: -- DB2* defines -- the targets (docs, pdf, etc) -- the tar rules The rest we can keep local, see how things evolve. We can always refactor it up. > * the actual translation is stored in a po file, one per documentation > document. So for French we currently have fr/wine-faq.po and later we > will also have wineusr-guide.po and winelib-guide.po. I'm not too hot about it to be honest. SGML is hard on the eye, this .po stuff seems to be even worse. But maybe it's easier to work with due to the various tools. If it makes it easier for you to maintain the translation, I'm cool with it. However, I'm not sure this will be the preferred way for all translators out there, so we shouldn't force it on everybody. > * Using po files lets us track exactly which translation paragraphs > are up to date and which are not. It also lets us leverage the tools > that have been developed around that format such as KBabel and maybe > even make it possible for contributors to translate the documentation > online using tools like Pootle (http://pootle.wordforge.org/), Kartouche > (http://i18n.kde.org/tools/kartouche/) or Rosetta > (https://launchpad.ubuntu.com/rosetta). This is great, but I doubt such tools can tell you *what* changed when something did change (the *what* here is "how did paragraph change") > * The link between the SGML files and the PO files and back is handled > by PO4A (http://po4a.alioth.debian.org/). I'm a bit worried about this one. It's new, debian specific, etc. There's no .rpm for it, and that makes me nervous. Tools like this must be easily available. Even if we go for it, maybe we'll have to keep the generated .sgml in CVS (just like configure). > * So configure.ac checks for the po4a tools. If they are missing then > the translated documentation cannot be built. I also added a > Makepo.rules.in that should be used by Makefiles building translated > documentation. What it does is just include the main Make.rules.in file > and add a couple of rules for generating SGML using PO files, and > extending the 'clean' target. This last bit cannot be put in the > top-level Make.rules.in because it does '$(RM) $(ALLBOOKS:%=%.sgml)' > which would be unfortunate in the en directory. The $(RM)... can remain local, and the rules can go in Make.rules.in. It would be confusing to have too many rule files. > sed -e 's/^<$article .*$ lang="en">$/<\1 lang="fr">/' -e > 's/^<$book .*$ lang="en">$/<\1 lang="fr">/' wine-faq.posgml > >wine-faq.sgml || (rm -f wine-faq.sgml && false) Nasty. BTW, the 'lang="en"' part of the patch can go in separately too. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

3 5

winefile
by Martin Fuchs 14 May '05

14 May '05

Hi, I want to merge some Robert Dickenson's version of winfile (derived from the old winefile code in 2002) in the next time into winefile. At the same time I want to keep the code it in sync between the ReactOS code base and Wine. What do you think about splitting the source file into several smaller modules? winefile.c is quite large with its 4223 lines. Martin

3 4

Winelib's role in converting Windows applications
by Ira Krakow 14 May '05

14 May '05

As many of you know, Brian and I are writing a book on Wine and Winelib for Prentice Hall. Brian's doing the Wine part; I'm doing the Winelib part. At Wineconf, I had a number of conversations about Winelib's role in converting Windows apps. The consensus seems to be that the most efficient conversion path is for much of the Windows app to stay in Visual C++ (or whatever) and that only the modules that specifically require native Linux calls should be recompiled, via MinGW/Dev-C++ on the Windows side, and Winemaker on the Linux side, into Winelib objects. For example, if the application requires PAM authentication, or a Linux-based help system, these modules would be separated out and encapsulated as Winelib objects. I was thinking of using PAM authentication as a good example, since it works for any authentication scheme that the application requires. This is the approach I plan to take. I welcome all feedback. Thanks. Ira

6 5

Re: Assertion fails in riched20; relay debug segfaults
by Adrian Harvey 14 May '05

14 May '05

> On Wed, 11 May 2005 23:01:17 +1200, Adrian Harvey wrote: > > Well, I got some output at least! Never used strace before, but it > > looks kinda like a +relay trace for the kernel :-) > > Yep, that's exactly what it is :) > > > I also happened to be tailing the syslog (I was looking at something > > completely different) and I noticed that the following was written: > > > > May 11 22:50:55 orac kernel: strace[7749] trap stack segment rip:410c86 rsp:800000007b20 error:0 > > May 11 22:50:55 orac kernel: wine-preloader[7750]: segfault at 000000005575b624 rip 000000005575b624 rsp 00000000ffffc824 error 15 > > > > I doubt it's much use, but I thought any information might help here.... > > Somehow you managed to compile Wine as 64-bits, which isn't going to work. > I think you need to remove your current Wine installation and > install/compile it as 32 bits. > > thanks -mike OK, I've removed that install of wine form my system, updated to the latest CVS, re-run configure, make depend, make and make install, and still I get the same problem. I piped all the make output to a file, and the all the gcc commands have the -m32 flag after them (the winegcc ones don't, but these seem to all be linking rather than compiling.) I have run file over the binaries, and they all say ELF 32-bit LSB executable (or shared object, for the libraries). Out of interest, how did you know it had been compiled as 64 bit? Any ideas how I can track down which bit is being mis-compiled as 64 bit, so I can tidy up the build for that part? And is anyone else seeing the same symptoms (ie: WINEDEBUG="+relay" wine crashing)? I've got a pretty vanilla Fedora install, apart from being AMD64, so I shouldn't be unique.... thanks, Adrian

1 0

Re: Firefox 1.0.4 Installation
by Juan Lang 13 May '05

13 May '05

Andrew wrote: > Firefox appeared to install correctly, but it won't start. Trying to > install under winedbg with WINDEBUG=+trace winedbg to terminate the > application after I typed "next": Hmm, works for me here. I assume you mean WINEDEBUG=, not WINDEBUG=. And, do you mean WINEDEBUG=trace or WINEDEBUG=trace+all? I think +trace will have no effect, as trace isn't the name of a debug channel. --Juan __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail

1 0

Firefox 1.0.4 Installation
by Andrew Neil Ramage 13 May '05

13 May '05

When I tried to install Firefox 1.0.4 for Windows, I got the following output in the shell window I started wine from. andrew@zeus:~/Download/Software> wine Firefox\ Setup\ 1.0.4.exe fixme:win:SetWindowTextW cannot set text L"Extracting" of other process window 0x7002e err:static:STATIC_SetIcon huh? hicon!=0, but info=0??? err:static:STATIC_SetIcon huh? hicon!=0, but info=0??? err:ntdll:NtQueryInformationToken Unhandled Token Information class! fixme:shell:Stream_WriteLocationInfo writing empty location info fixme:shell:Stream_WriteLocationInfo writing empty location info fixme:shell:Stream_WriteLocationInfo writing empty location info fixme:shell:Stream_WriteLocationInfo writing empty location info fixme:shell:Stream_WriteLocationInfo writing empty location info fixme:exec:ShellExecuteExW32 flags ignored: 0x00000340 andrew@zeus:~/Download/Software> err:ntdll:NtQueryInformationToken Unhandled Token Information class! fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 andrew@zeus:~/Download/Software> Firefox appeared to install correctly, but it won't start. Trying to install under winedbg with WINDEBUG=+trace winedbg to terminate the application after I typed "next": andrew@zeus:~/Download/Software> winedbg Firefox\ Setup\ 1.0.4.exe fixme:console:SetConsoleCtrlHandler (0x405ef3e0,1) - no error checking or testing yet WineDbg starting on pid 0x15 In 32 bit mode. Wine-dbg>next Process of pid=0x00000015 has terminated Wine-dbg> Does anyone know what is going wrong ? -- Andrew You can be the captain I will draw the chart Sailing into destiny Closer to the heart Closer to the Heart by Rush (A Farewell to Kings, 1977) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: Extending File Dialog to include unix file paths [4/4]
by Steven Edwards 13 May '05

13 May '05

Hi, --- Francois Gouget <fgouget(a)free.fr> wrote: > No, that should not happen. If an application links with a library that > exports funcA() and funcB() but it only calls funcA(), then it will only > import funcA() and it will work on a system where that library only > exports funcA(). OK maybe I am thinking of a bug in binutils or something. There were a few of them caused problems when building on mingw which result in me having to hack Winebuild a bit. Thanks Steven Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

1 0

Re: winefile temporary allocations
by Francois Gouget 13 May '05

13 May '05

On Fri, 13 May 2005, Martin Fuchs wrote: > Changelog > use macros for platform dependent temporary allocations [...] > +#define TMP_ALLOC(s) HeapAlloc(GetProcessHeap(), 0, s) > +#define TMP_FREE(p) HeapFree(GetProcessHeap(), 0, p) > +#else > +#define TMP_ALLOC(s) alloca(s) > +#define TMP_FREE(p) > #endif Why is this needed? Doesn't HeapAlloc work on any 'Win32' platform? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

3 2

Re: Installing Acrobat Reader 7 and Acrobat in general
by gslink 13 May '05

13 May '05

Peter wrote: > I see. > Of course I have Acrobat 7 installed. The problem is Adobe does not > supply the DRM plugin (Yea I know some of you do not like DRM and I have > too some reservations but we should have the choice, shouldn't we?) > Since the only other way to get DRM support beside wine is VMware wich > is more ugly to set up. > > I would like to have a working Acrobat reader with DRM support on wine > since this is less trouble (and more efficent) then the VMware solution > people use atm. > > Maybe I can get Acrobat reader 5 with DRM support up and running. > Adobe has a very confusing policy of giving away information what > Version can on which Plattform. > I send them a note already but i fear (like always) I am ignored. :( > > cheers > Peter > > Am Donnerstag, den 12.05.2005, 11:46 -0400 schrieb gslink: > >>Use the native Linux Reader 7 from the Adobe web site. Running Reader 7 >>under Wine isn't worth the trouble. Acrobat Professional is a different >>matter. The latest Acrobat Professional that will work on Wine is 5. >>Both 6 and 7 require dlls that must be supplied from Windows. Seven has >>copy protect features that actually discourage use on any machine. With >>some trouble you can probably get 6 to work. It will currently install >>and with the addition of the missing dlls almost work. If someone wants >>to patch Wine so that 6 runs it would probably see considerable use. >> > > > The only difference between talking to a telephone pole and talking to Adobe is that if you drink enough the telephone pole will answer. In reality almost nothing of any importance currently runs on Wine without some setup. What you probably need to do is to experiment with replacing some of the dlls or adding some from Windows. This is usually what is necessary. You may also need to install the software in a Windows machine and then copy it over. Start trying things and something will probably work. I have been getting on the Wine people because this feature of Wine makes it useless for the average user. There needs to be some easy way for someone to report what is necessary to get a new version of something running or there needs to be a good configurator written. Wine is a very good program but the Wine group is making a classic programming error in forgetting the user interface. It doesn't make any difference how good it is if you can't get at it! In this case you can't.

2 1

Re: Looking for win9x/ME testers
by Saulius Krasuckas 13 May '05

13 May '05

* On Thu, 12 May 2005, Hans Leidekker wrote: > * On Thursday 12 May 2005 00:14, Kevin Koltzau wrote: > > The ole32_test.exe file is linked to missing export NTDLL.DLL:atoi. > > This patch fixes it. ... > Changelog: > Don't import from ntdll. Can someone explain me, please, where would atoi() function be linked now to? I still have not installed MinGW package, so cannot cross-compile winetest and cannot check this myself. :-/

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