Re: Status of wine development
On Tuesday 19 December 2006 08:11, Edward Savage wrote: > The next issue of WWN is around half done and will most likely be submitted > for the end of this week. Great, thanks for picking this up. I remember WWN being incredibly helpful when I got started with Wine. > Also more worrying is that I can't think of a good quip to put at the start > of the news letter! I guess this is a matter of practice. I'd suggest bugging Brian to let you in on the secret of witty remarks for Wine Weekly News (WRWWN). Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpzRygXkUs4R.pgp Description: PGP signature
Re: Status of wine development
The next issue of WWN is around half done and will most likely be submitted for the end of this week. It will focus on the major changes since the last issue and the work being done in d3dx. The problem has mainly been the size of wine and how many people there are working on it. Catching up on threads of discussion and the like takes a lot of caching of the wine-devel list and tracking people down to ask questions to get a grasp of that area of development is tricky. Expect the rate at which I am able to send in an edition to increase drastically once the first one is out. Also more worrying is that I can't think of a good quip to put at the start of the news letter! Edward On 12/19/06, Kai Blin <[EMAIL PROTECTED]> wrote: Well, there was somebody offering to pick up on Wine Weekly News, wonder what happened to that. Also, I'd disagree that minor releases aren't front-page news. There's usually a significant change in features (and bugs) in every release. :) Cheers, Kai
Re: Status of wine development
On 12/18/06, Remco <[EMAIL PROTECTED]> wrote: So, what's the status/news of DX10? DX in general? See : http://wiki.winehq.org/DirectX-ToDo That ToDo is up to date as far as I know, DX10 = 0% completeness. If anyone is aware of something in need of change on the DX-ToDo please fix it or let me know and ill update the page. Happy Holidays Tom
Re: Running winetest on Vista
On 18.12.2006 16:50, Dmitry Timoshkov wrote:
> Well, a manifest is just an text (.xml) file with the resource type set
> to RT_MANIFEST. Adding it into the resources is easy, the problem is that
> wrc doesn't support that kind of a resource, so that support should be
> added to wrc first.
RT_MANIFEST is 24. Adding a resource of type 24, ID 1, should suffice;
no special handling in wrc should be needed.
E.g.:
1 24 "myapplication.manifest"
or:
1 24
{
""
}
f-r-
Re: Status of wine development
On Tuesday 19 December 2006 00:27, Remco wrote: > I ask it consisely, but maybe the answers could be posted as a news item > on WineHQ. It would be great for Wine to get some exposure on tech sites > from time to time. That requires some actual news (new minor releases > aren't front-page news after all). Well, there was somebody offering to pick up on Wine Weekly News, wonder what happened to that. Also, I'd disagree that minor releases aren't front-page news. There's usually a significant change in features (and bugs) in every release. :) > So, what's the status/news of DX10? DX in general? the Mac-port? Wine 1.0? > What's the status of anything else that has been a major thing last year? I think the DX work is focusing on DX9 so far, and probably will stay like that for a while. Maybe some of the D3D people can fill in on the details. We're also working on getting DInput to be less broken, and someone in IRC seemed interested in DMusic, which could really need some love. We've ironed out almost all the bugs for running native DPlay, and I'm still working on figuring out that protocol. I expect this to take a while, though. As I don't own an Intel Mac, I can't tell you much about the Mac port. It should work ok in X, the quartz driver is still pretty stubbed out for all I know (correct me if I'm wrong). Wine 1.0 is due to be out in 6-18 months, as it's been the last 14 years. Actually, all kidding aside, we might see something in that direction once the D3D development stabilizes. How long that'll take, well... That's been my impression from reading the mailing list, people working on the single areas might know more specific things, so please correct me if this is all wrong. :) Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgp6OP1R31a2x.pgp Description: PGP signature
Status of wine development
I ask it consisely, but maybe the answers could be posted as a news item on WineHQ. It would be great for Wine to get some exposure on tech sites from time to time. That requires some actual news (new minor releases aren't front-page news after all). So, what's the status/news of DX10? DX in general? the Mac-port? Wine 1.0? What's the status of anything else that has been a major thing last year? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
STLPort 5.1 and winegcc / winelib
I was wondering if anyone had tried STLPort 5 with winelib. From searching the archives it seems you need to swap out gcc/c++ for winegcc/wineg++ and pass the -mno-cygwin option. Doing that gives me these errors. make -f gcc.mak all wineg++ -pthread -mno-cygwin -fexceptions -fident -fPIC -O2 -fuse-cxa-atexit -D_REENTRANT -D_GNU_SOURCE -I../../stlport -c -o obj/gcc/so/dll_main.o ../../src/dll_main.cpp /usr/include/../include/stdlib.h:469: error: expected ‘;’ before ‘*’ token /usr/include/../include/stdlib.h:470: error: expected ‘;’ before ‘*’ token /usr/include/../include/stdlib.h:471: error: expected ‘;’ before ‘*’ token /usr/include/../include/stdlib.h:475: error: expected ‘;’ before ‘*’ token /usr/include/../include/stdlib.h:479: error: ‘int32_t’ has not been declared winegcc: g++ failed. make: *** [obj/gcc/so/dll_main.o] Error 2 Anyway these are probably from grabbing the system headers which I have read you should not have happen, but if I try to use a -isystem/usr/include/wine/msvcrt or -Isystem/usr/include/wine/msvcrt and -nostdinc++ you then get tons of errors about the stl headers missing exception, cstring, etc. I was wondering if anyone had any thoughts or ideas on how to get this compiled so it is usable is porting applications. Thanks
Re: mscoree: Add a stub implementation for CorExitProcess and GetRequestedRuntimeInfo.
Here's a very simple .NET app that runs: http://www.heise.de/software/default.shtml?prg=20130&T=dingler&osg=1 $ file hit_windows.exe hit_windows.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit Mono/.Net assembly And the obligatory screenshot: -Hans
Re: [1] WineD3D: Add the state dirtification infrastructure
Am Montag 18 Dezember 2006 19:25 schrieb Stefan Dösinger:
Another issue I stumbled uppon: This patch moves the + 1 for the array
declaration to the right place.
> Am Montag 18 Dezember 2006 14:06 schrieb Stefan Dösinger:
> Another update, it fixes an spotted by Henri issue where the state was used
> instead of the representative and uses shifting and bitmasks to calculate
> the index and shift for the bitmap.
>
> > This is another updated version, it uses bitmaps for the isStateDirty
> > member.
> >
> > Am Sonntag 17 Dezember 2006 14:45 schrieb Stefan Dösinger:
> > > Am Freitag 15 Dezember 2006 18:31 schrieb Stefan Dösinger:
> > > > This patch adds the dirty list infrastructure. A dirty marker
> > > > consists of a DWORD containing the state it marks dirty, and the list
> > > > structure to build the list.
> > > >
> > > > The wined3ddevice has 3 new members:
> > > > dirtyStateList: The list of dirty states. This will be moved to a
> > > > per-context stucture once we add multithreading support
> > > > freeListElems: A list containing unused dirty markers to avoid
> > > > unnecessary HeapAlloc/HeapFree calls. I have seen D3D games spending
> > > > 15% cpu time in the Heap code, we don't want to increase that.
> > > > dirtyStates: An array that tells if a state is dirty. It is used to
> > > > avoid double dirtification. I do not use the
> > > > stateblock->changed.[] array because this is used for different
> > > > purposes in the stateblock code. Ivan, do we still need it?
> > >
> > > Attached is an updated patch that uses an array for dirtification
> > > instead of a list. Actually there are 2 arrays, one to quickly find out
> > > if a specific state is dirty, and one to quickly find all dirty states.
> > >
> > > Checking if a state is dirty is done very often, so we need the
> > > isStateDirty. A linear search on the dirtyArray would take way too much
> > > time. On the other hand, my experiance so far shows that usually not
> > > more than 10-20 states are dirty at the beginning of a drawprim call,
> > > so iterating over all states would be a waste of time too. That's why
> > > the dirtyArray is there.
> > >
> > > In the end there will be around 1000 states, so the size of those
> > > arrays will be 8-10 kilobytes. Even oldest games load textures in the
> > > area of megabytes, with recent games it's about gigabytes, so I don't
> > > think those 10 kb's are an issue :-) . I could easilly change the
> > > DWORDs to shorts, but all d3d states are defined as DWORDs, so I
> > > decided to use DWORDS.
> > >
> > > If I used a bitmap I could squeeze the same information in about 128
> > > bytes + extra size for the code dealing with the bitmap + extra runtime
> > > needs for bit shifting and checking all DWORDs in the bitmap. D3D games
> > > are usually cpu limited, so I prefer the more memory intensive version.
> > >
> > > The other patches should apply cleanly over this patch, so I do not
> > > resend them.
From e0b86ee56d5e91feaff5384ed5231f2b419fd8b3 Mon Sep 17 00:00:00 2001
From: Stefan Doesinger <[EMAIL PROTECTED]>
Date: Mon, 18 Dec 2006 20:18:54 +0100
Subject: [PATCH] WineD3D: Add state dirtification infrastructure
---
dlls/wined3d/device.c | 13 +
dlls/wined3d/drawprim.c| 12
dlls/wined3d/wined3d_private.h | 20
3 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index 685cdf9..217f666 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -7084,3 +7084,16 @@ const DWORD SavedVertexStates_T[NUM_SAVE
const DWORD SavedVertexStates_S[NUM_SAVEDVERTEXSTATES_S] = {
WINED3DSAMP_DMAPOFFSET
};
+
+void IWineD3DDeviceImpl_MarkStateDirty(IWineD3DDeviceImpl *This, DWORD state) {
+DWORD rep = StateTable[state].representative;
+DWORD idx;
+BYTE shift;
+
+if(!rep || isStateDirty(This, rep)) return;
+
+This->dirtyArray[This->numDirtyEntries++] = rep;
+idx = rep >> 5;
+shift = rep & 0x1f;
+This->isStateDirty[idx] |= (1 << shift);
+}
diff --git a/dlls/wined3d/drawprim.c b/dlls/wined3d/drawprim.c
index a560084..06a86ae 100644
--- a/dlls/wined3d/drawprim.c
+++ b/dlls/wined3d/drawprim.c
@@ -2129,6 +2129,8 @@ void drawPrimitive(IWineD3DDevice *iface
IWineD3DSwapChainImpl *swapchain;
int i;
BOOL fixup = FALSE;
+DWORD dirtyState, idx;
+BYTE shift;
BOOL lighting_changed, lighting_original = FALSE;
@@ -2163,6 +2165,16 @@ void drawPrimitive(IWineD3DDevice *iface
/* Ok, we will be updating the screen from here onwards so grab the lock */
ENTER_GL();
+/* Apply dirty states */
+for(i=0; i < This->numDirtyEntries; i++) {
+dirtyState = This->dirtyArray[i];
+idx = dirtyState >> 5;
+shift = dirtyState & 0x1f;
+This->isStateDirty[idx] &= ~(1 << shift);
+StateT
Re: mscoree: Add a stub implementation for CorExitProcess and GetRequestedRuntimeInfo.
Thanks for all the info, Hans. I stole some time this morning and, starting with your script, came up with one that lets Life Balance install; this would probably be appropriate for any .net 1.1 application: #!/bin/sh wineserver -k cat >> $HOME/.wine/system.reg <<"_EOF_" [Software\\Microsoft\\NET Framework Setup\\NDP\\v1.1.4322] "Install"=dword:0001 "SP"=dword:0001 [Software\\Microsoft\\.NETFramework\\policy\\v1.1] "4322"="3706-4322" _EOF_ The installer hangs at the end after you answer the "want to reboot?" prompt, but the app seems to be installed ok offhand. Running it fails with $ ~/wine-git/wine Life\ Balance.exe ** (Life Balance.exe:10): WARNING **: field __ImageBase in should have RVA data, but hasn't Stacktrace: at Life_Balance.LBForm..cctor () <0x> at Life_Balance.LBForm..cctor () <0x00084> at (wrapper runtime-invoke) System.Object.runtime_invoke_void (object,intptr,intptr,intptr) <0x> (This is with the latest Mono for Windows installed.) But hey, that's progress! - Dan
Re: Running winetest on Vista
"Paul Vriens" <[EMAIL PROTECTED]> wrote: Does it help if you rename it to test_setupapi.exe? No :-( As soon as setup is contained in the name it doesn't run. The link that Kevin showed makes sense now. Any idea how we can approach this? Do we indeed need to start adding manifests to some of our tests? I'm afraid this is not the only thing we're going to run into. IE7 and Vista already show some major changes in things like advpack/crypt32/wintrust. Well, a manifest is just an text (.xml) file with the resource type set to RT_MANIFEST. Adding it into the resources is easy, the problem is that wrc doesn't support that kind of a resource, so that support should be added to wrc first. -- Dmitry.
Re: ws2_32: Implement the SIO_ADDRESS_LIST_QUERY ioctl.
"Hans Leidekker" <[EMAIL PROTECTED]> wrote:
case WS_SIO_ADDRESS_LIST_QUERY:
-FIXME("-> SIO_ADDRESS_LIST_QUERY request: stub\n");
-break;
+ {
+int fd;
+DWORD size;
+
+TRACE("-> SIO_ADDRESS_LIST_QUERY request\n");
+
+if (!lpcbBytesReturned || (fd = get_sock_fd(s, 0, NULL)) == -1)
It appears that fd is not used later at all.
--
Dmitry.
re: mscoree: Add a stub implementation for CorExitProcess and GetRequestedRuntimeInfo.
Hi, Dan I don't think it's a good idea to make a check for .NET 2.0 succeed. Currently Mono implements only .NET 1.1 Paul Chitescu On Sun, 17 Dec 2006, Dan Kegel wrote: [...] And bingo, http://msdn2.microsoft.com/en-us/library/aa480243.aspx documents this as part of the check to see if .net is installed. Has somebody figured out a canned .reg file to use to fake out this install check? - Dan
Bug 50
First, sorry for the blank mail I accidentally sent earlier... my bad. Ok, so I have been assigned bug 50 [1] here at my job, and I'm trying to apply the patch [2] Keith Dunwoody proposed in June 2005, which fixed the issue but was rejected for technical reasons. Right now I can't think of another way around that bug except a patch that big, but I think we could break it into two smaller ones: the first one would change what must be changed for the second one ― the actual correction ― to work. Well, that first one involves changing the signatures of the ExtTextOut functions in winex11.drv, in a similar fashion to what Keith had proposed; but, instead of adding 'INT *breakTotalExtra, INT *breakCount' to their argument lists, I suggest that we pass them the whole DC instead of just its physDev ― that way we'd have access to the relevant attributes while still being able to get its physDev (assigning it to a variable right at the beginning of the functions, in order to keep their current functionality in this first step). I'm only afraid that may bring a little overhead, so I'd really like to see some opinions, or some better ideas... [1] http://bugs.winehq.org/show_bug.cgi?id=50 [2] http://bugs.winehq.org/attachment.cgi?id=912&action=view I'll be testing that here, anyway. Cheers, Pedro. -- "People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster." (Adam Osborne)
Bug 50
-- "People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster." (Adam Osborne)
Re: DDraw: Implement depth filling through blit. (re-resubmit) try3
Am Sonntag 17 Dezember 2006 23:24 schrieb [EMAIL PROTECTED]:
> Original Author:
> Elie Morisse
> [EMAIL PROTECTED]
>
> Updated by:
> Gregor Münch
> [EMAIL PROTECTED]
>
> This is modified version of this patch:
> http://www.winehq.org/pipermail/wine-patches/2006-September/030815.html
>
> With the help from Stefan Dösinger I altered 2 lines. Full credit
> belongs to Elie Morisse
>
> fixes: http://bugs.winehq.org/show_bug.cgi?id=4306
A small issue: The indentions in IWineD3DSurfaceImpl_BltZ look a bit strange.
--- a/dlls/ddraw/ddraw.c
+++ b/dlls/ddraw/ddraw.c
@@ -1787,7 +1787,7 @@ IDirectDrawImpl_CreateNewSurface(IDirect
{
Usage |= WINED3DUSAGE_OVERLAY;
}
-if(This->depthstencil)
+if(This->depthstencil || (pDDSD->ddsCaps.dwCaps & DDSCAPS_ZBUFFER))
{
Perhaps you can get rid of This->depthstencil by setting the DDSCAPS_ZBUFFER
flag instead on the requested surface desc in the auto depth stencil creation
callback. Mind you, this auto depth stencil creation isn't used nowadays any
more, it was needed earlier to prevent wined3d from crashing. You can remove
the function body and replace it by an ERR entirely I think, it shouldn't be
called if everything works correctly in wined3d.
pgp9h3LiIAQ48.pgp
Description: PGP signature
Re: mscoree: Add a stub implementation for CorExitProcess and GetRequestedRuntimeInfo.
On Monday 18 December 2006 04:06, Dan Kegel wrote: > Which apps? > Now that your patches seem to have been committed, I've started > trying to find and install apps that require .net, but for some > reason I'm having trouble finding many. For some years now I've been doing an unscientific benchmark of Wine by trying every installer on the CD that comes bundled with the excellent German magazine CT, every two months or so (I can confirm that we're doing much, much better than two years ago). For some time now it includes the dotnet runtime distributable along with a handful of applications that require it. CT's publisher, Heise Verlag maintains a vast online software database that is another shining example of Deutsche Gruendlichkeit: http://www.heise.de/software/default.shtml?osg=1 Try '.net' as keyword. > http://msdn2.microsoft.com/en-us/library/aa480243.aspx documents > this as part of the check to see if .net is installed. Has somebody > figured out a canned .reg file to use to fake out this install check? Good point. Here's a script that does that, modeled after your fakeie.sh. -Hans #!/bin/sh wineserver -k cat >> $HOME/.wine/system.reg <<"_EOF_" [Software\\Microsoft\\NET Framework Setup\\NDP\\v2.0.50727] "Install"=dword:0001 _EOF_
