Re: [2/3] WineD3D: Implement bem shader instruction
On 25/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
With the glsl suggestions from Henri :-)
+shader_addline(arg->buffer, "(%s.xy + bumpenvmat * %s.xy)%s);\n",
+ src0_param.reg_name, src1_param.reg_name, dst_mask);
MSDN states that the source parameters can have swizzles and
modifiers. Unless, you can prove that's not true, the code should
become:
void pshader_glsl_bem(SHADER_OPCODE_ARG* arg) {
glsl_src_param_t src0_param, src1_param;
shader_glsl_append)dst(arg->buffer, arg);
shader_glsl_add_src_param(arg, arg->src[0], arg->src_addr[0],
WINED3DSP_WRITEMASK_0|WINED3DSP_WRITEMASK_1, &src0_param);
shader_glsl_add_src_param(arg, arg->src[1], arg->src_addr[1],
WINED3DSP_WRITEMASK_0|WINED3DSP_WRITEMASK_1, &src1_param);
shader_addline(arg->buffer, "%s + bumpenvmat * %s);\n",
src0_param.param_str, src1_param.param_str);
}
Normally you would have to take the destination write mask into
account as well, but for this instruction it's always .xy.
Re: WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in arb shaders
On 25/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: In 1.X shaders too? I see that in 2.0+ shaders this is the way to use projected textures, but in 1.X there is the D3DTTFF_PROJECTED projected flag. No, 2.0+ has the D3DSI_TEXLD_PROJECT, 1.4 has _dw/_dz modifiers and pre-1.4 has the fixed function D3DTTFF_PROJECTED flag. You do bring up another issue though... I think we should decide on what the ARB backend is supposed to implement. Right now it's a bit of a mess with some parts only supporting up to ps_1.3, other parts doing ps_1.4, and some broken support for vs_2.0 added in. (eg. mova). I think that if we're going to say we don't support anything higher than ps_1.3 there, we shouldn't try to compile shaders with higher versions either.
Fwd: DirectDrawRenderer - opengl non power of 2 windows
Oh sorry, my misunderstanding! It is called from: flush_to_framebuffer_drawpixels http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/surface.c;hb=HEAD#l956 On 3/25/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Am Samstag 24 März 2007 23:59 schrieb Nathan Williams: > It crashes at: > dlls/wined3d/surface.c > d3dfmt_convert_surface: > 1593 *dest++ = table[color][0]; Yes, but from where is this called? d3dfmt_convert_surface: gets a height parameter, and this parameter is incorrect. -- Nathan
Re: DirectDrawRenderer - opengl non power of 2 windows
Am Samstag 24 März 2007 23:59 schrieb Nathan Williams: > It crashes at: > dlls/wined3d/surface.c > d3dfmt_convert_surface: > 1593 *dest++ = table[color][0]; Yes, but from where is this called? d3dfmt_convert_surface: gets a height parameter, and this parameter is incorrect. pgpnVWcsr4VI6.pgp Description: PGP signature
Re: DirectDrawRenderer - opengl non power of 2 windows
It crashes at: dlls/wined3d/surface.c d3dfmt_convert_surface: 1593 *dest++ = table[color][0]; http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/surface.c;hb=HEAD#l1593 If I hack that loop to be the right height, it works without complaint. The original setting of the height to be a power of 2 is: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/surface.c;hb=HEAD#l3195 On 3/25/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Is the crashing call done from flush_to_framebuffer_* or LoadTexture? -- Nathan
Re: DirectDrawRenderer - opengl non power of 2 windows
Am Samstag 24 März 2007 22:42 schrieb Nathan Williams: > Should I go ahead and remove the same from dlls/wined3d/surface.c and > submit a patch, or have you beaten me to it? =D > > On 3/25/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > > Sounds like that the surface conversion code still makes some assumptions > > about the allocated memory size and the surface size. Wine used to > > allocate the full power of 2 size, but I removed that and allocate only > > the real surface size because there are some applications which expected > > a specific pitch for the surface. The power of 2 size usage vs real size > > was pretty inconsistent, I guess there is another inconsistency. Is the crashing call done from flush_to_framebuffer_* or LoadTexture? pgpvGpwRLLcWT.pgp Description: PGP signature
Re: WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in arb shaders
Am Samstag 24 März 2007 16:01 schrieb H. Verbeet: > On 24/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > > Am Samstag 24 März 2007 15:36 schrieb Ivan Gyurdiev: > > > > From b1df18be85d1ca6a9904be05420f975f6933b030 Mon Sep 17 00:00:00 > > > > 2001 From: Stefan Doesinger <[EMAIL PROTECTED]> > > > > Date: Fri, 23 Mar 2007 19:03:58 +0100 > > > > Subject: [PATCH] WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in > > > > texcrd in arb shaders > > > > > > Isn't there a function to handle modifiers? > > > "get_modifier_line"... > > > > Oh indeed, you're right. I'll fix the patch. > > The tex instruction can have these modifiers as well. In 1.X shaders too? I see that in 2.0+ shaders this is the way to use projected textures, but in 1.X there is the D3DTTFF_PROJECTED projected flag. pgp15oy7xo5Gd.pgp Description: PGP signature
Re: DirectDrawRenderer - opengl non power of 2 windows
Should I go ahead and remove the same from dlls/wined3d/surface.c and submit a patch, or have you beaten me to it? =D On 3/25/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Sounds like that the surface conversion code still makes some assumptions about the allocated memory size and the surface size. Wine used to allocate the full power of 2 size, but I removed that and allocate only the real surface size because there are some applications which expected a specific pitch for the surface. The power of 2 size usage vs real size was pretty inconsistent, I guess there is another inconsistency. -- Nathan
Re: DirectDrawRenderer - opengl non power of 2 windows
> Now I traced the problem down to: > dlls/wined3d/surface.c > d3dfmt_convert_surface > > loops over the surface height and width, the only problem is that the > surface height appears to be scaled up to the next power of 2. > > As carmageddon runs in 320x200 the loop tries to iterate over 320x256 > and subsequently crashes with a page fault in winedbg. Sounds like that the surface conversion code still makes some assumptions about the allocated memory size and the surface size. Wine used to allocate the full power of 2 size, but I removed that and allocate only the real surface size because there are some applications which expected a specific pitch for the surface. The power of 2 size usage vs real size was pretty inconsistent, I guess there is another inconsistency. pgpPkE0ISQQ2g.pgp Description: PGP signature
Re: SoC Idea: Improve bultin WordPad
Hi, Printing please! It needs lots of work. Wordpad doesn't have it, and notepad printing is terrible. It will be done as soon as a cheap cure for cancer will be found ;) Not something to be done by an inexperienced person and definitely not a "low-hanging fruit" of any kind. It looks like I have an idea or two about how to deal with printing, but first architectural changes that have to be done, then testing it all, scare the hell out of me. The problem is representing two different visual representations of the same physical text, one for display, one for printing (which can be wrapped differently, as far as I know). Some hack may be used (like making a physical copy of the text being printed, a separate ME_TextEditor structure), but it's kind of ugly and I don't know if such a design decision wouldn't give future compatibility headaches. On the other hand, a "virtual representation" may be used (for printing, we'd use a list of runs and lines containing pointers to text fragments and styles in screen representation instead of separate copy of the text). The SDK documentation for EM_DISPLAYBAND and EM_FORMATRANGE aren't really clear to me. Maybe (pure wild speculation) there is no need to keep separate versions, because a client is required to free the printer formatting information before screen is updated? Some tests (reverse engineering, or just making an example application that prints using richedit) definitely need to be done. Anyone? :D -- Krzysztof Foltman
Re: Another win32 implementation: hiweedlayer?
> Yup. Going by the strings in "their" wined3d.dll.so, it's a relatively > recent version of wine as well. It says wine-0.9.32. They seem to ship a native mfc40.dll and vb6 runtime. Otherwise I could not see any special things yet. pgpUc2z0wTW9V.pgp Description: PGP signature
Re: SoC Idea: Improve bultin WordPad
Dan Kegel wrote: Alex wrote: closest I have gotten is some patches for Wine's WordPad implementation. Granted, it's less sexy than games, but you could learn more about C and Wine by building on that experience. There are lots of small and easy improvements that can be done get Wordpad up to par with native. Then come back next year to fix the games! That i s a good idea. :) I think I will go for it, unless anyone has objections to it. Sounds good to me. Suggestion: spend a day or two filing bugs or enhancement requests now for a bunch of things you'd like to fix / improve in wordpad. (I might even suggest broadening your proposal to include notepad; maybe there are a couple low-hanging fruit there.) Printing please! It needs lots of work. Wordpad doesn't have it, and notepad printing is terrible.
re; [Resend][Corrected] gdi32:widenpath partial implementation
I think it might help to a) create a bug in bugzilla with a link to Navigation, and a screenshot of the problem, and a recipe to reproduce b) think about how to implement a conformance test. Even a simple one might help. These suggestions were already made back in http://www.winehq.org/pipermail/wine-devel/2007-January/053457.html - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: SoC idea: Get Mono working well enough to run Digital Writing Software (was: ... simple apps)
Dan Kegel wrote: There are lots of little bits, some pretty basic, which Wine is missing before it can support mixed assemblies in Mono. For instance, http://bugs.winehq.org/show_bug.cgi?id=7098 says that we're missing an implementation of mscoree.dll.CorBindToRuntimeEx. This would probably be a fine area for an SoC project. I doubt it qualifies as a simple app (as it includes multiple pieces), but the dotnet 1.1 dependent app I want to run is the download and handwriting recognizing software for the Logitech io2 Digital Pen. http://www.logitech.com/index.cfm/downloads/software/US/EN,CRID=1808,contentid=13127 If there is someone who wants to tackle it, I'll buy them the starter kit. http://www.logitech.com/index.cfm/products/details/US/EN,CRID=1553,CONTENTID=11530 Jim
Re: Another win32 implementation: hiweedlayer?
On 24/03/07, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: Exactly. Remove everything up to class.tgz.BEGIN in hiweedlayer and untar it somewhere, what we see (reminds me something): share/ dosdevices/ lib/ bin/ drive_c/ user.reg system.reg my.reg and inside of lib\ wine\ (with all Wine dll.so files) libwine.so.1 libwine.so.1.0 -- Dmitry. Yup. Going by the strings in "their" wined3d.dll.so, it's a relatively recent version of wine as well.
Re: Another win32 implementation: hiweedlayer?
"Dan Kegel" <[EMAIL PROTECTED]> wrote: http://hiweed.com/node/798 offers "hiweedlayer" for download. It is supposedly a Windows layer like Wine. Running strings on their single executable, I see messages like %s is being traced! location has changed! abnormal behavior! shell has changed! %s has expired! Please contact your provider which look like they're from this little bit of malware: http://forums.fedoraforum.org/archive/index.php/t-25441.html but perhaps they're just trying to keep people from reverse-engineering their code (or finding out that they have Wine code inside?). Exactly. Remove everything up to class.tgz.BEGIN in hiweedlayer and untar it somewhere, what we see (reminds me something): share/ dosdevices/ lib/ bin/ drive_c/ user.reg system.reg my.reg and inside of lib\ wine\ (with all Wine dll.so files) libwine.so.1 libwine.so.1.0 -- Dmitry.
Re: Wine SoC idea: get your favorite IDE working
On Sat, 2007-03-24 at 06:17 -0700, Dan Kegel wrote: > As the CEO of a famous operating system company once said, > "I have four words for you: developers, Developers, DEVELOPERS, DEVELOPERS!" > ( http://www.youtube.com/watch?v=KMU0tzLwhbE ) > > Attracting more developers (not of wine, but of their own apps) to Linux > by getting their IDEs running on Wine would be great for wine, > as developers are more likely than the average user to file bug reports > or (dare we hope) fix bugs. So it would be good to get popular IDEs > working on Wine. > > Newer Microsoft IDEs like Visual Studio 2005 are a challenge, > Visual Studio 2005 express requires BITS (which is a SoC project in itself, > http://bugs.winehq.org/show_bug.cgi?id=5054) > > Some IDEs run fairly well if you install DCOM98, in which case you > would write conformance tests exposing the problems in our COM > implementation so Rob can fix them :-) > Older IDEs like Visual C++ 6 and Visual Basic 6 are in this category. cf. > http://bugs.winehq.org/show_bug.cgi?id=4931 > http://bugs.winehq.org/show_bug.cgi?id=5321 > > And then there's Eclipse, Delphi, Turbo C++, IntelliJ, Powerbuilder, Access, > Visual Fox Pro, and many others. There are also specialized IDEs like > AVRStudio (an IDE for embedded developers) which people want to run in Wine > (see http://bugs.winehq.org/show_bug.cgi?id=5312). > > Picking one or two of these and focusing on getting its problems > solved might be very useful. > - Dan > Another IDE I can throw out there is MPLAB. It is a major showstopper for anything doing PIC Development. It is freely down-loadable here: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 Stephan
Re: Fwd: "Out of Tree" DLLs
Kai Blin schreef: > Hi folks, > > Tim asked me about this on IRC today, and I didn't have any good idea about > it, so I'll just forward it to you people. > > Cheers, > Kai > > > > > Onderwerp: > "Out of Tree" DLLs > Van: > Tim Ansell <[EMAIL PROTECTED]> > Datum: > Sun, 25 Mar 2007 00:22:52 +1030 > Aan: > [EMAIL PROTECTED] > > Aan: > [EMAIL PROTECTED] > > Return-Path: > <[EMAIL PROTECTED]> > X-Original-To: > [EMAIL PROTECTED] > Delivered-To: > [EMAIL PROTECTED] > Received: > from blackjack.home.nowhere-productions.org (localhost [127.0.0.1]) by > blackjack.home.nowhere-productions.org (Postfix) with ESMTP id > E49822037F for <[EMAIL PROTECTED]>; Sat, 24 Mar 2007 14:55:29 +0100 (CET) > Delivered-To: > [EMAIL PROTECTED] > Received: > from pop.gmail.com by blackjack.home.nowhere-productions.org with POP3 > (fetchmail-6.3.2) for <[EMAIL PROTECTED]> (single-drop); Sat, 24 Mar > 2007 14:55:29 +0100 (CET) > Received: > by 10.114.75.8 with SMTP id x8cs1391094waa; Sat, 24 Mar 2007 06:53:20 > -0700 (PDT) > Received: > by 10.66.243.2 with SMTP id q2mr8592169ugh.1174744400071; Sat, 24 Mar > 2007 06:53:20 -0700 (PDT) > Received: > from lester.mithis.com (lester.mithis.com [69.60.120.93]) by > mx.google.com with ESMTP id b30si12976425ika.2007.03.24.06.53.15; Sat, > 24 Mar 2007 06:53:20 -0700 (PDT) > Received-SPF: > pass (google.com: domain of [EMAIL PROTECTED] designates 69.60.120.93 > as permitted sender) > Received: > from [10.1.50.1] (ppp246-117.static.internode.on.net > [203.122.246.117]) by lester.mithis.com (Postfix) with ESMTP id > F1052B777 for <[EMAIL PROTECTED]>; Sat, 24 Mar 2007 09:53:02 -0400 (EDT) > Content-Type: > text/plain > Organisatie: > MITHIS > Bericht-ID: > <[EMAIL PROTECTED]> > MIME-versie: > 1.0 > X-Mailer: > Evolution 2.10.0 > Content-Transfer-Encoding: > 7bit > Regels: > 23 > > > Hi, > > A long while back I wrote a "dll" which allows programs which use the > ftd2xx.dll library to access hardware to do so under wine. There has > been some interest in getting it working again. > > There are a bunch of stuff which need this, however it's very niche so > the code is always going to be fairly crappy and not good enough for the > main wine tree. > > It would be nice if there was a way for you to build this DLL easily > without having to build the complete wine. > > You can find the code here, > http://ftd2xx.cvs.sourceforge.net/ftd2xx/ftd2xx/ > > It probably doesn't compile at the moment as it's suffered quite a bit > of "bit rot" over the few years that I haven't touched it. > > Thanks for your help. > > Tim Ansell > After trying a little I came to the following conclusion, assuming dll is called foo.dll, exports are available as foo.spec and wine is installed globally: winegcc -D_REENTRANT -D__WINESRC__ $(CFLAGS) -o foo_main.o foo_main.c winegcc $(CFLAGS) -mwindows -lntdll -lkernel32 -o foo.dll foo_main.o -shared foo.spec winebuild -w --def -o libfoo.def --export foo.spec After that you just need to put libfoo.def and foo.dll.so in the right place. Hope this helps, Maarten
Re: WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in arb shaders
On 24/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Am Samstag 24 März 2007 15:36 schrieb Ivan Gyurdiev: > > From b1df18be85d1ca6a9904be05420f975f6933b030 Mon Sep 17 00:00:00 2001 > > From: Stefan Doesinger <[EMAIL PROTECTED]> > > Date: Fri, 23 Mar 2007 19:03:58 +0100 > > Subject: [PATCH] WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in > > texcrd in arb shaders > > Isn't there a function to handle modifiers? > "get_modifier_line"... Oh indeed, you're right. I'll fix the patch. The tex instruction can have these modifiers as well.
Re: WineD3D: Implement bem shader instruction
On 24/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: +shader_glsl_get_write_mask(arg->dst, dst_mask); +shader_glsl_add_src_param(arg, arg->src[0], arg->src_addr[0], WINED3DSP_WRITEMASK_ALL, &src0_param); +shader_glsl_add_src_param(arg, arg->src[1], arg->src_addr[1], WINED3DSP_WRITEMASK_0|WINED3DSP_WRITEMASK_1, &src1_param); + +shader_glsl_append_dst(arg->buffer, arg); +shader_addline(arg->buffer, "(%s + vec4(bumpenvmat * %s.rg, 0.0, 0.0))%s);\n", + src0_param.reg_name, src1_param.reg_name, dst_mask); +} Please use xyzw consistently for components. Mixing xyzw with rgba and stuv only obfuscates things. Also, the vec4 contructor is unecessary, you should use proper swizzles instead.
Another win32 implementation: hiweedlayer?
http://hiweed.com/node/798 offers "hiweedlayer" for download. It is supposedly a Windows layer like Wine. Running strings on their single executable, I see messages like %s is being traced! location has changed! abnormal behavior! shell has changed! %s has expired! Please contact your provider which look like they're from this little bit of malware: http://forums.fedoraforum.org/archive/index.php/t-25441.html but perhaps they're just trying to keep people from reverse-engineering their code (or finding out that they have Wine code inside?). Using google language tools to translate the page, http://translate.google.com/translate?u=http%3A%2F%2Fhiweed.com%2Fnode%2F798&langpair=zh%7Cen&hl=en&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools it looks like somebody already asked them if they were related to wine, but they didn't really answer. Can somebody fluent in Chinese make contact with them and see what their story is with regard to wine? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in arb shaders
Am Samstag 24 März 2007 15:36 schrieb Ivan Gyurdiev: > > From b1df18be85d1ca6a9904be05420f975f6933b030 Mon Sep 17 00:00:00 2001 > > From: Stefan Doesinger <[EMAIL PROTECTED]> > > Date: Fri, 23 Mar 2007 19:03:58 +0100 > > Subject: [PATCH] WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in > > texcrd in arb shaders > > Isn't there a function to handle modifiers? > "get_modifier_line"... Oh indeed, you're right. I'll fix the patch. pgpUpjIwQ5EE5.pgp Description: PGP signature
Re: Undocumented functionsyssetup.dll.SetupQueryRegisteredOsComponent
"Rolf Kalbermatter" <[EMAIL PROTECTED]> wrote:
From a quick check it seems to take three parameters, with the first being
a CLSID or other GUID and the other two being DWORDs. The second parameter
is checked to be higher than 0 and smaller or equal to 0xDC and the third
parameter is checked to be higher than 0 and smaller or equal to 0x454.
(This is XP SP2 fully patched).
When any of the three parameters are 0, the function sets last error to 0x57
and returns with 0. When the second and third parameter is above the limits
the function sets last error to 0x0D and returns with 0. When everything was
successful the function returns with 1.
This appears to be a correct description, at least attached test shows exactly
the same behaviour as described above. If I add 2 more parameters as Andrey
suggested I get a crash due to stack corruption.
This information should be enough to create a stub.
--
Dmitry.
#include
#include
#include
#include
typedef struct
{
DWORD dwSize;
char unused[0xd8];
} UNK_1;
typedef struct
{
DWORD dwSize;
char unused[0x450];
} UNK_2;
int main(void)
{
BOOL (WINAPI *pSetupQueryRegisteredOsComponent)(const IID *const iid, LPVOID
component_data, LPVOID exception_data);
BOOL ret;
IID guid;
HRESULT hres;
HANDLE hDll;
UNK_1 unk_1;
UNK_2 unk_2;
hres = IIDFromString(L"{473FF9A0-D659-11D1-A4B2-006008AF820E}", &guid);
assert(hres == S_OK);
hDll = LoadLibrary("syssetup.dll");
assert(hDll);
pSetupQueryRegisteredOsComponent = (void *)GetProcAddress(hDll,
"SetupQueryRegisteredOsComponent");
assert(pSetupQueryRegisteredOsComponent);
SetLastError(0xdeadbeef);
ret = pSetupQueryRegisteredOsComponent(NULL, NULL, NULL);
printf("(NULL, NULL, NULL) ret = %d, error %u\n", ret, GetLastError());
assert(GetLastError() == ERROR_INVALID_PARAMETER);
unk_1.dwSize = sizeof(unk_1);
unk_2.dwSize = sizeof(unk_2);
SetLastError(0xdeadbeef);
ret = pSetupQueryRegisteredOsComponent(&guid, &unk_1, &unk_2);
printf("(&guid, &unk_1, &unk_2) ret = %d, error %u\n", ret, GetLastError());
assert(GetLastError() == ERROR_FILE_NOT_FOUND);
unk_1.dwSize = sizeof(unk_1) + 1;
unk_2.dwSize = sizeof(unk_2) + 1;
SetLastError(0xdeadbeef);
ret = pSetupQueryRegisteredOsComponent(&guid, &unk_1, &unk_2);
printf("(&guid, &unk_1, &unk_2) ret = %d, error %u\n", ret, GetLastError());
assert(GetLastError() == ERROR_INVALID_DATA);
FreeLibrary(hDll);
return 0;
}
Re: WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in arb shaders
From b1df18be85d1ca6a9904be05420f975f6933b030 Mon Sep 17 00:00:00 2001 From: Stefan Doesinger <[EMAIL PROTECTED]> Date: Fri, 23 Mar 2007 19:03:58 +0100 Subject: [PATCH] WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in arb shaders Isn't there a function to handle modifiers? "get_modifier_line"...
Fwd: "Out of Tree" DLLs
Hi folks, Tim asked me about this on IRC today, and I didn't have any good idea about it, so I'll just forward it to you people. Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. --- Begin Message --- Hi, A long while back I wrote a "dll" which allows programs which use the ftd2xx.dll library to access hardware to do so under wine. There has been some interest in getting it working again. There are a bunch of stuff which need this, however it's very niche so the code is always going to be fairly crappy and not good enough for the main wine tree. It would be nice if there was a way for you to build this DLL easily without having to build the complete wine. You can find the code here, http://ftd2xx.cvs.sourceforge.net/ftd2xx/ftd2xx/ It probably doesn't compile at the moment as it's suffered quite a bit of "bit rot" over the few years that I haven't touched it. Thanks for your help. Tim Ansell --- End Message --- pgpQBXzSivDTn.pgp Description: PGP signature
Wine SoC idea: get your favorite IDE working
As the CEO of a famous operating system company once said, "I have four words for you: developers, Developers, DEVELOPERS, DEVELOPERS!" ( http://www.youtube.com/watch?v=KMU0tzLwhbE ) Attracting more developers (not of wine, but of their own apps) to Linux by getting their IDEs running on Wine would be great for wine, as developers are more likely than the average user to file bug reports or (dare we hope) fix bugs. So it would be good to get popular IDEs working on Wine. Newer Microsoft IDEs like Visual Studio 2005 are a challenge, Visual Studio 2005 express requires BITS (which is a SoC project in itself, http://bugs.winehq.org/show_bug.cgi?id=5054) Some IDEs run fairly well if you install DCOM98, in which case you would write conformance tests exposing the problems in our COM implementation so Rob can fix them :-) Older IDEs like Visual C++ 6 and Visual Basic 6 are in this category. cf. http://bugs.winehq.org/show_bug.cgi?id=4931 http://bugs.winehq.org/show_bug.cgi?id=5321 And then there's Eclipse, Delphi, Turbo C++, IntelliJ, Powerbuilder, Access, Visual Fox Pro, and many others. There are also specialized IDEs like AVRStudio (an IDE for embedded developers) which people want to run in Wine (see http://bugs.winehq.org/show_bug.cgi?id=5312). Picking one or two of these and focusing on getting its problems solved might be very useful. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
re: SoC Idea: Improve bultin WordPad
Alex wrote: > closest I have gotten is some patches for Wine's WordPad implementation. Granted, it's less sexy than games, but you could learn more about C and Wine by building on that experience. There are lots of small and easy improvements that can be done get Wordpad up to par with native. Then come back next year to fix the games! That i s a good idea. :) I think I will go for it, unless anyone has objections to it. Sounds good to me. Suggestion: spend a day or two filing bugs or enhancement requests now for a bunch of things you'd like to fix / improve in wordpad. (I might even suggest broadening your proposal to include notepad; maybe there are a couple low-hanging fruit there.) - Dan
RE: Undocumented function syssetup.dll.SetupQueryRegisteredOsComponent
Dan Kegel [mailto:[EMAIL PROTECTED] wrote: >Any suggestions as to how to discover the prototype of the apparently >undocumented function syssetup.dll.SetupQueryRegisteredOsComponent ? >It seems to be needed to install mdac-2.8. >( http://bugs.winehq.org/show_bug.cgi?id=5824 ) Well, on the web it does not seem to say anything about that function. So that leaves only reverse engineering. Which means someone would have to dig into it and try to come up with a prototype and possibly some explanation about the parameters and someone else would have to find what can be done. >From a quick check it seems to take three parameters, with the first being a CLSID or other GUID and the other two being DWORDs. The second parameter is checked to be higher than 0 and smaller or equal to 0xDC and the third parameter is checked to be higher than 0 and smaller or equal to 0x454. (This is XP SP2 fully patched). When any of the three parameters are 0, the function sets last error to 0x57 and returns with 0. When the second and third parameter is above the limits the function sets last error to 0x0D and returns with 0. When everything was successful the function returns with 1. And the function starts with opening for read access HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\ExceptionComponents then opens the subkey inside that key from the stringified CLSID. For any registry error the last error is set to the registry function return value and the function itself returns 0. After that things get hairy and seem to be related to functions like SetupEnumerateRegisterdOsComponents() and SetupQueryRegisteredOsComponentsOrder() too. As it seems this is a function that requires magic numbers as parameters and for that reason I'm quite sure that a real implementation is basically impossible without disassembling most of syssetup. Maybe that a stub implementation is enough to get MDAC setup to work. Rolf Kalbermatter
Re: Undocumented function syssetup.dll.SetupQueryRegisteredOsComponent
It's something like BOOL SetupQueryRegisteredOsComponent(IN const IID *const pIid, IN OUT LPVOID component_data, IN OUT LPVOID exception_data, DWORD reserved1, DWORD reserved2); component_data structure max length is 0xDC, exception_data's is 0x454; first argument of both is structure size. I wonder if they defined in setupapi.h already. Dan Kegel wrote: Any suggestions as to how to discover the prototype of the apparently undocumented function syssetup.dll.SetupQueryRegisteredOsComponent ? It seems to be needed to install mdac-2.8. ( http://bugs.winehq.org/show_bug.cgi?id=5824 ) - Dan
Re: xcopy / cmd question (lack of real exe in system32)
"Ann & Jason Edmeades" <[EMAIL PROTECTED]> writes: > Unfortunately I need to know if it's a console app or not, and hence call > FindExecutable followed by SHGetFileInfo. These don't seem to report > anything on the internal programs so I couldn't tell whether to wait for it > to complete (eg xcopy) or let it run (eg notepad). > > I'm patching it to assume worse case (run it synchronous) and just wait, > unless you have any other suggestions, working on the theory this is a very > rare case. We could certainly fix SHGetFileInfo to do the right thing for builtins, using the same method we use for GetFileVersionInfo. -- Alexandre Julliard [EMAIL PROTECTED]
SoC Idea: Improve bultin WordPad (was: Re: SoC Idea: Improve video support)
Lørdag 24 mars 2007 11:07, skrev du : > > closest I have gotten is some patches for Wine's WordPad implementation. > > Granted, it's less sexy than games, but you could learn more about C and > Wine by building on that experience. There are lots of small and easy > improvements that can be done get Wordpad up to par with native. Then come > back next year to fix the games! > > -Hans That i s a good idea. :) I think I will go for it, unless anyone has objections to it. Alexander N. Sørnes
Re: SoC Idea: Improve video support
> closest I have gotten is some patches for Wine's WordPad implementation. Granted, it's less sexy than games, but you could learn more about C and Wine by building on that experience. There are lots of small and easy improvements that can be done get Wordpad up to par with native. Then come back next year to fix the games! -Hans
Re: Winebot
Remco wrote: Will winebot be a win32 app or a linux app? Making it a win32 app and developing it on Windows would probably reveal more Wine bugs. Hi Remco, Winebot is a PERL/Linux code which calls BASH or AutoHotKey scripts. AutoHotkey is a Windows application, so I can safely say, that Winebot (using AutoHotkey) is both Linux and Windows application. Regards Vit
