Strange behavior on build
I'm having a strange behavior trying to build Wine on my machine at work
(which is a modified RH7.3 machine):
First of all, if I attempt to do a standard CVS checkout followed by a
make depend, the make depend failes with a dlls - no such directory
error, even though it exists.
Changing SHELL=/bin/sh to SHELL=/bin/bash in Make.rules and re-running
configure fixes this, but then I get stuck in a loop building - it looks
like the makefile starts building the dependancy wine, then builds
libs, then decides it needs to build wine to build libs and starts
that, then builds libs
I'm at a bit of a loss to explain the behavior, so does anybody have any
good suggestions?
Versions:
GNU bash, version 2.05b.0(1)-release (i586-redhat-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i386-redhat-linux-gnu
Linux version 2.4.20-openmosix1 (root@(none)) (gcc version 2.96 2731
(Red Hat Linux 7.3 2.96-113)) #1 Sun Jan 12 04:18:51 CST 2003
(if you would be so kind, please copy my work address of David
decimalpoint Hagood ('A'-1) aeroflex decimalpoint com since I am only
subscribed to the list on my personal email).
Problem with recent builds under RH8.0
Ever since upgrading to RH8.0, I've been getting the following errors when building Wine - even with a fresh CVS pull: device.o: In function `DrawPrimitiveI': /usr/src/wine/dlls/d3d8/device.c:392: undefined reference to `glMultiTexCoord2f'/usr/src/wine/dlls/d3d8/device.c:416: undefined reference to `glMultiTexCoord3f'/usr/src/wine/dlls/d3d8/device.c:516: undefined reference to `glMultiTexCoord2f'/usr/src/wine/dlls/d3d8/device.c:535: undefined reference to `glMultiTexCoord3f'/usr/src/wine/dlls/d3d8/device.c:730: undefined reference to `glClientActiveTexture' /usr/src/wine/dlls/d3d8/device.c:764: undefined reference to `glMultiTexCoord4f'device.o: In function `setupTextureStates': /usr/src/wine/dlls/d3d8/device.c:981: undefined reference to `glActiveTexture' device.o: In function `IDirect3DDevice8Impl_SetRenderState': /usr/src/wine/dlls/d3d8/device.c:2548: undefined reference to `glActiveTexture' device.o: In function `IDirect3DDevice8Impl_SetTexture': /usr/src/wine/dlls/d3d8/device.c:2977: undefined reference to `glActiveTexture' device.o: In function `IDirect3DDevice8Impl_SetTextureStageState': /usr/src/wine/dlls/d3d8/device.c:3156: undefined reference to `glActiveTexture' collect2: ld returned 1 exit status make[2]: *** [d3d8.dll.so] Error 1 make[2]: Leaving directory `/usr/src/wine/dlls/d3d8' If I disable the build of the D3D system, Wine builds and runs.
Re: Problem with recent builds under RH8.0
Uwe Bonnes wrote: Often for such problems a make distclean, .configure , make depend and make sequence helps. Bye Not this time. Same result.
Re: Problem with recent builds under RH8.0
Sylvain Petreolle wrote: whats your videocard and your drivers model/version ? xdpyinfo and glxinfo attached. Basicly a pull of the DRI CVS. name of display::0.0 version number:11.0 vendor string:The XFree86 Project, Inc vendor release number:4020 XFree86 version: 4.2.0 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x10feb80, revert to Parent number of extensions:28 BIG-REQUESTS DOUBLE-BUFFER DPMS Extended-Visual-Information FontCache GLX LBX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X-Resource XC-APPGROUP XC-MISC XFree86-Bigfont XFree86-DGA XFree86-DRI XFree86-Misc XFree86-VidModeExtension XInputExtension XKEYBOARD XTEST XVideo default screen number:0 number of screens:1 screen #0: dimensions:1600x1200 pixels (363x275 millimeters) resolution:112x111 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x3e depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:64x64 current input event mask:0xfa003f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMaskEnterWindowMask LeaveWindowMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals:8 default visual id: 0x23 visual: visual id:0x23 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x24 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x25 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x26 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x27 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x28 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x29 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x2a class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits display: :0.0 screen:0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI Radeon 20010402 AGP 2x x86/MMX/SSE OpenGL version string: 1.2 Mesa 3.4.2 OpenGL extensions: GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint,
Re: Problem with recent builds under RH8.0
Vincent Béron wrote: What's the output of rpm -q -f /usr/include/GL/gl.h and gl.ext? Mine's XFree86-devel-4.2.0-72, and I don't have any problem compiling Wine with OpenGL. My GL headers are from the CVS pull of DRI, so they aren't owned by any package.
LockFile support
I have an old, nasty application that uses the Paradox database engine. This app attempts to lock the database files using LockFile. Now, it USED to work under Wine. It no longer does. The program coughs up an error No access to directory, and stderr shows a bunch of LockFile not supported in server errors. Did the behavior of LockFile change in the past couple of months? Are there plans to add LockFile support into Wine?
Re: Texture problems under Wine - more info
Lionel Ulmer wrote: ' This begs the question: Does the Linux implementation of pthread really work anyway? Considering that about 2 months ago, I was able to play HalfLife Opposing Force all the way through under Wine, I doubt the pthread emulation is a problem. By the way, what drivers are you using ? XFree86 DRI for Radeon 7500 (r100 driver) from CVS. I haven't had time to begin regressing the OpenGL shim under Wine, as this weekend has been rather busy doing other things, but as I get time I will begin doing so.
Wine REALLY emulates Windows (was: Texture corruption in Wine)
I am continually amazed at how well Wine emulates Windows - for example, my recent experiences show Wine has the whole Just re-install it, it will fix it thing down pat! 8^ To recap the story thus far - Several months ago, I was able to play Halflife- Opposing force all the way through under Wine. Then my motherboard died, and I replaced it with an SMP mobo. I had to do some tweaks to my kernel, my X server, and to Wine to get everybody back up. But when I was done, and I went to install Halflife-Blue shift, the textures were screwed up. So were the textures in OpFor. I tried booting UMP, I tried scraping the fake Windows install and reinstalling, to no avail. Friday, I downloaded Transgamings WineX in an effort to remove a few variables from the matrix. WineX ran BlueShift and OpFor flawlessly - exonerating my X server, kernel and system. So, this morning I set about trying to find out what changed in Wine. I went back and pulled Wine as of the 20020902 tag, and rebuilt. Then I did my usual install method: rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R make install Still had no luck with Halflife - still had corrupted textures. So, I moved my fake Windows and .wine directories out of the way, created new, empty directories, copied my old .wine/config over, re-installed the Wine default registry, and re-installed Blueshift. And it worked. OK, maybe the install had problems. I moved my new fake windows and .wine directories out of the way, and moved the old directories back. And still, it worked. All textures were fine. Note: at this point, I should have had the OLD install of Blueshift back in place, and the old registry. The very one that didn't work five paragraphs ago. So, I went to my image of the current CVS of Wine, rebuilt it, and once again did a rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R make install. And still, it worked. In theory, I should have been back to where I started from. Except where I started from didn't work. Where I was did. Now, I am at a loss as to what could have changed from the non-working state to the working state. Like I said, Wine has the whole Windows mysterious changes thing down pat! But it works. As Bugs Bunny said, I don't ask questions, I just have fun. So, I am off to kill some headcrabs. But for the life of me I don't know HOW what I did fixed it
Texture problems under Wine - more info
As I've stated in previous mailings, I've started having problems getting HalfLife to run under Wine - while at one time I was able to complete all of HalfLife - Opposing Force running under Wine, now I am unable to get the textures to render correctly. I have more information - I subscribed to Transgaming, downloaded the current WineX, installed HalfLife under it, and it works correctly. So, that would tend to exonerate my libGL, my system, and HalfLife, and leave only Wine as the suspect in the problem. So, the question is What is the difference between the WineX OpenGL library and the Wine OpenGL library? I hope to do more research on this over the weekend, but thought I'd post this now in case it rang any bells with somebody else.
Re: Screwed up textures in OpenGL apps
Chris Thielen wrote: I do believe there are OpenGL regressions. I have a single processor system with a working OpenGL, yet OGL games under Wine have texture issues they did not have previously. I'm not entirely sure it's wine, as I've updated my Mesa/X/modules many times. You are in the same boat as I - I've upgraded my XMesa (currently I am running a CVS pull of the DRI mainline branch) - however since all my native apps are fine, I conjecture that it is something wrong between the Wine OGL shim and the native OGL library.
Re: Screwed up textures in OpenGL apps
Lionel Ulmer wrote: Out of curiosity after the DoubleBuffered thread Does this fix your problem too ? No, I was running DesktopDoubleBuffered = Y already.
Re: Screwed up textures in OpenGL apps
Dan Kegel wrote: Please verify that booting with just one CPU active doesn't fix the problem. e.g. at lilo prompt, do something like linux nosmp It could be that Wine doesn't support SMP yet. - Dan First thing I tried, and with no change, so I don't think it's a SMP issue. Furthermore, my other apps under Wine work fine, only the OpenGL ones die.
Screwed up textures in OpenGL apps
I'd asked this before, but received no response, so I'll ask it again. Does anybody have any suggestions on where to start debugging textures being wrong under OpenGL apps under Wine? Specifically, I am trying to get HalfLife-Blue Shift to run, but all the static textures (walls, floors, etc.) are screwed up. The dynamic textures on things like people are fine. Now, I USED to have Halflife running great, but then I upgraded my system to a SMP P3 system (I had been running a UMP P3) (the old system died.) All my native apps (Q3A, RTCW, gears, etc.) are just fine. Only Windows apps running under Wine are screwed up. Does anybody have a simple Windows OpenGL app I can use for testing? Or a direction to begin looking in? I do know this - forcing OpenGL to go to indirect rendering does NOT fix the textures - they are still just as screwed up, just a lot slower.
Strange problem on serial port
There seems to be a strange problem related to the serial port. Specifically, when running Delorme AAA MapNGo 4.0, and attempting to use GPS navigation, it is unable to communicate with the GPS device. On stderr Wine is printing out RtlNtStatusToDOSerr - unable to map 0102 This only happens when the GPS device is connected and sending data, otherwise no error is printed. I know that the device is sending, because Minicom will show the data stream from the device. This also leaves out permission problems as both Wine and Minicom are running with the same permissions. A bit of grepping through the code indicates the likely error code is STATUS_TIMEOUT. Could it be that the serial I/O routines are incorrectly returning STATUS_TIMEOUT to the calling program when data was read? Additionally, I have another Windows program that accesses the serial port without problems - could it be that second program is ignoring the timeout error, while the first is not?
Re: Wine securityflaw: Protect against root
P. Christeas wrote: Write a segment of code that will abort wine, if it is run as root (that is, just before wine starts anything). This piece of code should only be explicitly disabled in the 'configure' script. That way, only a I slightly disagree - I think the thing to do would be to have wine not run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is set, AND THEN pop up a dialog box that requires confirmation before continuing. I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed). Since I know of no mail client for Linux that would set the X bit on an attachment, this would help protect users from themselves, while allowing those that need to be able to take the risks to do so. And as for making / available as a Wine drive - how about creating a tool that would allow you to add or remove drive mappings at run time? So that if I find that I really do need /usr/foo/bar/baz available to Wine, I can run a program that tells wineserver to add that as drive Q: for now.
Re: Wine securityflaw: Protect against root
Eric Pouech wrote: does rm have such an option ? rm doesn't, so I don't see any reason for Actually, rm DOES have such an option: -i, --interactive prompt before any removal AND certain distros (RedHat for example) alias rm to rm -i by default. Also, I stated that the command line parameter to wine would be required to even start the process - in other words, if you didn't supply it, you would not get the dialog, wine would just terminate. AND, this would not necessarily have to be bloat in wine, it could be handled by a default wrapper - the wrapper checks UID and command flags, provides feedback if Wine needs to rebuild the font cache, etc. You represent one extreme of the spectrum - This isn't Wine's job, we shouldn't do anything. The other side - Wine should be safe. If things aren't safe, don't run, has also been represented here. I'm just suggesting a middle ground.
Re: Listview Z8
Andreas Mohr wrote: What a weak and useless suggestion, this will run out of characters in no time at all ;-) Better use Chinese characters ! Bah! You are still weak! Better to use Klingon - I do beleive they've reserve some Unicode space for them!
Re: Listview Z0 (roll-up patch)
Dimitrie O. Paun wrote: The algorithm has been: start a new series when Alexandre has committed the previous one. So, for example, because I've started the Z-series last night, that means that Alexandre already committed the X-series. So the only outstanding patch not committed to CVS is Z0. I don't see a need for a roll-up patch ;) That helps, but also leaves me with a conundrum - when I do a CVS update on my machine at work, and rebuild wine (make clean, make depend, make, su, wipe wine directories in /usr/local, make install, exit, run Mng4) I get the listview crash on Along the way. I haven't been updating my machine at home, which had the patches applied, so I thought the patches were not in CVS. I will do a cvs up -C and rebuild here at home, and see what I get.
Re: Listview Z0 (roll-up patch)
Well, a cvs up -C and rebuild, and things are find here at home. I'll have to see what is up with my machine at work Monday...
Appplied U[1-5], still faults
Applied and tested listview patches through U5 - The road type column in the directions window is back (good), but the system still dies on the Along the way (bad), with the same assertion failure as the previous report.
OpenGL problems - textures hosed
I'm getting some strange textures on HalfLife, Opposing Force, and Blue Shift: Sample screen shots are here: http://sktc.net/~wowbagger/ba_hazard1.png http://sktc.net/~wowbagger/ba_hazard10001.png Specifically, any static texture is screwed up. Dynamic textures, like water or people are OK. Native GL apps, like Q3A, RTCW and UT are fine, which would tend to exonerate the local GL. This is running the CVS of Wine, updated a few hours ago (call it noon US Central Daylight time 19 Oct 2002 (UTC-5)), and the main branch of the DRI CVS, on a dual P3-1GHz machine. I have tried coming up in single processor mode with no change in rendering. Any pointers?
Re: Listview regression
Dimitrie O. Paun wrote: On October 19, 2002 11:34 am, David D. Hagood wrote: Second, when I do the Along the way, the program cores out. This one's tricky. Can you please retest (it will still crash), and send me the log, after applying thing patch: The patch is not applying - Is this supposed to apply to the current CVS, or to the current patch set (including V0)?
Re: Linstview regression, big time
Dimitrie O. Paun wrote: On October 15, 2002 10:04 pm, David D. Hagood wrote: What can I do to help on this? Would posting a debug message dump showing the list items being inserted be of use? Yes, please send me a trace of: --debugmsg +listview And if you can, screenshots with the said listview with it working, and not working OK, the files are here: http://sktc.net/~wowbagger/listview.tar.gz This file contains the following directory structure: wine/working - captures from an earlier version of wine that works wine/notworking - captures from the current (within a day or two) CVS In each directory, there is a log file created with wine --debugmsg +listview,+treeview as well as 2 screen captures, one of the main application screen, and one of the Along the way dialog. I tried to keep the interaction with the program identical in each case: 1) Launch program with the trip already defined. 2) Compute quickest route 3) snapshot main screen 4) Compute along the way 5) snapshot along the way dialog 6) Quit 7) Do you want to save your changes - NO The two runs were done on different machines (my laptop has the working version, and my main screen the non-working version), but the installed application is the same in both cases. I have pulled the Wine version from my laptop over to my main machine, but I don't have it installed right now, and I wanted to get this done before I went to work. If there is anything else I can do, please let me know.
Re: Linstview regression, big time
Dimitrie O. Paun wrote: I guess the problem with the main screen is that the listview to the left mangles long items when drawing them, just like in the attached picture, right? If so, you haven't tried the latest patches... ;) Can you please confirm it's OK now? I can confirm the listview in the main window is not showing the corruption. However, I can also confirm that the problem in the Along the way window is still present, as you can see in this file: http://sktc.net/~wowbagger/listview2.tar.gz This is with a CVS pull of about an hour ago. I do have an additional datum - If I create a very LARGE list of items (Along the way-all within 50 miles, no filtering) a FEW of the items show on the list.
Linstview regression, big time
Since the work on the listview rewrite has started, the listview has regressed big time. Running Delorme's AAA MapNGo V4.0, the Along the way window HAS-A listview into which are inserted the items found. This used to work in the old code, but now nothing is shown. I know the items themselves are being inserted. What can I do to help on this? Would posting a debug message dump showing the list items being inserted be of use? I'm not a Windows programmer, so I don't know how quickly I could actually come up to speed on the code itself, but I am quite willing to try code out and report on the success or failure of it.
OpenGL textures are wrong under HalfLife
My old motherboard died, and so I upgraded from a single P3 to a dual P3 system. I went to run HalfLife, which had been running beautifully under Wine, and now all the wall textures are screwed up. There is nothing of the proper textures in them - it's not like the colors are screwed up, more like the actual data is screwed up. However, it IS consistent from run to run - the same patterns on the same vertexes each time. The various humans in the level are fine - it is just the environment that is screwed. This is running the OpenGL setting in HL - I thought I'd try the DirectX setting, but all I get there is This is not supported by your card. Now, I have upgraded XFree to the latest CVS pull, I rebuilt my kernel, and upgraded Wine, so it COULD be any of the above. However, I pulled an older version of Wine from another machine with the same results. Native GL programs like Q3A, RTCW, and UT all look fine, so the native GL layer is running well. Could this be an artifact of SMP? Or is there something that Wine does differently in accessing the GL libraries from a native app that would explain this?
Problems with multiple Wine programs at once
I have the misfortune of needing to use Windows based DSP compilers for a project I am working on. Fortunately, they run under Wine just fine. So, the actual makefile is executed by a native GNU/Linux make, but the compile and assemble parts are Windows programs running under Wine (using Linux's binfmt_misc to launch them.) If I do a normal make, all is well. However, if I try to do a make -j2 then after a few moments all the wine processes will freeze. Doing a ps -o wchan shows all the wine processes stuck in pipe_wait, and the wineserver process in do_poll. Has any body else seen this sort of behavior?
Re: PE support in MZ_Exec() /winedos/module.c
Dmitry Timoshkov wrote: Chris Morgan [EMAIL PROTECTED] wrote: I have a .com application that is calling out to dos int21 4Bh to load and execute a program. snip If that is what Windows really does, then your approach is certainly right. more snippage Would it not be better (at least under Linux) to simply allow the normal OS load process to handle this? Since Linux can be configured to directly call Wine to run DOS/Windows binaries, the would allow them to run normally, plus if you wished to replace the DOS program with an equivelent native program it would still work.
CUPS and Wine
I've been having trouble with my RH7.2 LPRng based printing, so I decided I'd try installing CUPS. After fighting for hours to get this so-called easier printing system installed and working, I finally got to where I could print from Linux apps. Now, however, Wine steadfastly refuses to bring up a meaningful print dialog. I've gone into system.reg and win.ini and removed all the entries relating to the printing system, to no avail. Wine sort of recognises that there is a printer named Color managed by CUPS, but it cannot get any kind of properties for it - no paper size, no queue, and any attempt to accept the dialog is either ignored or results in a fault. This is with a CVS pull and clean rebuild as of 30 minutes ago. Where do I go from here?
Re: CUPS and Wine
Andreas Mohr wrote: Add to that the fact that CUPS gets rather completely rid of the useful Unix filter machanism, and you really start to wonder whether CUPS really is better than say lpd+printtool. Quite the other way around or so... Actually, I do beleive that CUPS does use a filter mechanism internally. But I do agree - I'm not as sure that CUPS is all that much better. But to REALLY fix printing would mean far more than what CUPS can do - IMHO what we need is more of a RPC style system, where the client app communicates bidirectionally with the print server, so that the client can ask What can you do for me?, the server responds I can staple, collate, bind, and add gold leaf inlay, and the client can present that to the user. Maybe some sort of XML/SOAP sort of thing (-1, Offtopic). Known problem :-\ CUPS *should* be totally easy to set up in Wine, yet for some reason Wine stumbles hard and dies instantly. Then I respectfully suggest the the documentation should reflect this - I had a perfectly good LPRng system running, and the only problem was getting Wine to talk to my color printer. CUPS is GREAT sayth the docs, so installth CUPS shall I do If noone has a stab at fixing this, then maybe I'll have some time to fix it. Don't ask for a close look at my ToDo list, though... ;-) Know the feeling... AFAIR we also have a bug reported for that, and if there isn't one, then it's about high time to create one. I was going to do this very thing (I am a big champion of Bugzilla at my place of employ - I have the attitude of If there ain't a bug agin it, it don't exist!) but when I try to query the Bugzilla database, I get: Please stand by ... Content-type: text/html Software error: SELECT bugs.bug_id, bugs.groupset, substring(bugs.bug_severity, 1, 3), substring(bugs.priority, 1, 3), substring(bugs.rep_platform, 1, 3), map_assigned_to.login_name, substring(bugs.bug_status,1,4), substring(bugs.resolution,1,4), substring(bugs.short_desc, 1, 60) FROM bugs, profiles map_assigned_to, profiles map_reporter LEFT JOIN profiles map_qa_contact ON bugs.qa_contact = map_qa_contact.userid, longdescs longdescs_ WHERE bugs.assigned_to = map_assigned_to.userid AND bugs.reporter = map_reporter.userid AND bugs.groupset 0 = bugs.groupset AND longdescs_.bug_id = bugs.bug_id AND (bugs.product = 'Wine') AND (bugs.bug_status = 'NEW' OR bugs.bug_status = 'ASSIGNED' OR bugs.bug_status = 'REOPENED') AND (INSTR(LOWER(longdescs_.thetext), 'cups')) GROUP BY bugs.bug_id ORDER BY bugs.priority, bugs.bug_severity: Can't write, duplicate key in table 'longdescs_' at globals.pl line 231. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error.
Re: Fixes for ADPCM decoding.
Gads. I knew better than that. Sorry, diff -u attached.
Changelog:
ADPCM nybble processing order was incorrect.
? console/Makefile
? controls/Makefile
? files/Makefile
? graphics/Makefile
? graphics/enhmetafiledrv/Makefile
? graphics/metafiledrv/Makefile
? graphics/win16drv/Makefile
? graphics/win16drv/prtdrv.glue.c
? graphics/x11drv/Makefile
? if1632/Makefile
? if1632/relay16.s
? libtest/Makefile
? loader/Makefile
? loader/ne/Makefile
? memory/Makefile
? misc/Makefile
? msdos/Makefile
? relay32/Makefile
? scheduler/Makefile
? win32/Makefile
? windows/Makefile
? windows/x11drv/Makefile
? windows/x11drv/wineclipsrv
Index: dlls/msacm/imaadp32/imaadp32.c
===
RCS file: /home/wine/wine/dlls/msacm/imaadp32/imaadp32.c,v
retrieving revision 1.5
diff -u -r1.5 imaadp32.c
--- dlls/msacm/imaadp32/imaadp32.c 31 May 2002 23:25:48 - 1.5
+++ dlls/msacm/imaadp32/imaadp32.c 10 Jun 2002 02:53:41 -
-284,16 +284,16
{
for (i = 0; i 4; i++)
{
-process_nibble(*src 4, stepIndexL, sampleL);
+process_nibble(*src, stepIndexL, sampleL);
W16(dst + (2 * i + 0) * 4 + 0, sampleL);
-process_nibble(*src++, stepIndexL, sampleL);
+process_nibble(*src++ 4, stepIndexL, sampleL);
W16(dst + (2 * i + 1) * 4 + 0, sampleL);
}
for (i = 0; i 4; i++)
{
-process_nibble(*src 4, stepIndexR, sampleR);
+process_nibble(*src , stepIndexR, sampleR);
W16(dst + (2 * i + 0) * 4 + 2, sampleR);
-process_nibble(*src++, stepIndexR, sampleR);
+process_nibble(*src++ 4, stepIndexR, sampleR);
W16(dst + (2 * i + 1) * 4 + 2, sampleR);
}
dst += 32;
-335,9 +335,9
for (nsamp = nsamp_blk; nsamp 0; nsamp -= 2)
{
-process_nibble(*src 4, stepIndex, sample);
+process_nibble(*src, stepIndex, sample);
W16(dst, sample); dst += 2;
-process_nibble(*src++, stepIndex, sample);
+process_nibble(*src++ 4, stepIndex, sample);
W16(dst, sample); dst += 2;
}
/* we have now to realign the source pointer on block */
Re: Concerning the boot procedure for renaming/deleting files
Gerhard W. Gruber wrote: Does anybody know what the \??\ stands for and wether the '1' for the I cannot answer the second part, but the \??\ is Windows NT's answer to / - it is the root of the filesystem that is visible from within the NT kernel. Various device files, and mounted file systems are visible here, like a Unix / directory.
Re: Wine's path VS host path
The problems with adding the code directly to the Wine config path are: 1) We package the tools along with the project - that way, if the tools are updated for a giving build, they will always be available with that build. I've done too much code archeology where I couldn't build a release because of subtle differences between tool versions, and I don't want to play that. 2) Our release procedure states that the developers are to make the code available to a software configuration control and management person, and they regenerate the project. The less configuration they have to do beforehand the better. 3) There can be multiple copies of the project checked out of CVS - I would like to be able to just do a cvs co project; cd project; ./m and have a build. Adding the tools to Wine's path will work, however it introduces a point of difference between running under CMD.EXE under Windows and running under Wine in that one way you can dynamically extend the path, one way you cannot.
Re: Wine's path VS host path
Andreas Mohr wrote: On Thu, Feb 14, 2002 at 06:17:56PM -0600, David D. Hagood wrote: My newly submitted patch implement App Paths support might just be what you need... (disclaimer: I did *not* implement it for you ! :-) I would never be so foolish as to expect someone to implement something just for me ;^ However, I know for a fact this app is only searching the path - under Windows it's possible to extract the project to any directory and start a build, and all I do is add it to the environment PATH, not a registry key.
Wine's path VS host path
Due to circumstances beyond my control, I have an embedded system that I am developing that uses Windows based compilers. Unfortunately, WinNT bluescreens too much for me to be able to work, so I have ported the project to using Gnu Make, with the compilers being executed via Wine. The problem is that the compilers search the path for their sub-components (just like GCC does - the driver calls the preprocessor, compiler, assembler, etc.). Now, the location of the project within the filesystem is not fixed - it depends upon where the developer checks it out. The project has the compilers stored along with the code, so the project is self-contained. The project has a shell script that sets several environment variables describing the location of the project, and adds the needed directories to the Unix path. However, Wine (wisely) does not make that path available to the Windows program, so when the compiler driver looks for the preprocessor, it bombs. As a work-around, I've stated the the developers must install the tools into a fixed directory, and add that directory to the Windows path as defined in ~/.wine/config. However, it would be nice if the setup shell script could add the tools directory within the project automatically to the Wine path. Has any thought been given to honoring a WINEPATH (or similar) environment variable, which would be added to the Wine path at runtime? On a related note: would it be possible to have a means to tell the wineserver process to hang around for a few seconds after the last wine process using it has terminated? Again, in this make process you get lots of start wine, start compiler, compile, exit. Start wine, start compiler, compile, exit operations - if the wineserver stuck around for 2 seconds after the last wine process terminated, this would aviod starting and stopping the wineserver process.
Re: Wine's path VS host path
[EMAIL PROTECTED] wrote: Pity you couldn't use some other environment variable. The entire unix Yes, but make must also be able to find the tools, hence they are in the path (I am using Linux's binfmt_misc with the appropriate settings so that the programs are directly executable). compiler would look in, say MYPATH, a shell script could easily set that how it liked. If I had the source, it would already be running natively. However, in this case I don't - the compiler is for a DSP, and is most definitely Closed Source *nix current directory is another possibility you should consider. If The project is a rather large one, comprised of over 9000 files in many different directories. Having the tools always in CWD isn't an option. wineserver -p Great! One down, one to go. I'll add that to the initial setup shell script. Perhaps, one fine day when I'm not trying to get a 160G drive to play nice in my computer, and I've taken the time to get ADPCM working in Wine, I can add some sort of additional path environment logic in. And **I** would actually rather release under LGPL, thankyouverymuch.
Re: wineserver (and fonts)
One thing I'd like to see some consideration given to is a way to cache the parsing of the fonts in the wineserver (or something similar). I have a lot of X fonts on my system, and several of them are not recognized by Wine's font parser. Result: Wine has to rescan the fonts every time it starts. If either a) Wine could be configured to skip fonts it doesn't understand (and thus the cache would be built and valid) or b) some process shared to all Wine processes on the same display could parse the fonts and make the font data available.
