wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Oh, the pain! Script to install a VB app that uses MS SQL
by Dan Kegel 23 Oct '05

23 Oct '05

I slogged through writing a shell script that works around all the problems I ran into which installing a VB app that uses MS SQL. Have a look, it's at: http://kegel.com/wine/initvbapp.sh.txt Oh, the pain, the pain! It had to download and install the MDAC runtime download and install the VB runtime download and build cabextract and unshield for the next step, download and manually unpack the ntwdblib.dll driver from MS SQL 7, work around Wine bug http://bugs.winehq.org/show_bug.cgi?id=3636, and work around a bug in the VB packaging wizard http://support.microsoft.com/kb/299645, and *then* run the app's installer. I haven't verified that the app runs once installed; I'm just so happy to have the installer complete with no errors finally. This is probably similar to what winetools does, but I haven't looked at winetools to see how much overlap there is. I certainly prefer a simple shell script like this to a menu-driven opaque program, at least when trying to understand root causes of problems. Hopefully this will help somebody else who's trying to get VB apps to install.

1 0

Re: fix for #3219
by Eric POUECH 23 Oct '05

23 Oct '05

why not test for '?' and '.' which are the forms we know off, instead of letting the door ajar ? A+ > Message du 19/10/05 18:27 > De : "Vijay Kiran Kamuju" > A : "Hans Leidekker" , wine-devel(a)winehq.org > Copie à : > Objet : Re: fix for #3219 > > I have kept it there incase of regressions > We can just easily uncomment and test. > > Thanks, > Vijay > > On 10/19/05, Hans Leidekker wrote: > > On Wednesday 19 October 2005 09:19, Vijay Kiran Kamuju wrote: > > > > > - /* MS mangled names always begin with '?' */ > > > - if (*sym->current != '?') return FALSE; > > > + /* MS mangled names always begin with '?' > > > + if (*sym->current != '?') return FALSE; */ > > > > It's better to remove code then disabling it > > this way. We can always refer to CVS history. > > > > -Hans > > > > > > > > > >

2 2

Re: Shell32 File Property dialog
by Detlef Riekenberg 23 Oct '05

23 Oct '05

Am Freitag, den 14.10.2005, 13:28 +0200 schrieb Johannes Anderwald: > I have a patch which adds file property dialogs to shell32 Welcome to wine. Your Idea is nice and many Thanks for your Wine-Support, but since wine is different from ReactOS, your Patch will not work here. I started half a year ago with similar Problems. Please read take a look in the "Wine Developer's Guide": http://www.winehq.com/site/docs/wine-devel/index And the Part about "Coding Practice" http://www.winehq.com/site/docs/wine-devel/codingpractice - Define a Unicode-String with L"text" does not work with gcc on unix. Please use the same Style as your Patch did for wProperties in "shlexec.c" (Array of WCHAR). - TCHAR is not used in wine. If there is a UNICODE and a ANSI implementation in Windows, implement the UNICODE-Version and let the ANSI-Version call the UNICODE-Version. - I don't knew, if DPRINT() works in wine. We use here: TRACE(), WARN(), ERR() and FIXME() with WINE_DEFAULT_DEBUG_CHANNEL() This messages go to the console. (There are more Macros for additional Debug-Channels as well) - You use numeric values very often (Dialog-Parameter, Buffer-Length) Are there really no defines for this Numbers? - K.I.S.S => Make your Patch as small as possible. An Idea would be to Start with one Page and add the other Pages later. There are some FIXME in the code (Example: Date/Time - Format). How much work is it to do it "the Windows-Way" ? The following Link is a useful collection of Coding Hints: http://wine-wiki.org/index.php/Coding_Hints (wine-wiki.org (private) started before the official wiki.winehq.org comes up.) Asking Steven Edwards how to Port from ReactOS to wine is IMHO another good idea. -- By By ... ... Detlef

1 0

Re: [LOSTWAGES] Correct comment about QT license
by H. Verbeet 23 Oct '05

23 Oct '05

On 10/23/05, Dimi Paun <dimi(a)lattica.com> wrote: > ChangeLog > Correct comment about QT license, Win32 version is now GPLed. > Also, both Qt3 and Qt4 can be compiled with MinGW these days. http://www.trolltech.com/products/qt3/platforms/supported.html http://www.trolltech.com/developer/platforms/supported.html

1 0

Re: enhmfdrv: Return proper values from GDI APIs
by Phil Krylov 23 Oct '05

23 Oct '05

Hi, Are there any problems to apply this patch before 0.9? On Mon, 17 Oct 2005 03:43:55 +0400 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > Hi, > > This patch fixes EMF rendering in some programs that depend on the fact > that SetTextAlign(), SetBkMode(), SetROP2(), SetPolyFillMode(), and > SetStretchBltMode() return proper values when called on a EMF device > context. > > > ChangeLog: > > Fixed EMFDRV_SetTextAlign, EMFDRV_SetBkMode, EMFDRV_SetROP2, > EMFDRV_SetPolyFillMode, and EMFDRV_SetStretchBltMode to return proper > old values of modes that are being set. Added FIXMEs for other cases of > improper return values. > > -- Ph. -- Ph.

3 3

preload libGL
by Tomas Carnecky 23 Oct '05

23 Oct '05

I need to preload my own library with a custom glXSwapBuffers(). But wine opengl libGL.so directly so there's no way to do it. I've ended up doing this: glXSwapBuffersType preload__glXSwapBuffers = (glXSwapBuffersType) wine_dlsym(RTLD_DEFAULT, "glXSwapBuffers", NULL, 0); preload__glXSwapBuffers(gdi_display, physDev->drawable); but that is not a nice solution. What about linking x11drv directly with libGL? tom

3 11

Caching for X11DRV_SetImageBits?
by Michael Carlson 23 Oct '05

23 Oct '05

Let me start off with an introduction. I'm a veteran C programmer, but I'm unfamiliar with programming X11 and unfamiliar with wine, although I've been looking into both recently to correct a problem I'm having with wine. I posted about the same problem in August on the same mailing list, about making function parameters const. This was a simplistic solution, but I suggested it simply because I didn't feel I had the time to familiarize myself with all the inner-workings of wine. Now, I believe I do have the time. To repeat the situation, I found that in several of the games I like to run, the same problem is causing wine to be slow: using oprofile, I find that nearly all of wine's CPU usage lies in x11drv, and 98-99% of the cpu usage in x11drv is taken up by calls to some of the convert functions in dib_convert.c. For example, in Civilization 3, some 98% of the CPU usage in x11drv is taken up by two functions: convert_555_to_565_asis, and convert_565_to_555_asis. This summer I had a similar problem on my laptop, where fce ultra was using the function convert_888_to_0888_asis for most of its cpu. Essentially, it seems that most of the work wine is doing when running these programs is just for converting between one pixel format and back, and I hope to find a good solution to this speed problem, preferably through caching. I'm writing to this list in hope of other more experienced wine hackers giving their advice, telling me what is possible, and what the best solution is, before I go too far on my own with this. I'm looking at a group of related functions in wine, in dlls/x11drv/dib.c. It came to my attention that in X11DRV_SetDIBits and X11DRV_SetDIBitsToDevice, wine always seems to end up calling X11DRV_DIB_SetImageBits, which calls (in my case, probably because my desktop is 16-bit color) X11DRV_DIB_SetImageBits_16, which in every case calls a convert function of one type or another (all of which are CPU hogs). These are the core functions that seem to be related to the problem. Here is my early analysis of the problem: X11DRV_DIB_SetImageBits always creates and destroys an XImage during the life of the function, and calls X11DRV_DIB_SetImageBits_16 (or another bit depth), which ends up converting the bitmap to the proper color format / bit depth. It seems to me the best solution is to use some kind of caching to save the converted bitmap in its cached form, preferably as an XImage. Inside X_PHYSBITMAP the HBITMAP is stored, windows' unique handle for that particular bitmap. So, what if we stored the appropriate converted XImage per-HBITMAP, per-bpp, so that it doesn't need to be created, converted, and destroyed each time, and we could delete all cached XImages corresponding to the HBITMAP from the cache when DeleteObject() is called for that HBITMAP? I'm doing a lot of guesswork on the inner-workings of wine, X, and the windows GDI here. Please tell me, am I on the right track for eliminating these unnecessary conversions? If not, where should I be looking? Again I'm new to wine, X, and somewhat new to GDI programming - but I would like to learn. Please, GDI/X11 experts, give me some advice on the best solution to this problem!

2 1

Mystery solved: acoc breaks Wine's configure!
by Dan Kegel 23 Oct '05

23 Oct '05

Here's the strangest thing I've seen for a while. I was tracking down why I could build Wine, but another guy on the same machine could only build a slightly broken Wine that gave the error Wine cannot find the FreeType font library. To enable Wine to use TrueType fonts please install a version of FreeType greater than or equal to 2.0.5. whenever you tried to use it. The first clue was funny output from Wine's configure script, though it was hard to see until I diff'd against good output, and used cat -v to make invisible chars visible: --- configure.log.good.txt 2005-10-20 10:57:21.000000000 -0700 +++ configure.log.bad.txt 2005-10-21 14:41:59.000000000 -0700 ... -checking for ldd... /usr/bin/ldd -checking for -lX11 soname... libX11.so.6 -checking for -lXext soname... libXext.so.6 ... +checking for ldd... /home/mmoss/bin/ldd +checking for -lX11 soname... libX11.so.6^[[0m +checking for -lXext soname... libXext.so.6^[[0m And what's that funny ldd? And what are those escape sequences? Turns the ldd is one wrapped by acoc (http://www.caliban.org/ruby/acoc.shtml) which colorizes the output, which also explains the funny escape sequences. This error went away when we stopped using acoc to colorize the output of commands like ldd. We had been using acoc-0.5.2, but the latest version (0.7.1) also exhibits the problem. I hope this helps somebody else who's scratching their head over strange build failures! - Dan

2 1

Re: shell32: Remove redundant .\\ from test files
by Jakob Eriksson 23 Oct '05

23 Oct '05

James Hawkins wrote: >Hi, > >I started by removing all .\\ from the shlfileop.c test file in msvc >and the tests all passed , but three of the tests failed in wine. > > If the tests fail on wine, should they not be todo_wine{} then? regards, Jakob

2 1

Re: Shell32 File Property dialog
by Mike McCormack 23 Oct '05

23 Oct '05

Johannes Anderwald wrote: > I have a patch which adds file property dialogs to shell32 Looks like you've written the patch for ReactOS... it doesn't apply to the current Wine tree. I think you need to do a little bit more work to get it ready for submission: * use TRACE instead of DPRINT * don't use %S in debug statements (with TRACE) it's not portable, use %s and debugstr_w(str) instead * in SH_FileVersionDlgProc you miss a break at the end of WM_COMMAND * the formatting is all over the place. 4 space indent, no tabs is prefered * make sure to use the A or W functions and types explicitly. eg. you use PROPSHEETPAGE where you should use PROPSHEETPAGEW. * this comments looks dodgy: "SH_FileTimerProc is invoked every 100ms to check if the property sheet should be closed required because the property sheet pages are MODELESS" Your Window proc will get a WM_CLOSE when you need to close, or WM_DESTROY when it is destroyed. Freeing memory and other things that need to be done when the window is closed should happen in the Window procedure, and there should be no need for a timer. Please take the time to build you patch with and generate it against the CVS version of WineHQ. thanks for the patch, Mike

1 0

Solaris Updates
by Robert Lunnon 22 Oct '05

22 Oct '05

I have posted my local patches to wine-patches. Note that for 0.9 I have posted most of the patches that are likely to be essential to build a working Wine package (other than those previously rejected) regardless of the shape the code is in. Some of it is very ugly and lacks integration for other OSen, I have noted these. Since this code is maintained as a delta from CVS wine specific to Solaris and only used for binary packages, it's not necessary to start out with the niceties all there (This particularly happens when I get deep into week long debugging sessions). Patches not sent are listed hereunder long with the reasons... Possibly essential (Show stoppers) ptrace stub patch - Disable debugger by returning error for all ptrace calls, add ptrace stubs (framework) to allow work on ptrace emulation layer for wine. -Previously rejected linking patch - since libwinecrt0.a was added wine has been broken due to the linker wanting to import main() in dlls, this results in unresolved symbols. I have temporarily worked around this and can build wine with a change to winegcc that links another archive (I call winedllcrt0.a) which omits the main() definitions in the case where -shared is passed to winegcc. Alexandre has asked that I keep looking for a way to make the Solaris linker successfully link an archive containing main() to dlls without the need to have two runtime startoff libraries. Patch won't be submitted until a final solution is found. Recommended functionality patches cpuid patch - CPUID detection using x86 cpuid instruction - previously rejected wineconsole/curses.c - Patch non-essential and FAR too hacky at this point - just removes all mouse code. Other Patches tools - automation patches to allow unattended build No interest to Wine project Debugger - work in progress, not working A complete set of patches (even the gross ones) are maintained at http://www.blastwave.org/wine

1 0

Re: dinput: Fix mouse poll and few other bugs
by Stefan Dösinger 22 Oct '05

22 Oct '05

Am Samstag, 15. Oktober 2005 18:49 schrieb Magnus Olsen: > Hi > This change allown me run all MS DirectInput sample with out any problem. > it also take care of bad writen dinput program that try getting the mouse, > Without calling on right api, see my commmect in dinput. I have not > tested in wine, But I have tested it in ReactOS and Windows. Did you forget to attach the patch?

1 0

autoexec.bat and pif's which run batch files
by paul 22 Oct '05

22 Oct '05

I have not seen this one problem listed and it may be a 1.0 target. Filed bug 3638. Legacy installers modify autoexec.bat to add the install directory to the path and may also use set's. After the installer installs the program will not run as it's bin directory is not in the path. This also could be a reason why many applications only work when run from the directory it is installed in. If windows type is set to 95 or less in winecfg then autoexec should be processed before running the program. I also have programs which uses a pif to run a batch file. The batch in a pif is disabled/stubbed. I plan to look at filling it that feature when I get some time. Paul Romanyszyn

1 0

Roadblock #1 for VB installers: MDAC
by Dan Kegel 22 Oct '05

22 Oct '05

A lot of VB apps use MDAC (http://msdn.microsoft.com/data/mdac/downloads/). They tend to include mdac_typ.exe, the mdac installer, and run it, but unfortunately, Wine doesn't seem to run it properly. (I'm testing using mdac 2.7 sp1, fwiw.) First, the MDAC installer refuses to run unless the registry key for IE6 is present. (OK, that's easy to work around... if you're a programmer. It probably ought to be a winecfg pulldown.) Second, even if the MDAC installer runs, all it does is install a bunch of directories under c:\windows\RegisteredPackages. The DLLs needed by the VB app are locked up in .cab's in those directories. In the app I'm trying to install, the installer then fails with err:module:import_dll Library MSDART.DLL (which is needed by L"C:\\windows\\system32\\msadox.dll") not found Something, somehow, is supposed to be triggering an unpack, but it's not happening. (See http://msdn.microsoft.com/workshop/delivery/download/download_node_entry.asp for a discusion of how the unpacking is supposed to go on Windows.) I've filed a bug report at http://bugs.winehq.org/show_bug.cgi?id=3636

1 0

Are Visual Basic install problems common?
by Dan Kegel 21 Oct '05

21 Oct '05

Is it common for Visual Basic applications to have problems installing under Wine? Take the recent post by Denis, for instance. He's trying to install a fairly complex Visual Basic app that uses MDAC, and the installer just won't run properly under Wine. (I've corresponded with him privately, and can give more details if desired.) I have this feeling that this isn't an isolated instance. Maybe there are hundreds of thousands of businesses and government offices that have large collections of VB apps written in-house, not yet ported over to VB.NET, which they'd like to run under Wine -- but they take one look at the trouble they have installing, and give up. Does anyone have experience rolling VB (not VB.net) apps here? Is it easy to create VB apps that install fine under Windows, but not under Wine?

3 6

version: updated trace for VERSIONED_PRINTER (v3)
by Detlef Riekenberg 21 Oct '05

21 Oct '05

Changelog: > - updated trace to support VERSIONED_PRINTER > This time without deleting the TRACE for the flags. Informations on the Web: "Specifying Printer Driver Version Numbers" > http://msdn.microsoft.com/library/en-us/graphics/hh/graphics/prtinst_17e31a… > -- By By ... ... Detlef

1 0

ActiveX controls in MSHTML?
by Dan Kegel 21 Oct '05

21 Oct '05

A systems integrator mentioned that many commercial ERP applications use ActiveX terminal emulator controls embedded in web pages. (I think http://www.zephyrcorp.com/terminal-emulator-activex-document.htm is an example of such an ActiveX control.) Presumably these will run in IE on Wine, but will they run in the new MSHTML browser that's part of Wine? (Sorry if my terminology is a bit off - I haven't played with mshtml ever.)

3 2

wine / Linux kernel interaction
by Damjan Jovanovic 21 Oct '05

21 Oct '05

I am working on STI for wine, and there is an issue I want to ask about. At present, I changed CreateFile() to open /dev/USBSCAN... on a "\\.\USBSCAN..." device, where /dev/USBSCAN... comes from a Linux kernel module that does the equivalent of Window's USBSCAN.SYS. And NtDeviceIoControl() checks whether the i/o control code is 0x8000.... (USB scanner ioctl) and if so, calls ioctl(). It all works (but most is hardcoded for my scanner at the moment). But, the kernel module needs to know whether a newly added USB device is a scanner or not, which requires access to the wine registry / SetupAPI. One option is to make some user-space utility that the module can query for this info. The other way it could be done is to give wine the ability to load the kernel module when wine starts, and pass it a list of parameters which are the scanners it should drive. And the third way is to use a private ioctl or the proc filesystem so wine gives a running instance of the module the list of scanners, when wine itself starts running. And how would the kernel module tell wine / STI a new scanner has arrived? Finally, could this kernel module be distributed with wine? Its acceptance into the Linux kernel tree is doubtful. Thank you Damjan P.S. Is anyone working on kernel handles for wine? __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs

9 15

wine FC package [was: Final call for bug fixes]
by Paolo Abeni 21 Oct '05

21 Oct '05

hi, I have build a FC4 rpm package adapting the MDK spec file and patches. All the files can be found here: http://magisystem.yi.org/rpms/ I hope that it can help... Regards, Paolo Abeni -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Audio, Video, HI-FI...oltre 2.000 prodotti di alta qualità a prezzi da sogno solo su Visualdream.it Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2954&d=21-10

1 0

Linking wine *dll.so libraries with Linux applications ?!
by Alexander Efremov 21 Oct '05

21 Oct '05

Hello, is it possible to link Win32 Wine libraries (*.dll.so) with a Linux application. Suppose we have a simple Linux gcc program main.cc #include <vfw.h> int main(int argc, char** argv) { AVIFileInit(); } which utilizes Win32 library features. When I try to compile it and link I do not have any problems: g++ -Wall -g main.cc -lavifil32 -o main But when I execute it I get a segmentation fault. Is there any way to avoid it ? May be I have to link other libraries ? Is it possible at all to dynamically link Wine libraries with Linux gcc-compiled code ? Thank you. -- Best regards, Alexander mailto:aefremov@mpi-sb.mpg.de

7 16

docs
by Brian Vincent 21 Oct '05

21 Oct '05

I don't want to step on any toes, but I plan on redoing the User Guide this weekend. Mostly it'll just be an extension of the existing stuff I wrote and bringing it up to date. I figure I can probably bang it out in a few hours. Is anyone else close to having docs completed? -Brian

2 3

Re: user/defdlg.c: Just restore focus to current control [Bug:430]
by Richard Cohen 21 Oct '05

21 Oct '05

Vitaliy Margolen wrote: > Restore focus should not select all text in edit control. Only tabbing into it > should do that (according to msdn). > > Vitaliy Margolen > > changelog: > user/defdlg.c: > - Restore focus to the current control without selecting text > As with Vijay's patch, this patch breaks TABbing out of the readonly edit field in the testcase to bug 430 Richard.

2 2

Re: GDI/tests: link to {G|S}etRelAbs() during runtime
by Dmitry Timoshkov 21 Oct '05

21 Oct '05

"Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: > I am sure FreeLibrary() call wasn't necessary, but that might change in > future (if gdi.dll gets linked only during runtime). Because of this I > didn't want to FreeLibarary() right after last call to GetProcAddress(), > so added it at the end of the test. Feel free to correct the test. :-) Since this is a GDI test it already implicitly links with gdi32.dll. So, there is no need for LoadLibrary/FreeLibrary, GetModuleHandle is enough. -- Dmitry.

2 1

Compile documentation problem
by gslink 21 Oct '05

21 Oct '05

If Wine is going to enter beta soon then someone ought to document the procedure for compiling the source. If FC is used to attempt such a compile and the instructions packaged with the source are followed the result will be a compile failure in fonts. This is in spite of installing fontforge. The fact that an additional library must be supplied should be mentioned in the installation instructions packaged with the source. Of course, if the RH rpm of fontforge is used then it will fail to install because of the missing library. Compiling fontforge from source or not installing it results in the Wine failure to compile. The readme should be fixed.

3 5

Re: [DOCS] winedlloverrides
by Dimi Paun 21 Oct '05

21 Oct '05

----- Original Message ----- From: "Jonathan Ernst" <Jonathan(a)ErnstFamily.ch> > For more informations about DLL overrides, please refer to section 3.1.2.1 of this guide. This 3.1.2.1 is likely to change, can we have a symbolic reference instead? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

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