January 2004 - Wine-Devel - list.winehq.org

Re: Add iccvid.spec to winapi_check

by Hans Leidekker

On Friday 16 January 2004 09:13, Dimitrie O. Paun wrote: > We can do that even now, by turning the problem inside out: > -- teach winapi_check the simple find trick > -- provide a (manually maintained) list of exceptions OK, here's a patch that does that. Afterwards do: cvs rm -f tools/winapi_check/modules.dat -Hans Changelog: Get rid of the static module list.

Jan. 18, 2004

Re: I'm off to Cuba!

by Brian Vincent

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

Jan. 18, 2004

Alsa 1.0 patch for audio.c

by Brett I. Holcomb

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

Jan. 18, 2004

I'm off to Cuba!

by Dimitrie O. Paun

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

Jan. 18, 2004

Re: PATCH: tools/winewrapper and memory limits

by Gerald Pfeifer

On Sun, 18 Jan 2004, Marcus Meissner wrote: > This does not really help, since winewrapper is only used for in-source-tree > startup. > > Once installed, 'wine' is no longer this shellscript, but an ELF binary. Of course you're right (I didn't forget our discussion <g>). Still, this very patch would have saved me at least one hour, probably more in trying to debug things, so I think it's worth getting applied. Concerning a real installation, perhaps also in that case 'wine', as invoked by the user, should become a shell script performing this test (and, later, perhaps further ones) before invoking the real thing? Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

Jan. 18, 2004

Re: PATCH: tools/winewrapper and memory limits

by Marcus Meissner

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

Jan. 18, 2004

Re: Need help debugging ... Ddraw issue

by Andreas Rosenberg

> Perhaps. I'd be willing to bet that virtually all (gui) win32 apps are > tested by running it from explorer or the shell, which seems to use full > paths though. I'd also bet 5 EUROs ;-) > So the fact that we usually run without a full path seems to > be problematic. I guess there's a slight chance it could break apps > designed to be run from the command line in Windows which might make > similarly bad assumptions. Perhaps a config option, override-able in > appdefaults, which controls passing the full path to the app - on by > default. Sounds good. > This leaves the question of where it gets the command line from, of > course. If not argv[0], not WinMain, then where? I find it hard to believe > the game does a TEB->PEB to get this, given that those structures are > undocumented. Jason wrote: >The one thing I couldnt answer is how the game 'gets' the command line. >It doesnt (didnt!) appear to use any API to do it, although I didnt >spend long looking into this. Could it be that the string containing the name of path and exe was not retrieved from the command line, but using GetModuleFileName or GetModuleFileNameEx? At least I would use this function if would like to get path where my exe is running. Another idea would be that the crash happens in the startup code or in the (C?) library part. There it could easily be that the PEB is being accessed, because they prepare the arguments for main / WinMain. If somebody could provide me the problematic exe of DK and the address where the crash occurs I will put it through IDA pro. This might help lifting the mystery. If IDA pro detects which compiler suite has been used to link the EXE, it should be "easy" to detect where the string came from... -Andy

Jan. 17, 2004

Re: winecfg: a patch to review

by Ivan Leo Murray-Smith

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

Jan. 17, 2004

Re: winecfg: a patch to review

by Kevin Koltzau

On Saturday 17 January 2004 12:41 pm, Dimitrie O. Paun wrote: > > I agree that [Version] should be an app specific setting, it is a > > frequently used option. Maybe we can roll version settings and the Dll > > settings tab together into an "Application" tab? > > I think this is a good idea. In general speaking, this per-app > settings is a hack required by poor implementation. Windows > doesn't need it, so we should be fine without it. Therefore: > -- we should try to minimize it's use > -- eliminate it in the future > -- not encourage people to use it, unless required > Thus cluttering the interface with it would be a bad plan IMO. > Having it in a separate tab can keep us honest to not > overuse it, and to more easily get rid of it in the future. Windows actually does have a few settings like this (Well, XP does) You can specify an EXE will run in the following compatabillty modes: Windows 95 Windows 98 / Windows Me Windows NT 4.0 (Service Pack 5) Windows 2000 as well as specify the app should run in 256 colors, disable visual themes, run in 640x480 resolution There has been many cases where I've found applications that refused to run on XP and being able to specify the Win95 or NT4 compatibility mode worked great

Jan. 17, 2004

Re: GetShortPathName broken

by Stefan Leichter

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

Jan. 17, 2004

Re: Try using the Mozilla Active X control in MSHTML

by Steven Edwards

Hiya Mike, --- Mike McCormack <mike(a)codeweavers.com> wrote: > Using Mozilla to implement IWebBrowser seems to be the Right Way for > me, > as the Mozilla project is already trying to do that themselves... > it's a > common goal that we can work together on! Yes. We with ReactOS need this also. All three projects have a common goal here. > It would be pretty cool if we could compile Mozilla as a winelib app, > or > figure out how to do get debugging info out of the control so we > could > see what needs to be fixed for it to work. Most of the hard part should be done for this if WineGCC is ready. You can now build mozilla on Mingw as long as you disable MAPI and ActiveX. Of course ActiveX will need to be fixed to allow the control to be embedded. > I'm pretty interested to work on this too, but unfortunately there's > other "real work" that I need to get done at the moment. Such is life. The ReactOS team will try to help on this soon. We have Mozilla almost loading and are still stalled on TCP support atm. Once we have this inplace we will be working with you guys on this. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 17, 2004

Re: Running Wine under MS SFU under Wine ... ?

by Steven Edwards

Hello Greg, --- "Gregory M. Turner" <gmturner007(a)ameritech.net> wrote: > I recently learned that SFU (3.5, at least) is actually a Windows > "subsystem," > which supposedly should mean that it is not a compatibility layer > like cygwin > implemented on top of the Windows API. Could be fun, I definitely > will give > it a whorl presently... I attempted a port of WINE to SFU a while back and it should work as well as the Cygwin port would once we get Get/SetThreadContext supported implemented for the Cygwin case. There were some issues I had at the time getting configure running with ksh and then with conflicing types in msvcrt. All in all there were no major showstoppers except the same problems as the Cygwin port which is time....... Thanks Steven PS. OpenNT the first incarnation of SFU/Interix was based on Cygwin. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Mike Hearn

On Sat, 17 Jan 2004 20:29:00 +0000, Jason Edmeades wrote: > I'd be worried this may cause more problems than it solves. Perhaps. I'd be willing to bet that virtually all (gui) win32 apps are tested by running it from explorer or the shell, which seems to use full paths though. So the fact that we usually run without a full path seems to be problematic. I guess there's a slight chance it could break apps designed to be run from the command line in Windows which might make similarly bad assumptions. Perhaps a config option, override-able in appdefaults, which controls passing the full path to the app - on by default. This leaves the question of where it gets the command line from, of course. If not argv[0], not WinMain, then where? I find it hard to believe the game does a TEB->PEB to get this, given that those structures are undocumented. > This is an > interesting one in that wine *does* correctly emulate windows behaviour, > but the app is broken to only expect a full path. Aside from an app > specific option (perhaps we could add in app specific config options > into a central compatibility ini file), I think the only way to capture > this is to document in eg. the appDB. I'm sure this would cause mighty flamewars but a compatability db we ship with Wine for obscure/broken/impossible-to-generalise apps might be an idea. Even Microsoft does this with their shims database. I'm not sure how else we're supposed to solve problems like IE setup trying to use a (broken/old) native advapi32, or issues like this where the app is broken but because of the fundamentally different nature of Windows it's never seen. The appdb isn't really suitable for this IMHO as it mixes up lots of different things - user talking, app rating: advice for running it could easily get buried and there is no way to remove old stuff. If there was a compatability db (perhaps a set of registry entries) it could be held in CVS and updated using patches. Feels messy, but if Windows does it we may have to anyway one day. thanks -mike

Jan. 17, 2004

Re: GetShortPathName broken

by Stefan Leichter

Am Samstag, 17. Januar 2004 18:40 schrieb Eric Pouech: > Stefan Leichter a écrit : > > Hello, > > > > The function GetShortPathName is broken in current cvs. This short > > program exhibits the problem: > > ------------------------------------ > > #include <stdio.h> > > #include <windows.h> > > #include <version.h> > > > > int main(int argc,char **argv[]) > > { char buffer[0x104] =""; > > DWORD retval; > > retval = GetShortPathName("C:\\Program Files", buffer, sizeof(buffer)); > > printf("%08x, %08x, %s\n", retval, GetLastError(), buffer ); > > > > return(0); > > } > > ----------------------------------------- > > On win2k and wine "2004-01-14 CST" i get > > 0000000b as retval and 00000000 from GetLastError() starting with wine > > "2004-01-14 18:21:00 CST" up to current cvs i get 00000000 for retavl > > and 00000002 from GetLastError(). > > > > So for my understanding the patch http://cvs.winehq.com/patch.py?id=10682 > > broke the function. > > does the C:\Program Files exist in your settings ? > I tried your small test here, and it return as expected (same values as > you describe for 2k). What you seem to have is the return value when the > directory 'Program Files' doesn't exist in your configuration, in which > case it returns an error (2 = ERROR_FILE_NOT_FOUND) > > A+ Thanks Eric, this was the right tip. My Problem is that i have two directories. The first one is "C:\Program Files" but the second one is C:\Programme. After i renamed (first character) the second one the test program works for me too. So what changed is the behavoir if two directories will match the short path. Sorry for the wrong error report Bye Stefan

Jan. 17, 2004

Re: Debugger doc pages

by Jason Edmeades

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

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Jason Edmeades

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

Jan. 17, 2004

Re: Problem with configure/config.cache

by Marcus Meissner

On Sat, Jan 17, 2004 at 04:49:09PM +0100, Dominik Strasser wrote: > Hi, > I am running into a problem, each time I rerun tools/wineinstall: > wineinstall calls configure; configure finds a valid config.cache. > On detction of the aRTS sound server it does the following: > if test "${ac_cv_c_artsserver+set}" = set; then > echo $ECHO_N "(cached) $ECHO_C" >&6 > else > # check for aRTS > ... > > so if configure is called repeatedly, the else clause is not executed. > But only in this else clause, ARTSC_CFLAGS and ARTSC_LIBS are set, which > results in an uncompilable wine alsa driver because ARTSLIBS and > ARTSINCL is set to those vars. > > Something similar happens in the detection of the asm keywords to be > used in the stabs generation. This is fine, the calculated string is saved in the cache. However the ICU detection was broken too. > I am not an autoconf guru, so I have no clue how to fix this. I am a bit of one, so here is a patch. Ciao, Marcus Changelog: Removed AC_CACHE_CHECK around checks with side effects. Index: configure.ac =================================================================== RCS file: /home/wine/wine/configure.ac,v retrieving revision 1.230 diff -u -r1.230 configure.ac --- configure.ac 15 Jan 2004 04:56:18 -0000 1.230 +++ configure.ac 17 Jan 2004 19:39:27 -0000 @@ -413,24 +413,24 @@ AC_SUBST(SANEINCL) dnl **** Check for the ICU library **** -AC_CHECK_HEADERS(unicode/ubidi.h) -if test "$ac_cv_header_unicode_ubidi_h" = "yes" -then - AC_CACHE_CHECK([whether we can statically link the ICU libraries], ac_cv_lib_icu, - [saved_libs="$LIBS" - ICU_LIB_DIR="${ICU_LIB_DIR-/usr/lib}" - ICUUC_LIB="${ICUUC_LIB-$ICU_LIB_DIR/libicuuc.a}" - ICUDATA_LIB="${ICUDATA_LIB-$ICU_LIB_DIR/libicudata.a}" - LIBS="$LIBS $ICUUC_LIB $ICUDATA_LIB -lstdc++ -lgcc_s" - AC_TRY_LINK([#include <unicode/ubidi.h>],[ubidi_open()], - [ac_cv_lib_icu="yes"],[ac_cv_lib_icu="no"]) - LIBS="$saved_libs"]) - if test "$ac_cv_lib_icu" = "yes" - then - AC_DEFINE(HAVE_ICU,1,[Define to 1 if the ICU libraries are installed]) - AC_SUBST(ICULIBS,"$ICUUC_LIB $ICUDATA_LIB -lstdc++ -lgcc_s") - fi -fi +AC_CHECK_HEADER(unicode/ubidi.h,[ + saved_libs="$LIBS" + + ICU_LIB_DIR="${ICU_LIB_DIR-/usr/lib}" + ICUUC_LIB="${ICUUC_LIB-$ICU_LIB_DIR/libicuuc.a}" + ICUDATA_LIB="${ICUDATA_LIB-$ICU_LIB_DIR/libicudata.a}" + LIBS="$LIBS $ICUUC_LIB $ICUDATA_LIB -lstdc++ -lgcc_s" + AC_TRY_LINK([ + #include <unicode/ubidi.h> + ],[ + ubidi_open() + ], [ + AC_DEFINE(HAVE_ICU,1,[Define to 1 if the ICU libraries are installed]) + AC_SUBST(ICULIBS,"$ICUUC_LIB $ICUDATA_LIB -lstdc++ -lgcc_s") + ] + ) + LIBS="$saved_libs" +]) dnl **** Check for FreeType 2 **** AC_CHECK_LIB(freetype,FT_Init_FreeType,ft_lib=yes,ft_lib=no,$X_LIBS) @@ -605,33 +605,24 @@ dnl **** Check for aRts Sound Server **** AC_PATH_PROG(ARTSCCONFIG, artsc-config) -AC_CACHE_CHECK([for aRts Sound server], - ac_cv_c_artsserver, - if test x$ARTSCCONFIG = x -o x$ARTSCCONFIG = x'"$ARTSCCONFIG"'; - then - ac_cv_c_artsserver=no - else - ARTSC_CFLAGS=`$ARTSCCONFIG --cflags` - ARTSC_LIBS=`$ARTSCCONFIG --libs` - ac_cv_c_artsserver=no - save_CFLAGS="$CFLAGS" - CFLAGS="$CFLAGS $ARTSC_CFLAGS" - AC_TRY_COMPILE([ - #include <artsc.h> - ],[ - arts_stream_t stream; - ],[ - ac_cv_c_artsserver=yes - ]) - CFLAGS="$save_CFLAGS" - fi) - -if test "$ac_cv_c_artsserver" = "yes" +if test x$ARTSCCONFIG != x -a x$ARTSCCONFIG != x'"$ARTSCCONFIG"'; then - AC_SUBST(ARTSLIBS, $ARTSC_LIBS) - AC_SUBST(ARTSINCL, $ARTSC_CFLAGS) + ARTSC_CFLAGS=`$ARTSCCONFIG --cflags` + ARTSC_LIBS=`$ARTSCCONFIG --libs` + save_CFLAGS="$CFLAGS" + CFLAGS="$CFLAGS $ARTSC_CFLAGS" + AC_TRY_COMPILE([ + #include <artsc.h> + ],[ + arts_stream_t stream; + ],[ + AC_SUBST(ARTSLIBS, $ARTSC_LIBS) + AC_SUBST(ARTSINCL, $ARTSC_CFLAGS) - AC_DEFINE(HAVE_ARTS, 1, [Define if you have ARTS sound server]) + AC_DEFINE(HAVE_ARTS, 1, [Define if you have ARTS sound server]) + ] + ) + CFLAGS="$save_CFLAGS" fi dnl **** Check for ALSA ****

Jan. 17, 2004

Re: Partial MDI rewrite

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > One thing I didn't understanding looking at the DC code was the USER lock. > Why does USER not use CRITICAL_SECTIONs like everywhere else, instead of > these syslevel things? Are there MSDN docs on this or is it a purely > internal thing? It's a Windows thing but I don't think it's documented. A syslevel is basically a critical section with checks to make sure you grab the locks in the right order. It's used for long lived locks like the Win16 or USER ones. -- Alexandre Julliard julliard(a)winehq.com

Jan. 17, 2004

Re: Implement LockWindowUpdate [take 3]

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > There was also talk some time ago to redo the visible region handling > through the server, but it seems other things took priority. This may > also fix bugs like this one: > > http://bugs.winehq.org/show_bug.cgi?id=1091 > > Alexandre, any news/plans on this front? The plan is still the same, I expect to begin working on that soon. -- Alexandre Julliard julliard(a)winehq.com

Jan. 17, 2004

Re: Implement LockWindowUpdate [take 3]

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > Is 'concerned' a technical term? I've not seen it in the Wine sources > before. If so, is there a function anywhere to calculate the concerned > DCs given a window? No it's not really a standard technical term. You need to walk the DCE list and check the window associated to each DCE to figure it out, something like what DCE_InvalidateDCE does. -- Alexandre Julliard julliard(a)winehq.com

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Mike Hearn

On Sat, 17 Jan 2004 15:00:55 +0100, Frank Schruefer wrote: > * Note that both Start Menu Execute and Explorer start programs with > * fully specified quoted app file paths, which is why probably the only case > * where you'll see single file names is in case of direct launch > * via CreateProcess or WinExec. Awwww crud. So basically the reason Keeper crashes is because it expects to be run from explorer? I wonder if it crashes on Windows if you run it from command.com in that directory, ie without a full path. I wonder if when a program is invoked directly from the wine loader app we should pretend it's been run from Explorer and pass it the full path. Alexandre, would that be an acceptable solution (subject to more thorough testing of course). thanks -mike

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Andreas Rosenberg

Frank Schruefer wrote: > But now what to do? > Suggestions? Shouldn't the WINE exe loader imitate the behavior of an application being started by the Explorer in Windows? I don't know if this is a possible solution, but this seems to be the most "compatible" one. I think the NT behavior is that a child process should get the command line, like it was provided by the parent process. To me it look's not correct to fix GetCommandLineA, but what's being passed to CreateProcess. This also the point, where you can decide if you are starting a Win32(s) or a Win16 application (and you can manipulate the commandline accordingly). If you add a config option that only changes the behavior of GetCommandLineA you would have a difference what you get as parameter for lpCmdLine via WinMain and what you get via GetCommandLineA! > * WARNING: there's a Windows incompatibility lurking here ! > * Win32s always includes the full path of the program file, Did anybody check if this is true if the process has been created with "CreateProcess" without a complete path. Does the Win32s layer in Win3.1 manipulate the commandline? Andy

Jan. 17, 2004

Re: Regression tests and Paul Millars WRT

by Paul Millar

Hi Mike, On Thu, 15 Jan 2004, Mike Hearn wrote: > 1) Firstly, to Paul - could you hook things up so that when we get new > red/purple builds an email is sent to wine-devel? Sure, that should be easy to add. It used to send emails automatically, but directly to me so I'd check them and forward the message if it was genuine. I didn't want to bombard wine-devel with worthless emails (like the bit below about web-proxies). > I just sent a patch to fix the http tests that started failing but I > wouldn't have seen it if it was not for your system. Ah, well, there might have been a bit of a problem there. Web access here at Glasgow is somewhat badly designed. The Powers That Be have enforced a web-proxy by redirecting all out-going web requests to a single page hosted by some dusty old 486. Normally, this allows the web tests to pass, as they don't check the content of the page, unfortunately this machine needing rebooting now and then. When I last asked, they monitor the machine's up, but not that apache is running, so someone has to yell before it gets fixed. Looks like that's what happened Friday morning. As a work-around, I had apache running on the build-machine, with iptables rewriting (almost) all outgoing web traffic to the local web-server. That stopped working after a kernel update (next to fix on TODO list), but I didn't notice, because whilst the 486 was up, everything looked like it was working. Your patch means its possible to change the target website, but I think it'd be better to keep the iptables rewrite, rather than to fiddle with the wine code. What do you think? > I think Alexandre runs the test suite before checking in each patch, but > it's still possible that there are ones he misses (like this). If it was > being done automatically perhaps AJ would not need to run the whole test > suite before each commit, so he could work faster as well (and > alexandre-cycles are waaaaay more valuable than cpu-cycles :) Hmmm... sure, alexandre-cycles are more valuable; but I don't think this should replace checks that he runs. The feedback, even with automatic emails, would take too long. > 2) Why is this not running on a WineHQ machine? Too expensive? Not needed? Too expensive? :^) The name of the build-machine was a joke with some friends. Originally, it was using machines that were being thrown out because they weren't powerful enough to run the latest Windows OS. Oh the irony! (its a much faster machine, now :) Originally, the web/SQL-server was just a handy machine with high(ish) available uptime and bandwidth with a friendly sysadmin who doesn't mind me running WRT. It could be hosted anywhere; the only restriction is the build-box (quisquiliae) talks mysql directly to the SQL server (which is also the web server). The web server also checks the build state by querying a port on quisquiliae. There's security issues about all this, so they're all behind various firewalls and firebridges. So, I'd be happier leaving things as-is, at least for now. > 3) Is the source to WRT available anywhere? I was tidying the code up before releasing it, mostly for vanity's sake :) Its pretty ugly, designed to get the job done ... but what the hell, its available here: http://www.astro.gla.ac.uk/users/paulm/Code/wrt-0.1.tar.gz Paul. ---- Paul Millar

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Duane Clark

Frank Schruefer wrote: > (REPOST, somehow this message yesterday didn't go through until now, strange! > Sorry if you may get it twice.) > You are not subscribed to the list as Frank.Schruefer(a)t-online.de, so your postings go through moderation.

Jan. 17, 2004

Re: Implement LockWindowUpdate [take 3]

by Dimitrie O. Paun

On January 17, 2004 09:19 am, Mike Hearn wrote: > At the moment the invalid region is stored in WND yes, and to implement > this properly it would have to be moved into the server and manipulated > using server RPCs? I'm not going to attempt this myself, just wondering > what it'd take (and maybe somebody will see this thread and write a > patch). There was also talk some time ago to redo the visible region handling through the server, but it seems other things took priority. This may also fix bugs like this one: http://bugs.winehq.org/show_bug.cgi?id=1091 Alexandre, any news/plans on this front? -- Dimi.

Jan. 17, 2004