wine-devel March 2003

wine-devel@winehq.org

109 participants
285 discussions

Re: Resend of the Fix for ArrangeCtrlPositions in commdlg
by Mike McCormack 19 Mar '03

19 Mar '03

Hi, This patch does badly with Visio 2000's file Open dialog. The file dialog is as big as the main window, but the OK button is placed in the middle of the dialog, more or less. (It should be at the bottom RHS). I can send you a screenshot if you'd like. Mike Maxime Bellengé wrote: > As requested by Alexandre, I send the patch with more comments. > > I have made several test cases under windows and taken screenshot to > compare with wine. If someone is interested in seeing them, send me a > mail. > > ChangeLog: > - Fix how the size of the dialog is computed and the child component > placed. > > > > ------------------------------------------------------------------------ > > Index: dlls/commdlg/filedlg95.c > =================================================================== > RCS file: /home/wine/wine/dlls/commdlg/filedlg95.c,v > retrieving revision 1.90 > diff -u -r1.90 filedlg95.c > --- dlls/commdlg/filedlg95.c 7 Mar 2003 20:29:31 -0000 1.90

2 3

Re: wine/loader module.c
by Eric Pouech 19 Mar '03

19 Mar '03

Alexandre Julliard wrote: > Modified files: > loader : module.c > > Log message: > Make GetModuleFileNameA call GetModuleFileNameW. Small cleanups. the cleanups are wrong... for example the following code: char c[5]; DWORD len; len = GetModuleFileNameA(0, c, 4); c[4] = '\0'; printf("len is %d/%d\n", len, strlen(c)); gives "len is 4/4" on W2K, while we get "len is 3/3" on wine when the buffer is too small, GetModuleFileName doesn't put the terminating '\0' to the string, while wine does (and my patch didn't) (and yes I do have a test sample, but that I haven't finished it yet) A+ -- Eric Pouech

2 4

wine and services ..
by Lars Segerlund 19 Mar '03

19 Mar '03

I have asked a before about NT services, and about the support for them in wine, does wine have any support for NT services ? I'm getting errors on some code which I have written for NT and it runs on NT 2k xp , and it seem's that there is no support for services. If I wanted to get started on an implementation, how difficult and where would I look ? It seem's that wined should be able to handle stuff like this ? / regards, Lars Segerlund.

2 1

Re: TreeView notifications fix (take 2)
by Dimitrie O. Paun 19 Mar '03

19 Mar '03

On March 19, 2003 09:08 am, Mike Hearn wrote: > As per Dimis suggestion, here is a more streamlined version of the > patch. > > ChangeLog: > > - Make IsWindowUnicode check dialog wndprocs Excellent! Now, in the light of this new finding, we have to reasses the listview situation. Did you get a chance to rerun Drew's tests for the listview? -- Dimi.

2 1

Re: TreeView notifications fix
by Dmitry Timoshkov 19 Mar '03

19 Mar '03

"Mike Hearn" <mike(a)theoretic.com> wrote: > ChangeLog: > - Make the change notifications respect unicode vs ansi. > - TVN_SELCHANGINGW, > + infoPtr->bNtfUnicode ? TVN_SELCHANGINGA : TVN_SELCHANGINGW, Shouldn't this be reversed? -- Dmitry.

5 12

[RFC] windres' -I option
by Dimitrie O. Paun 19 Mar '03

19 Mar '03

Hi folks, For the past few month, I've been working on having better interoperability between MinGW, and Wine (http://www.winehq.org). By this I mean the ability to maintain a single build system capable of building apps for either environment. Needless to say, this is a worthy goal, as it allows Windows-only apps to seamlessly build as Linux-native apps. This is a complex problem, but for the purpose of this email I will only focus on windres. As you probably already know, the Wine project has it's own resource compiler (wrc). For obvious reasons, it is quite desirable to have wrc and windres be command line compatible. To this end, I've modified wrc to the point where we support all but *one* of windres' options: -I. This option is used in windres to specify the input format, while in wrc it's used to specify include directories. The wrc semantics has a lot on it's side: it is the de-facto standard in the Unix world for specifying include dirs, and it is even compatible with MS's rc. Given the overwhelming inclination to use -I as an include dir specifier, I think it would be better if we could align windres to this standard. My proposal is simple: rename -I to something else (I suggest -J), and introduce -I as a synonym for --include-dir. Now, I realize this is a controversial change -- what about backwards compatibility? Luckily, the situation is not as bad as it might seem. Firstly, this option does not seem to be used all that often in practice. Second, the nature of the option allows for a simple scheme. That is, with -I now used for include directories, we can try to match the 3 possible old values (res, rc, coff). If they match, we consider it a input format specifier, issue a deprecation warning, and behave in the old fashion. Otherwise, consider the input an include directory. But what if one want to specify 'res' or 'coff' as an include dir? Well, apart from the fact that this is _very_ unlikely, all they have to do is to prefix those values with './': that is ./res or ./coff. But I guess this is already too much talk and too little action. Here is a patch that implements the above, and updates the documentation. ChangeLog Rename the -I option to -J. Introduce -I as synonym for --include-dir. Index: binutils/windres.c =================================================================== RCS file: /cvs/src/src/binutils/windres.c,v retrieving revision 1.13 diff -u -r1.13 windres.c --- binutils/windres.c 5 May 2002 23:25:27 -0000 1.13 +++ binutils/windres.c 17 Mar 2003 07:14:16 -0000 @@ -110,8 +110,7 @@ #define OPTION_DEFINE 150 #define OPTION_HELP (OPTION_DEFINE + 1) -#define OPTION_INCLUDE_DIR (OPTION_HELP + 1) -#define OPTION_LANGUAGE (OPTION_INCLUDE_DIR + 1) +#define OPTION_LANGUAGE (OPTION_HELP + 1) #define OPTION_PREPROCESSOR (OPTION_LANGUAGE + 1) #define OPTION_USE_TEMP_FILE (OPTION_PREPROCESSOR + 1) #define OPTION_NO_USE_TEMP_FILE (OPTION_USE_TEMP_FILE + 1) @@ -122,8 +121,8 @@ { {"define", required_argument, 0, OPTION_DEFINE}, {"help", no_argument, 0, OPTION_HELP}, - {"include-dir", required_argument, 0, OPTION_INCLUDE_DIR}, - {"input-format", required_argument, 0, 'I'}, + {"include-dir", required_argument, 0, 'I'}, + {"input-format", required_argument, 0, 'J'}, {"language", required_argument, 0, OPTION_LANGUAGE}, {"output-format", required_argument, 0, 'O'}, {"preprocessor", required_argument, 0, OPTION_PREPROCESSOR}, @@ -140,7 +139,7 @@ static void res_init PARAMS ((void)); static int extended_menuitems PARAMS ((const struct menuitem *)); -static enum res_format format_from_name PARAMS ((const char *)); +static enum res_format format_from_name PARAMS ((const char *, int)); static enum res_format format_from_filename PARAMS ((const char *, int)); static void usage PARAMS ((FILE *, int)); static int cmp_res_entry PARAMS ((const PTR, const PTR)); @@ -588,7 +587,7 @@ /* Convert a string to a format type, or exit if it can't be done. */ static enum res_format -format_from_name (name) +format_from_name (name, int exit_on_error) const char *name; { const struct format_map *m; @@ -597,7 +596,7 @@ if (strcasecmp (m->name, name) == 0) break; - if (m->name == NULL) + if (m->name == NULL && exit_on_error) { non_fatal (_("unknown format type `%s'"), name); fprintf (stderr, _("%s: supported formats:"), program_name); @@ -779,6 +778,7 @@ char *input_filename; char *output_filename; enum res_format input_format; + enum res_format input_format_tmp; enum res_format output_format; char *target; char *preprocessor; @@ -828,12 +828,12 @@ output_filename = optarg; break; - case 'I': - input_format = format_from_name (optarg); + case 'J': + input_format = format_from_name (optarg, 1); break; case 'O': - output_format = format_from_name (optarg); + output_format = format_from_name (optarg, 1); break; case 'F': @@ -868,7 +868,16 @@ verbose ++; break; - case OPTION_INCLUDE_DIR: + case 'I': + /* for backward compatibility, should be removed in the future */ + input_format_tmp = format_from_name (optarg, 0); + if (input_format_tmp != RES_FORMAT_UNKNOWN) + { + fprintf (stderr, _("Option -I is deprecated for setting the input format, please use -J instead.\n")); + input_format = input_format_tmp; + break; + } + if (preprocargs == NULL) { quotedarg = quot (optarg); Index: binutils/doc/binutils.texi =================================================================== RCS file: /cvs/src/src/binutils/doc/binutils.texi,v retrieving revision 1.30 diff -u -r1.30 binutils.texi --- binutils/doc/binutils.texi 24 Feb 2003 16:20:28 -0000 1.30 +++ binutils/doc/binutils.texi 17 Mar 2003 07:14:22 -0000 @@ -2569,7 +2569,7 @@ non-option argument, then @command{windres} will write to standard output. @command{windres} can not write a COFF file to standard output. -@item -I @var{format} +@item -J @var{format} @itemx --input-format @var{format} The input format to read. @var{format} may be @samp{res}, @samp{rc}, or @samp{coff}. If no input format is specified, @command{windres} will @@ -2597,6 +2597,7 @@ to use, including any leading arguments. The default preprocessor argument is @code{gcc -E -xc-header -DRC_INVOKED}. +@item -I @var{directory} @item --include-dir @var{directory} Specify an include directory to use when reading an @code{rc} file. @command{windres} will pass this to the preprocessor as an @option{-I} -- Dimi.

1 0

Re: Wine crashes and floods shell with garbage
by Vilppa Salt 19 Mar '03

19 Mar '03

>Anyone else has this problem? > >[mrok@mrok cdrom]# wine setup >[mrok@mrok cdrom]# fixme:ntdll:MODULE_AllocModRef Trying to load second >.EXE >file: E:AutoRun.exe >fixme:ntdll:MODULE_AllocModRef Trying to load second .EXE file: >E:AutoRun.exe >fixme:ntdll:MODULE_AllocModRef Trying to load second .EXE file: >E:AutoRun.exe >@wine client error:0: T++Â€B `BÃ@ >`BfBÅÃœh@3ÅŒ@#Ã€Ãœh@+Å3ÅŒ >@wine client error:0: T++Â€B `BÃ@ >`BfBÅÃ«h@3ÅŒ @?@#ÄÃ«h@+Å3ÅŒ >@wine client error:0: T++Â€B `BÃ@ >`BfBÄÅ®h@3ÅŒ @?@#ÂŽÅ®h@+Å3ÅŒ >@wine client error:0: T++Â€B `BÃ@ >`BfBÂ°Ãh@3ÅŒ @?@#Ãh@+Å3ÅŒ >@wine client error:0: T++Â€B `BÃ@ >`BfBÂµh@3ÅŒ @?@#Âµh@+Å3ÅŒ >@wine client error:0: T++Â€B `BÃ@ >`BfBÅh@3ÅŒ @?@#lÅh@+Å3ÅŒ >@wine client error:0: T++Â€B `BÃ@ >`BfBhh@3ÅŒ @?@#Th@+Å3ÅŒ >@wine client error:0: T++Â€B `BÃ@ >`BfBPh@3ÅŒ @?@#<h@+Å3ÅŒ >@wine client error:0: T++Â€B `BÃ@ >`BfB8mh@3ÅŒ @?@#$mh@+Å3ÅŒ >@wine client error:0: T++Â€B `BÃ@ `BfB >[h@3ÅŒ @?@#[h@+Å3ÅŒ >@wine client error:0: T++Â€B `BÃ@ >`BfIh@3ÅŒ @? @#ÃŽHh@+Å3ÅŒ >... > >Looks like this happens when wine tries to run another process. Any >ideas >how to fix it? Yes, I've had it. When trying to run Tribes 2 PC version that happens. I also think that it is because .exe tries to launch another exe file. When running "wine SIERRAUP.EXE" the program checks for updates from a web site and then tries to launch "tribes2.exe -online" and crashes with similar symptoms. Those errors always begin with T++ and after that comes some random garbage. No ideas how to fix it. --- Vilppa- Sunpoint.net ilmoittaa: Sunpoint.net tarjoaa kaikille rekisteröityneille käyttäjilleen kuukausimaksuttoman Internet -yhteyden (pvm). http://www.sunpoint.net/SunAds/click.htm?mode=footer&id=71&jump=http%3A%2F%…

1 0

Re: wine/tools/winebuild winebuild.man.in utils.c ...
by Dimitrie O. Paun 18 Mar '03

18 Mar '03

On March 18, 2003 12:30 am, Alexandre Julliard wrote: > [...] also to make specification of an entry point link name optional. Yay! Does this mean that we can transform entries that are of the form ... X(...) X to just ... X(...) ? :) -- Dimi.

3 3

Re: Fwd: Test Header
by Alexandre Julliard 18 Mar '03

18 Mar '03

Jon <jon_p_griffiths(a)yahoo.com> writes: > Finally, all references to stdout have been removed - this allows the tests > to be built with msvcrt or libc and work. This in turn allows developers to > check that c library differences (e.g. printf formatting) won't affect the > test results, without rebooting to rebuild/re-run the tests under native > windows. It also means you can manually call _chkstk when implementing > undocumented calls to ensure that you have the parameters and calling > convention correct (a coming patch implements this function for builtin > msvcrt). > > Note we have to define __NO_INLINE__ when we make the tests, since otherwise > our non-stdout referencing calls get mapped straight back to referencing > stdout by the glibc headers, and msvcrt will blow up trying to write to a non > existant fd. This is wrong; if you link with msvcrt you have to use msvcrt headers, and then everything works fine, including references to stdout. If you mix glibc and msvcrt you are in trouble. -- Alexandre Julliard julliard(a)winehq.com

3 4

Re: Open Source MFC Replacement WRT Wine?
by thomas.mertes＠gmx.at 18 Mar '03

18 Mar '03

On Wed, 18 Oct 2000, Francois Gouget wrote: > On Wed, 18 Oct 2000, Andrew Lynch wrote: > > > As seen on SourceForge: > > > > "The Open Foundation Classes (OFC) are a frameset of > [...] > > http://sourceforge.net/projects/ofc/ > [...] > > This project could potentially solve that problem by > > replacing MFC with a open source/free equivalent. > > > > Has anyone heard anything further on this? > > > > Opinions? Comments? Discussion? > > I went to their web site on SourceForge and AFAICS there's not much: > nothing in CVS, no released files, no bug reports. It looks like they > are just starting up so it is understandable. I wish them well. > > If their project does take off I think we should provide them with > the necessary support so that it compiles out of the box with Winelib. > Then maybe some of the Wine folks could be interested in contributing > but that's up for individual developpers to decide. > > But first: > Show me the (at least some) code! I looked there, and found some code (just a little bit, but at least some code). If you are wondering: I checked Google for "open source MFC", found this mail and checked the link (http://sourceforge.net/projects/ofc/). After that I could not resist replying to this mail. I don't know, if there is developing activity going on in the OFC project. The last check in is 5 Months ago. But I think now is the time for First Contact (C). Greetings Thomas Mertes -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
29
Older →

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 March 2003