TCL 8.3 installs?
Hello All, I was just wondering if anyone has had any troubles getting TCL 8.3 to install under Wine? I tried, but it froze up. I will try again tomorrow and hopefully be able to get some error messages to report to the group, ok. Cheers, Lonnie
Re: Internationalisation (bug #452)
Sylvain Petreolle <[EMAIL PROTECTED]> writes: > If we want to support the langage, we should put in > a new nls language description in dlls/kernel/winnls, > because no one exists for now. > do you agree with this or should we stop the support > for this language ? I suggest we just ignore it until someone who cares takes the trouble to make it work again. It's not like there is a huge public demand for that language -- Alexandre Julliard [EMAIL PROTECTED]
Re: Attn: component owners list
Dimi I would be very glad of help on common controls. I think "common controls" is big enough to keep both of us busy. I would recommend that we be co-owners of this part. Guy - Original Message - From: "Dimitrie O. Paun" <[EMAIL PROTECTED]> To: "Andriy Palamarchuk" <[EMAIL PROTECTED]>; "wine-devel" <[EMAIL PROTECTED]> Sent: Thursday, May 09, 2002 9:55 PM Subject: Re: Attn: component owners list > On May 9, 2002 01:28 pm, Andriy Palamarchuk wrote: > > * Dimitrie O. Paun - GUI > > Hey, I think that's a bit too ambitious for the time I have > available... Common controls would have been much better, > but those are taken by Guy now :) > > Anyhow, I'll be away for a while, I might sign up when I get back... > > -- > Dimi. > >
RE: Bug tracking organization
> "developer stuff" metabug > WineLib > winedbg > regression testing/test suite metabug > msvcrt, msvcrt20, crtdll > Misc. metabug (for other stuff) > twain, winaspi > "others" metabug (in order to deposit bug reports of > "alien" wine packages > here) > I would like to see the mingw/cygwin/ms_vc ports or a porting metabug under developer stuff. The DLL seperation in wine 1.0 is a dependancy the ReactOS project has. Only the dlls, programs and tools really matter for mingw and MS_VC so I think that can be reached for wine 1.0. I still want to do a cygwin port of wineserver But as long as dll seperation is done then it can wait till wine 1.x Thanks Steven
Re: wineinstall fails after cvs update
--- degs <[EMAIL PROTECTED]> wrote: > On Friday 10 May 2002 21:03, Andriy Palamarchuk > wrote: > > Hi Degs, > > > > --- degs <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I find tools/wineinstall frequently fails in > > > ./configure when trying to > > > rebuild Wine after a "cvs update". I only seem > to be > > > able to fix this by > > > blowing away the whole tree and re-fetching it > with > > > "cvs checkout". Is > > > wineinstall the Right Way to build Wine when one > is > > > trying to hack on it? > > > > Wineinstall not only installs wine, but also > > configures it. Usually you do not need to > reconfigure > > wine each time you refreshed source from CVS, so > > simply run in the Wine root dorectory: > > ./configure > > make depend > > make install > > > > or in one line: > > ./configure && make depend && make install > > > > "make install" will refresh the Wine binaries, but > > won't do anything with your existing > configuration. > > > > BTW, question about installation belongs to > > wine-users, look forward for your questions about > > hacking ;-) > Hi, > > Sorry I wasn't very clear - its not really a > wine-users question per se - I > want to be able to hack on Wine whilst keeping > up-to-date with the > cvs.winehq.com version and need to know how to build > it. I'm aware > wineinstall runs configure - its configure that > fails for me. It fails > regardless of whether I run configure manually or > through wineinstall so > wineinstall is probably a red herring. > > So, my question is: what is the correct way to > rebuild Wine after 'cvs update' > so that the configure *doesn't* fail? preferably > without having to blow away > the whole tree, re-check out and re-merge any > changes which I've made to it? > > I'm sure this must be a common problem but I can't > figure out how to get > around it - if anyone can tell me the right way to > do this it would be really > handly. > > BTW I know its not my changes to my local Wine tree > which break configure as > I've changed nothing in that area (I've only added > debug code to some bits of > GDI which are giving me jip) > > thanks > -- degs > are you downloading on windows and then copying over to linux? if so, you will probably need a tool like uxcook95, which fixes problems with files downloaded in ascii (windows' preferred method of storage, even for binary files), google search will probably bring up a few hits... -Dustin __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
Re: wineinstall fails after cvs update
On Fri, 10 May 2002, degs wrote: > Hi, > > I find tools/wineinstall frequently fails in ./configure when trying to > rebuild Wine after a "cvs update". I only seem to be able to fix this by > blowing away the whole tree and re-fetching it with "cvs checkout". Is > wineinstall the Right Way to build Wine when one is trying to hack on it? The only reason I can think of is that you changed something in configure.in and then regenerated the configure script. But then when you did the cvs update you got tons of conflicts in the configure script so it does not work anymore. The solution to this is to resolve any conflicts you may have in the configure.in file, and the run autoconf again to update the configure script. If that does not help, then you will have to tell us more about what configure says when it fails and possibly post the config.log file. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U
Re: Bug tracking organization
On Sat, 11 May 2002, Andreas Mohr wrote:
> Hi all,
>
> I think our bug tracking is still a bit too chaotic.
> Thus I intend to get some info on what bug tracking should look like.
>
> So far, we've got "Wine 0.9.0 TaskList" and "Wine 1.x WishList" as the
> two main metabugs.
>
> IMHO Wine 0.9.0 TaskList is the main bug for all development work up to
> Wine 1.0.
> And Wine 1.x WishList is everything that will definitely not be included
> in Wine 1.0 (and possibly even more).
>
> Now how about the layout of Wine 0.9.0 TaskList ?
Two comments:
* I think the proposed layout has way too many metabugs. It's easy to
deal with lists of at least up to 50 bugs. We don't want to have one
metabug for every 3 or 4 regular bug. So I don't think we need much in
the way of metabugs, especially in the 0.9.0 list. The only ones
currently are for the documentation (bug 75, and one per book:
77,78,79). These I inherited and while we could probably do with bug 75
and everything flat underneath I consider it unnecessary to reorganize.
The other one is for the dll separation work (bug 96, has 20 subbugs)
and bug 655 which you created.
* most of the tasks you propose are not on the list that we established
at WineConf 2002. To remain meaningful the 0.9.0 bug list should not
contain each and every known bug and task under the sun. We are not
going to fix them all before 0.9.0 or even before 1.0.
To refresh memories, here is the charter of the 0.9.0 release:
(from http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=35)
This is now a Meta Bug for 0.9.0 which will mark the start of our
progress to 1.0 as discussed at WineConf 2002:
* when the items in this list have been completed, we release 0.9.0
* at this point we should be ready to have increased user
participation for using, testing and documenting Wine.
* during 0.9.1, 0.9.2, etc. we do a progressive code freeze
* then when everything is frozen we release 1.0
* after 1.0.0 we will have stable and unstable branches
Note that Wine 0.9.0/1.0.0 does not mean that Wine
will run all Windows applications. It means that:
* Wine is ready for use by the general public for selected
applications
* that applications based on an old version of Wine/Winelib will
work with a new version of the Wine server.
* that the stable branches of Wine should not suffer major
regressions. An application that works in 1.0.x should work in
1.0.y if y>x.
Please correct me if you feel that the above does not reflect what was
discussed at WineConf2002.
Probably, most of the tasks you want to add in the 0.9.0 list could go
into the general tasklist, aka bug 395:
http://wine.codeweavers.com/bugzilla/showdependencytree.cgi?id=395
Now on to specific items:
[...]
> Presentation metabug
> Documentation
> Website
> Stable packaging (.deb, .rpm, .tar.gz)
This has been discussed multiple times and the conclusion was that
packaging is not really part of the core of Wine. However, if you know
of specific things to improve in the 'Wine Packagers Guide'
(http://www.winehq.com/Docs/wine-pkg/) then we could add these to the
general task list.
> programs metabug (what WineLib programs to supply ?)
I don't think we need a metabug for that. When we realize there is a
need to provide a specific application (such as regedit or regsvr32),
then all that is needed is to create a
[...]
> multimedia metabug
> dsound
> winmm
> directx (direct3d etc.)
> opengl
> video
These are good but should be in the general tasklist. You need to be
more specific though. E.g. what do you have in mind for winmm? Or rather
than just dsound we could list 3D DirectSound support. (but I guess you
did not want to expand too much in this list ;-)
One thing that would be useful is a description of what we need for
Direct3D support and what are the main tasks to get Direct3D support.
Another which would fall under the 'video' heading is adding support for
XVideo to DirectDraw.
[...]
> lowlevel metabug
> file system metabug
> registry
> profile
> lzexpand
> memory management metabug
> loader metabug
> PE
> NE
> DOS metabug
> comm metabug
> winsock
> wininet, icmp, url, urlmon, snmpapi, mapi32, netapi32
> serial
> TAPI
> "developer stuff" metabug
> WineLib
> winedbg
> regression testing/test suite metabug
> msvcrt, msvcrt20, crtdll
> Misc. metabug (for other stuff)
> twain, winaspi
> "others" metabug (in order to deposit bug reports of "alien" wine packages
> here)
Same thing for all of this. What we need is more specific items that
need to be fix with a good description of the work to do rather than 30+
empty metabugs.
--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
$live{free} || die "";
Re: wineinstall fails after cvs update
On Friday 10 May 2002 21:03, Andriy Palamarchuk wrote: > Hi Degs, > > --- degs <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I find tools/wineinstall frequently fails in > > ./configure when trying to > > rebuild Wine after a "cvs update". I only seem to be > > able to fix this by > > blowing away the whole tree and re-fetching it with > > "cvs checkout". Is > > wineinstall the Right Way to build Wine when one is > > trying to hack on it? > > Wineinstall not only installs wine, but also > configures it. Usually you do not need to reconfigure > wine each time you refreshed source from CVS, so > simply run in the Wine root dorectory: > ./configure > make depend > make install > > or in one line: > ./configure && make depend && make install > > "make install" will refresh the Wine binaries, but > won't do anything with your existing configuration. > > BTW, question about installation belongs to > wine-users, look forward for your questions about > hacking ;-) Hi, Sorry I wasn't very clear - its not really a wine-users question per se - I want to be able to hack on Wine whilst keeping up-to-date with the cvs.winehq.com version and need to know how to build it. I'm aware wineinstall runs configure - its configure that fails for me. It fails regardless of whether I run configure manually or through wineinstall so wineinstall is probably a red herring. So, my question is: what is the correct way to rebuild Wine after 'cvs update' so that the configure *doesn't* fail? preferably without having to blow away the whole tree, re-check out and re-merge any changes which I've made to it? I'm sure this must be a common problem but I can't figure out how to get around it - if anyone can tell me the right way to do this it would be really handly. BTW I know its not my changes to my local Wine tree which break configure as I've changed nothing in that area (I've only added debug code to some bits of GDI which are giving me jip) thanks -- degs > > Andriy Palamarchuk > > > __ > Do You Yahoo!? > Yahoo! Shopping - Mother's Day is May 12th! > http://shopping.yahoo.com
opengl rendering to the wrong window
Hello, I am trying to get the Neverwinter Nights Model viewer (http://www.bioware.com/games/neverwinter_nights/other_multimedia/model_viewer/) working under wine. The menus etc of the model viewer come up correctly, but no rendering can be seen in the render window. Through some investigation I determined that the model was being rendered, just in the wrong window. I moved the window out of the way by a few pixels and saw the model was being rendered to what looks like the main window underneath the menu. Here is a screen shot that shows what I mean. http://nwwine.beergeek.net/shots/nw_offset.jpg The black square is the windows shifted and the blue background is the glClearColor of the rendering window. As you can see the model is under the window :( Now if I move the window way offscreen and add an offset to the glViewport call I can get the model to render in the correct place, but this is obviously not the right solution. What could be causing it to be rendered in the wrong window? The render window has a hwnd =1003e and a drawable client/whole = 0x464/0x463 and the first couple of time through wglMakeCurrent the drawable that comes back from the hdc that is passed (requested from 1003e) is 0x464 which seems right, but I think this is some sort of test renderings offscreen before the application comes up. Later in the logs this is not true. GetDCEx is called with 1003e, but it returns a hdc that has a different drawable associated with it (the one for the root window I think). But even if I try to for the drawable to 0x464 is does not render in to the correct window (it does not render at all). Does anybody have any direction to point me in? Or is there any information that I could provide to make the situation more clear? Thanks! ryan
Bug tracking organization
Hi all, I think our bug tracking is still a bit too chaotic. Thus I intend to get some info on what bug tracking should look like. So far, we've got "Wine 0.9.0 TaskList" and "Wine 1.x WishList" as the two main metabugs. IMHO Wine 0.9.0 TaskList is the main bug for all development work up to Wine 1.0. And Wine 1.x WishList is everything that will definitely not be included in Wine 1.0 (and possibly even more). Now how about the layout of Wine 0.9.0 TaskList ? I'd suggest the following layout: 0.9.0 Presentation metabug Documentation Website Stable packaging (.deb, .rpm, .tar.gz) programs metabug (what WineLib programs to supply ?) GUI metabug window management metabug messaging metabug common controls metabug shell namespace fonts/printing metabug multimedia metabug dsound winmm directx (direct3d etc.) opengl video DLL separation metabug RPC/wineserver metabug OLE metabug (ok, not 100% correct, but main hole is DCOM RPC stuff) lowlevel metabug file system metabug registry profile lzexpand memory management metabug loader metabug PE NE DOS metabug comm metabug winsock wininet, icmp, url, urlmon, snmpapi, mapi32, netapi32 serial TAPI "developer stuff" metabug WineLib winedbg regression testing/test suite metabug msvcrt, msvcrt20, crtdll Misc. metabug (for other stuff) twain, winaspi "others" metabug (in order to deposit bug reports of "alien" wine packages here) Is this structure ok ? How should it be reorganized, what should be changed ? If we get to a final result, then I'll make sure the 0.9.0 bug gets to look like that. OK, on to the next topic: How should we organize the bug work ? We need tons of people to take UNCONFIRMED bugs and make sure that they reach enough quality in order to be reassigned as NEW (I expect ~ 30% of all bugs to get dropped right away). The second line of bug tracking would be experienced developers that are mainly responsible for certain areas (like we already started to discuss). There might even be a third line of "emergency" people for the really tough cases... BTW, I'm currently subscribed to wine-bugs. I guess I'll stay subscribed for a while, and once the initial bug tracking structure is solid and doesn't need special attention, I'll be able to concentrate on specific areas, and then I'll probably unsubscribe. Any comments ? -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.arcor.de/andi.mohr/
Re: Internationalisation (bug #452)
If we want to support the langage, we should put in a new nls language description in dlls/kernel/winnls, because no one exists for now. do you agree with this or should we stop the support for this language ? > In Windows terms I think Rumantsch should be > LANG_RHAETO_ROMANCE > (though this constant only appears in Wine headers > so I'm not sure if > that's an official Windows definition). The file is ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: FindFirstFile
In <[EMAIL PROTECTED]>, on 05/10/02 at 03:08 PM, "Dimitrie O. Paun" <[EMAIL PROTECTED]> said: :True. That was a bit strong. What about if filename starts with '.', :return Hidden = 1, else return Hidden = 0, and we ignore all requests to :modify the Hidden flag. What about if the physical file system is FAT, we support all of the flags just like Windows does. -- Chuck Crayne --- [EMAIL PROTECTED] ---
Re: wineinstall fails after cvs update
Hi Degs, --- degs <[EMAIL PROTECTED]> wrote: > Hi, > > I find tools/wineinstall frequently fails in > ./configure when trying to > rebuild Wine after a "cvs update". I only seem to be > able to fix this by > blowing away the whole tree and re-fetching it with > "cvs checkout". Is > wineinstall the Right Way to build Wine when one is > trying to hack on it? Wineinstall not only installs wine, but also configures it. Usually you do not need to reconfigure wine each time you refreshed source from CVS, so simply run in the Wine root dorectory: ./configure make depend make install or in one line: ./configure && make depend && make install "make install" will refresh the Wine binaries, but won't do anything with your existing configuration. BTW, question about installation belongs to wine-users, look forward for your questions about hacking ;-) Andriy Palamarchuk __ Do You Yahoo!? Yahoo! Shopping - Mother's Day is May 12th! http://shopping.yahoo.com
wineinstall fails after cvs update
Hi, I find tools/wineinstall frequently fails in ./configure when trying to rebuild Wine after a "cvs update". I only seem to be able to fix this by blowing away the whole tree and re-fetching it with "cvs checkout". Is wineinstall the Right Way to build Wine when one is trying to hack on it? thanks -- degs PS: I know hardly anything about autoconf (shudder) and absolutely *zero* about CVS :-(
Re: FindFirstFile
On May 9, 2002 01:50 am, Shachar Shemesh wrote: > > As for renaming hidden files to ".filename", that would break > compatibility if Windows use the same directory. True. That was a bit strong. What about if filename starts with '.', return Hidden = 1, else return Hidden = 0, and we ignore all requests to modify the Hidden flag. -- Dimi.
Re: PATCH: imaadp32.acm
Marcus Meissner a écrit : > > On Fri, May 10, 2002 at 07:57:16PM +0200, Marcus Meissner wrote: > > Hi, > > > > This implements an empty stub for DriverProc, until we have something here. > > (So we don't crash loading this driver.) > > Or better, just drop the whole thing. I have an IMA ADPCM ready for inclusion (with decoding and encoding ready). I may have time to send it tonight (with a ton of other stuff I have in my tree), so don't bother with this patch A+
Re: Regression in CreateDIBSection
David Hammerton wrote: > Hmm, > > Although that patch is correct, it seems that there is another bug - when > calling [Set|Get]DIBits we really should be locking the DIBSection so that it > coerces properly before the write/read. These use the DIBSection in GdiMod. > > This patch fixes it. > > David. > > Changelog: > - Lock/unlock (and hence maybe coerce) DIBSections into GdiMod during > the SetDIBits and GetDIBits functions, before actually accessing the X Pixmap. > > Licence: MIT/X11 > > Files affected: > graphics/x11drv/dib.c > > Patch Against: > ReWind CVS 10 may 2002 I confirm that's fixing BabyGammon. Thanks, Mehmet
Re: Breakthrough! Can now crosscompile unit tests!
> What I want is for the Wine configure to detect that > mingw32 > is present, then modify Makefiles so that when "make > tests" > is run, EXE-files are modified. > I also don't want to do #ifdef REAL_EXE or whatever > in every > c-file, I want all that to happen automagically in > wine/test.h ! > I want the configure script to take care of all that > and always > compile unit tests twice, once for linux target, > once for Windows > target. (EXE) You might be able to do ./configure --host=mingw --target=mingw --target=mingw under your cross system. Then in your configure script you can have a check that does something like this if case in host os = *mingw* Blah fi Where Blah is the change you need. I'm not very good at programming and even worse at fixing configure script/makefile bugs so I dont know what all you need to do. Take a look at the recent patch A.J. submitted that fixed my dlltool/wrap dlopen issues on cygwin/mingw. > Makefiles Alexandre is the one who know all about all, when ever I've had a makefile problem he has been very helpful. Steven __ Do You Yahoo!? Yahoo! Shopping - Mother's Day is May 12th! http://shopping.yahoo.com
Re: Breakthrough! Can now crosscompile unit tests!
On Fri, May 10, 2002 at 06:51:40AM -0700, Steven Edwards wrote: > > > > Ah, but of course! :-)I'm happy now! > > > > Now it works, at least for dlls/kernel/tests/file.c > > > > If you compile with: > > > > i586-mingw32msvc-gcc -o FILE.EXE -DREAL_EXE file.c > > > > If you have to do a #ifdef for the unit tests do the > generic _WINDOWS as this covers both the mingw and the > MSV_VC port. I dont know if this will give you trouble > when you go to cross compile wine/tools that have > #ifdef _WINDOWS but I use it on my mingw port. > I can now manually compile unit tests with "i586-mingw32msvc-gcc -o FILE.EXE -DREAL_EXE file.c" What I want is for the Wine configure to detect that mingw32 is present, then modify Makefiles so that when "make tests" is run, EXE-files are modified. I also don't want to do #ifdef REAL_EXE or whatever in every c-file, I want all that to happen automagically in wine/test.h ! I want the configure script to take care of all that and always compile unit tests twice, once for linux target, once for Windows target. (EXE) Then a .BAT file could easily be created that runs all the EXEs. Bang, native unit testing in a box! Challenge: I have very little clue about how Wines configure and Makefiles work. Who does? Who should I bug with questions? -- regards, Jakob Eriksson The wages of sin is debugging. -- Ron Jeffries
Re: Regression in CreateDIBSection
Hmm,
Although that patch is correct, it seems that there is another bug - when
calling [Set|Get]DIBits we really should be locking the DIBSection so that it
coerces properly before the write/read. These use the DIBSection in GdiMod.
This patch fixes it.
David.
Changelog:
- Lock/unlock (and hence maybe coerce) DIBSections into GdiMod during
the SetDIBits and GetDIBits functions, before actually accessing the X Pixmap.
Licence: MIT/X11
Files affected:
graphics/x11drv/dib.c
Patch Against:
ReWind CVS 10 may 2002
On Fri, 10 May 2002 17:22:43 +0200, Mehmet YASAR wrote:
| Hi,
|
| the following patch incorporated in CVS may 3rd has broken BabyGammon
| (you can get it at
| http://www.directfichiers.com/babygammon/BAFR100DOGT90.EXE )
|
| With it I have black background instead of the normal backgammon game.
| If somebody could look at this ...
|
| Mehmet YASAR
|
| Extract from logs :
|
| 08073078:Call
| user32.LoadImageA(0040,006a,,,,2000)
| ret=00407f17
| 08073078:Call
|
|x11drv.CreateDIBSection(403844f4,403bb334,,,,,)
|
| ret=407b4ac2
| trace:bitmap:X11DRV_DIB_CreateDIBSection format (114,19), planes 1, bpp
| 8, size 2204, colors 256 (RGB)
| 08073078:Call x11drv.GetDeviceCaps(403844f4,000c) ret=407b173b
| 08073078:Ret x11drv.GetDeviceCaps() retval=0010 ret=407b173b
| 08073078:Call x11drv.GetDeviceCaps(403844f4,000e) ret=407b173b
| 08073078:Ret x11drv.GetDeviceCaps() retval=0001 ret=407b173b
| trace:bitmap:CreateBitmap 114x19, 65536 colors returning 0870
| trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 4 to 4
| 08073078:Ret x11drv.CreateDIBSection() retval=0870 ret=407b4ac2
|
|
|
|
|
|
|
|
| --- Next Part ---
|
| Index: wine/graphics/x11drv/dib.c
| diff -u wine/graphics/x11drv/dib.c:1.91 wine/graphics/x11drv/dib.c:1.92
| --- wine/graphics/x11drv/dib.c:1.91 Wed Apr 24 16:32:11 2002
| +++ wine/graphics/x11drv/dib.c Sat May 4 13:32:48 2002
| @@ -5793,16 +5793,8 @@
| InitializeCriticalSection(&(dib->lock));
| if (VIRTUAL_SetFaultHandler(bm.bmBits, X11DRV_DIB_FaultHandler, (LPVOID)res))
| {
| - if (section || offset)
| -{
| - X11DRV_DIB_DoProtectDIBSection( bmp, PAGE_READWRITE );
| - if (dib) dib->status = DIB_Status_AppMod;
| -}
| - else
| -{
| - X11DRV_DIB_DoProtectDIBSection( bmp, PAGE_READONLY );
| - if (dib) dib->status = DIB_Status_InSync;
| -}
| + X11DRV_DIB_DoProtectDIBSection( bmp, PAGE_READWRITE );
| + if (dib) dib->status = DIB_Status_AppMod;
| }
| }
|
|
|
|
|
|
|
|
--
David Hammerton
programmer and support
TransGaming Technologies Inc.
http://www.transgaming.com
[EMAIL PROTECTED]
protectset.diff
Description: application/unknown
Re: wine/ ./configure ./configure.ac include/confi ...
On Fri, May 10, 2002 at 07:18:41AM -0700, Steven Edwards wrote: > I thought they were the same save this : > > The _snprintf vs. snprintf alternative seems to be > caused by conflicting standards: AFAIK Ansi/ISO C > requires all non-standard functions added > by the compiler to start with "_" , whereas POSIX > requires all its standard functions not to start with > "_". You are right. I misread what the patch does. Sorry. ciao Jörg -- Joerg Mayer <[EMAIL PROTECTED]> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
Regression in CreateDIBSection
Hi,
the following patch incorporated in CVS may 3rd has broken BabyGammon
(you can get it at
http://www.directfichiers.com/babygammon/BAFR100DOGT90.EXE )
With it I have black background instead of the normal backgammon game.
If somebody could look at this ...
Mehmet YASAR
Extract from logs :
08073078:Call
user32.LoadImageA(0040,006a,,,,2000)
ret=00407f17
08073078:Call
x11drv.CreateDIBSection(403844f4,403bb334,,,,,)
ret=407b4ac2
trace:bitmap:X11DRV_DIB_CreateDIBSection format (114,19), planes 1, bpp
8, size 2204, colors 256 (RGB)
08073078:Call x11drv.GetDeviceCaps(403844f4,000c) ret=407b173b
08073078:Ret x11drv.GetDeviceCaps() retval=0010 ret=407b173b
08073078:Call x11drv.GetDeviceCaps(403844f4,000e) ret=407b173b
08073078:Ret x11drv.GetDeviceCaps() retval=0001 ret=407b173b
trace:bitmap:CreateBitmap 114x19, 65536 colors returning 0870
trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 4 to 4
08073078:Ret x11drv.CreateDIBSection() retval=0870 ret=407b4ac2
Index: wine/graphics/x11drv/dib.c
diff -u wine/graphics/x11drv/dib.c:1.91 wine/graphics/x11drv/dib.c:1.92
--- wine/graphics/x11drv/dib.c:1.91 Wed Apr 24 16:32:11 2002
+++ wine/graphics/x11drv/dib.c Sat May 4 13:32:48 2002
@@ -5793,16 +5793,8 @@
InitializeCriticalSection(&(dib->lock));
if (VIRTUAL_SetFaultHandler(bm.bmBits, X11DRV_DIB_FaultHandler, (LPVOID)res))
{
- if (section || offset)
-{
- X11DRV_DIB_DoProtectDIBSection( bmp, PAGE_READWRITE );
- if (dib) dib->status = DIB_Status_AppMod;
-}
- else
-{
- X11DRV_DIB_DoProtectDIBSection( bmp, PAGE_READONLY );
- if (dib) dib->status = DIB_Status_InSync;
- }
+ X11DRV_DIB_DoProtectDIBSection( bmp, PAGE_READWRITE );
+ if (dib) dib->status = DIB_Status_AppMod;
}
}
Re: Breakthrough! Can now crosscompile unit tests!
> "Steven" == Steven Edwards <[EMAIL PROTECTED]> writes: Steven> If you have to do a #ifdef for the unit tests do the generic Steven> _WINDOWS as this covers both the mingw and the MSV_VC port. I Steven> dont know if this will give you trouble when you go to cross Steven> compile wine/tools that have #ifdef _WINDOWS but I use it on my Steven> mingw port. Retinking my last mail and reading Steven's mail, wouldn't be __WIN32__ and __WINE__ be the better choices to destinguish. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: wine/ ./configure ./configure.ac include/confi ...
> I'm afraid that this is the wrong solution to this > problem: > People using sNprintf do this sometimes for security > reasons. Just ignoring > the length is very likely to cause some problems > with applications that > would have been otherwise secure (I'm thinking of > chatclients etc). > snprintf should either be implemented or the > application simply should > not work, but making a secure app insecure is not > the way to go. I thought they were the same save this : The _snprintf vs. snprintf alternative seems to be caused by conflicting standards: AFAIK Ansi/ISO C requires all non-standard functions added by the compiler to start with "_" , whereas POSIX requires all its standard functions not to start with "_". __ Do You Yahoo!? Yahoo! Shopping - Mother's Day is May 12th! http://shopping.yahoo.com
Re: wine/ ./configure ./configure.ac include/confi ...
On Thu, May 09, 2002 at 08:33:41PM -0500, Alexandre Julliard wrote: > Log message: > Steven Edwards <[EMAIL PROTECTED]> > Detect snprintf && _snprintf, use _snprintf on stupid platforms > (windows). I'm afraid that this is the wrong solution to this problem: People using sNprintf do this sometimes for security reasons. Just ignoring the length is very likely to cause some problems with applications that would have been otherwise secure (I'm thinking of chatclients etc). snprintf should either be implemented or the application simply should not work, but making a secure app insecure is not the way to go. ciao Jörg -- Joerg Mayer <[EMAIL PROTECTED]> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
Re: Breakthrough! Can now crosscompile unit tests!
> "Jakob" == Jakob Eriksson <[EMAIL PROTECTED]> writes:
Jakob> On Thu, May 09, 2002 at 08:01:51PM -0400, Steven Edwards wrote:
Jakob> Ah, but of course! :-) I'm happy now!
Jakob> Now it works, at least for dlls/kernel/tests/file.c
Jakob> If you compile with:
Jakob> i586-mingw32msvc-gcc -o FILE.EXE -DREAL_EXE file.c
Jakob> The magic is the defines of ok, todo_wine and START_TEST.
Jakob> See this as proof of concept, I'm sure someone can make this look
Jakob> better.
Jakob> (If you have Debian 3.0, just "apt-get install mingw32-runtime
Jakob> mingw32".)
Jakob> How do I make this happen automagically when doing "make tests"?
You can test for __MINGW32__, __CYGWIN__ or __linux in your source:
#include
int main(void)
{
#ifdef __linux
printf("compiled on linux\n");
#endif
#ifdef __MINGW32__
printf("compiled with mingw\n");
#endif
return 0;
}
> gcc test.c
> ./a.out
compiled on linux
> i386-mingw32msvc-gcc test.c
> wine a.exe
compiled with mingw
Something like "make GCC=i586-mingw32msvc-gcc" (not sure about the syntax)
exchanges gcc against i586-mingw32msvc-gcc in well written Makefiles.
Are there any recent mingw rpm packages for linux?
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Re: Breakthrough! Can now crosscompile unit tests!
--- Jakob Eriksson <[EMAIL PROTECTED]> wrote: > On Thu, May 09, 2002 at 08:01:51PM -0400, Steven > Edwards wrote: > > > jakov@black:/tmp> > > > jakov@black:/tmp> i586-mingw32msvc-gcc file.c > > > > /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mi > > > ngw32msvc/lib/libmingw32.a(main.o)(.text+0x8f): > undefined > > > reference to `WinMain@16' > > > > There is no main statement in file.c > > > Ah, but of course! :-)I'm happy now! > > Now it works, at least for dlls/kernel/tests/file.c > > If you compile with: > > i586-mingw32msvc-gcc -o FILE.EXE -DREAL_EXE file.c > If you have to do a #ifdef for the unit tests do the generic _WINDOWS as this covers both the mingw and the MSV_VC port. I dont know if this will give you trouble when you go to cross compile wine/tools that have #ifdef _WINDOWS but I use it on my mingw port. __ Do You Yahoo!? Yahoo! Shopping - Mother's Day is May 12th! http://shopping.yahoo.com
Breakthrough! Can now crosscompile unit tests!
On Thu, May 09, 2002 at 08:01:51PM -0400, Steven Edwards wrote:
> > jakov@black:/tmp>
> > jakov@black:/tmp> i586-mingw32msvc-gcc file.c
> > /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mi
> > ngw32msvc/lib/libmingw32.a(main.o)(.text+0x8f): undefined
> > reference to `WinMain@16'
>
> There is no main statement in file.c
Ah, but of course! :-)I'm happy now!
Now it works, at least for dlls/kernel/tests/file.c
If you compile with:
i586-mingw32msvc-gcc -o FILE.EXE -DREAL_EXE file.c
The magic is the defines of ok, todo_wine and START_TEST.
See this as proof of concept, I'm sure someone can make this
look better.
(If you have Debian 3.0, just "apt-get install mingw32-runtime mingw32".)
How do I make this happen automagically when doing "make tests"?
#ifndef REAL_EXE
#include "winbase.h"
#include "winerror.h"
#include "wine/test.h"
#else
#include
#include
#define ok(val, msg) {if (!(val)) {printf ("%s\n", msg);} }
#define todo_wine
#define START_TEST main
#endif /* REAL_EXE */
#include
#include
LPCSTR filename = "testfile.xxx";
LPCSTR sillytext =
"en larvig liten text dx \033 gx hej 84 hej 4484 ! \001\033 bla bl\na.. bla bla."
"1234 43 4kljf lf &%%%&& 34 4 34 3# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&& 34 4 34 3# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&& 34 4 34 3# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&& 34 4 34 3# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&& 34 4 34 3# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&& 34 4 34 3# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&& 34 4 34 3# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&& 34 4 34 3# 33 3 3 3 # 3## 3"
"sdlkfjasdlkfj a dslkj adsklf \n \nasdklf askldfa sdlkf \nsadklf asdklf asdf ";
static void test__lcreat( void )
{
HFILE filehandle;
char buffer[1];
WIN32_FIND_DATAA search_results;
filehandle = _lcreat( filename, 0 );
ok( HFILE_ERROR != filehandle, "couldn't create file. Wrong permissions on
directory?" );
ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite
complains." );
ok( 0 == _llseek( filehandle, 0, FILE_BEGIN ), "_llseek complains." );
ok( _hread( filehandle, buffer, strlen( sillytext ) ) == strlen( sillytext ),
"erratic _hread return value." );
ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );
ok( INVALID_HANDLE_VALUE != FindFirstFileA( filename, &search_results ), "should
be able to find file" );
ok( DeleteFileA( filename ) != 0, "DeleteFileA complains." );
filehandle = _lcreat( filename, 1 );
ok( HFILE_ERROR != filehandle, "couldn't create file!?" );
ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite
shouldn't be able to write never the less." );
ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );
ok( INVALID_HANDLE_VALUE != FindFirstFileA( filename, &search_results ), "should
be able to find file" );
ok( DeleteFileA( filename ) != 0, "DeleteFileA complains." );
filehandle = _lcreat( filename, 2 );
ok( HFILE_ERROR != filehandle, "couldn't create file. Wrong permissions on
directory?" );
ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite
complains." );
ok( 0 == _llseek( filehandle, 0, FILE_BEGIN ), "_llseek complains." );
ok( _hread( filehandle, buffer, strlen( sillytext ) ) == strlen( sillytext ),
"erratic _hread return value." );
ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );
todo_wine
{
ok( INVALID_HANDLE_VALUE == FindFirstFileA( filename, &search_results ),
"should NOT be able to find file" );
}
ok( DeleteFileA( filename ) != 0, "DeleteFileA complains." );
filehandle = _lcreat( filename, 4 ); /* SYSTEM file */
ok( HFILE_ERROR != filehandle, "couldn't create file. Wrong permissions on
directory?" );
ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite
complains." );
ok( 0 == _llseek( filehandle, 0, FILE_BEGIN ), "_llseek complains." );
ok( _hread( filehandle, buffer, strlen( sillytext ) ) == strlen( sillytext ),
"erratic _hread return value." );
ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );
todo_wine
{
ok( INVALID_HANDLE_VALUE == FindFirstFileA( filename, &search_results ),
"should NOT be able to find file" );
}
ok( DeleteFileA( filename ) != 0, "DeleteFileA complains." );
}
void test__llseek( void )
{
INT i;
HFILE filehandle;
char buffer[1];
long bytes_read;
filehandle = _lcreat( filename, 0 );
ok( HFILE_ERROR != filehandle, "couldn't create file. Wrong permissions on
directory?" );
for (i = 0; i < 400; i++)
{
ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ),
"_hwrite complains." );
}
ok(
Re: Request For Comments: emulation of Windows file attributes on POSIX
On Fri, 10 May 2002 00:03:12 +0200 Jakob Eriksson > wrote: > > I filed a bug that comments Wine can't create a HIDDEN file, > so that Wine does not later find it with FindFirstFile(). > http://bugs.winehq.com/show_bug.cgi?id=660 > there was a little discussion there and I suggested > a) a mode where Wine reads the special info from VFAT and NTFS filesystems. > (linux kernel enhancement probably necessary) > b) for POSIX filesystems, an emulation layer where Wine emulates the > attributes by storing them in a special file in each directory. > Andriy Palamarchuk commented with this: > There are plans on integration with Samba and this functionality can be > implemented there for communication with Windows machines. > However, I can't decide whether it is worth to implement these features for > Posix file system. > I suggest you to discuss the matter on wine-devel. > Is it worth it at all? > Is it worth it if I implement it as a Wine learning exercise and all you Wine > demigods have to do is either say "ok" or "bad, to slow, let's ditch it" or whatever. > I don't understand that about Samba integration. Can they read the > special attributes on VFAT and NTFS? Are they planning to emulate it? I don't know to what extent others on the list have been tracking filesystem development in Linux or any other *nix, so this may be well known to some. I've been looking at it from several respects, one of which was linking ACLs to filesystem ACLs. In the Linux area SGI's XFS filesystem already supports ACLs. Work is under way integrating this with Samba ACLs and the ext3 work being done by Andreas Grunbacher. JFS does not yet support ACLs in it's Linux incarnation but the work is on the 'todo' list. I have no knowledge of the situation wrt ReiserFS. I mention this because part of the XFS implementation includes storage of extended attributes in a form that could be used by products such as Wine. AFAIK this does not apply to the other filesystem types although JFS with its O/S 2 background either should or should not present much difficulty to the addition. EAs would certainly be a way of handling the 'DOS' type attributes that could not be mapped onto normal Unix attributes. Part of the work involves producing suitable utilities to correctly handle the EAs along with the files they relate to. Clearly tying Wine in to one f/s type is not a practical option, but some work in that area by those on the periphery of the project might fill in the holes in such a way as to resolve issues on all f/s types (for Linux and other platforms). -- Keith Matthews Frequentous Consultants - Linux Services, Oracle development & database administration
Re: Attn: component owners list
On Thu, May 09, 2002 at 10:28:38AM -0700, Andriy Palamarchuk wrote: > * Huw Davies - TrueType support, printing Works for me. > Available components: > * gdi You can put me down for this too if you like. Huw.
