- Wine-Devel - list.winehq.org

DOSFS_GetFullPathName
by Enrico Horn March 24, 2002

March 24, 2002

Hi, Ive been trying to get Heroes III to work with wine and I found that it cant load some file it needs because DOSFS_GetFullPathName return the path to that file without the backslash at the end although heroes3 asked for it with a backslash at the end. it asks for .\\DATA\\ and the method returns <path to heroes3>\DATA <---- missing backslash in the method the last backlash is removed when no driveletter is in the requested pathname. I'd like to know why this was implemented like this as I cannot understand the reason for it. Thanks for your help Enrico farmboy1(a)subdimension.com

4 3

Even more dumb regression questions...
by Geoffrey Hausheer March 24, 2002

March 24, 2002

InitiallyI thought I'd start with writing a test in Perl, and I got some basic stuff working. But then I needed to access structures, constants, etc, and had no idea how to do this, so I am now rewriting my test in C. My understanding was that for the most part, the C and Perl testing infrastructure were supposed to be comparable, but I haven't seen any examples of how I can do the things I mentioined (specifically, access constants (flags for functions), or create/read structures required by functions. Is this possible to do, and if so could someone give me an example of each? The constants are obviously less difficult, in that I could always redefine them in the test, but being able to manipulate structures seems like it would be a requirement for the framework. Sorry if this is all really straight forward. Thanks, .Geoff ----------------------------------------------------- Protect yourself from spam, use http://sneakemail.com

2 2

Re: Winebuild on Windows
by Alexandre Julliard March 23, 2002

March 23, 2002

Patrik Stridvall <ps(a)leissner.se> writes: > * tools/winebuild/build.h, > tools/winebuild/parser.c, > tools/winebuild/relay.c, > tools/winebuild/res16.c, > tools/winebuild/res32.c: > Fixed some more of the issues that prevented > Winebuild from working under Windows. Why do you need to build .spec.c files on Windows? All you should need is a .def file, and maybe a small hack for the debug channels declarations. -- Alexandre Julliard julliard(a)winehq.com

2 1

Window focus regression
by Duane Clark March 23, 2002

March 23, 2002

This patch to windows/x11drv, back on Feb 25, causes a window focus regression. It has been reported on wine-users, and also affects my apps. http://cvs.winehq.com/patch.py?id=1014666451571945191826671 What a coincidence, this was submitted by Dave :-) Since I don't understand what this was attempting to fix, how about a trade. I will fix the toolbar bug I introduced, and could you take another look at this one? Basically, I am running Gnome (RH 7.2) and have the window manager mouse focus set to follow the mouse. When I slide the mouse out of and back into a managed wine window, the window does not completely regain focus. The mouse focus is returned, but not the keyboard focus. This can be seen in SignLab. I select the text tool, click somewhere in the window, type a few characters, then slide the mouse out of and back into the window. Now typing has no effect until I click the mouse somewhere in the window. Clicking somewhere in the grey border area allows the keyboard focus to return without cancelling the text tool.

3 2

RE: Winebuild on Windows
by Patrik Stridvall March 23, 2002

March 23, 2002

> Patrik Stridvall <ps(a)leissner.se> writes: > > > * tools/winebuild/build.h, > > tools/winebuild/parser.c, > > tools/winebuild/relay.c, > > tools/winebuild/res16.c, > > tools/winebuild/res32.c: > > Fixed some more of the issues that prevented > > Winebuild from working under Windows. > > Why do you need to build .spec.c files on Windows? Well, the .def file that winebuild generates have references to stubs that are implemented in the .spec.c. This could of course be fixed by a simple if statement somewhere, I guess. However I'm not sure that there aren't other things that might be needeed so I generated and compiled .spec.c just in case. > All you should > need is a .def file, In any case the first part of the patch (winebuild.diff) is needed even to generate the .def file so please apply that regardless. > and maybe a small hack for the debug channels > declarations. Yes. But that could just as well be done in .spec.c like on Unix couldn't it? However I understand if you think winebuild2.diff is a little hacky. I'm not 100% satisfied with it myself. So what do you suggest? Is the debug channels really the only problem?

1 0

More dumb regression questions
by Geoffrey Hausheer March 23, 2002

March 23, 2002

How do I run a wine perl regression test in Windows? I thought the entire point was to make it so you don't need a c-compiler, yet I can't seem to get the tests to run without the winetest application (which I've been unable to build on windows so far). Is it planned that this executable be distributed with wine, or am I missing something else? Ideally, I'd like to be able to get just the tests and required apps through cvs (or even a .zip file), and run them. If this is possible today, it isn't obvious (to me) how to do it. Sorry if this is documented somewhere, but I checked Francois' presentation, and the huge thread in January, and didn't find anything about it. If you want to convince people to help write tests, it'd sure be nice if it was easy to find information about how to do it :) .Geoff ----------------------------------------------------- Protect yourself from spam, use http://sneakemail.com

2 1

sandbox for regression tests
by Geoffrey Hausheer March 23, 2002

March 23, 2002

Hello everyone, I was considering writing a few regression tests for wine, and after reading Francois' presentation, I thought perhaps a File I/O would be a good one to implement (especially since he mentions CreeateFile). So I began thinking about how to go about it, which led me to the following... Has any thought been given to creating a sandbox for regression tests? For instance, let's look at creating a test for File I/O. This requires creating/deleting files/directries, the ability to locate files, etc. But I don't see anything in the framework that lets me do this portably on all systems. In wine, I can't gaurantee that the test directory (which I could probably write to) is mapped to a Windows drive. On all platformes, I don't see how I can write to an arbitrary location on C:, since it may be unwriteable, and even if it's not, people probably don't want extraneous wine stuff littered around their drive when something goes wrong. I'm now thinking I'll try something more straight-forward as my first attempt, but this type of test seems like it'd be very useful, and I don't see how to do it with today's infrastructure. Ideas? Thanks, .Geoff ----------------------------------------------------- Protect yourself from spam, use http://sneakemail.com

2 1

winver & managed question
by Lonnie Cumberland March 23, 2002

March 23, 2002

Hello All, I have just been reading the docs on Wine and came across the --managed Allow the window manager to manage created windows --winver Version to imitate (win95,nt40,win31,nt2k,win98,nt351,win30,win20) Does the "--managed" allow my xserver to take care of the windows? Also, if I set "--winver nt2k" then does this mean that Wine will look for the specified directories in my /wine-c directory laid out the way that they actually are specified on a real Windows NT/2000 machine? That would be great if it did. Cheers, Lonnie -- Lonnie Cumberland OutStep Technologies Incorporated EMAIL: Lonnie(a)OutStep.com : Lonnie_Cumberland(a)yahoo.com The Basis Express Virtual Office & Data Backup and Recovery Services URL: http://www.basis-express.com "The Virtual Office without boundaries!!!"

2 1

Native Linux SO libraries
by Lonnie Cumberland March 23, 2002

March 23, 2002

Hello All, I have recently read in the Wine Docs that native Linux .so libraries can be loaded by wine and I think that this is wonderful. It means to me, if I have read everything correctly, that I can communicate with my linux kernel from within the wine windows environment correct? Also, does some one have an example .so and also an example windows test driver program that I can use to see how this is done? Any help would be greatly appreciated. Thanks, Lonnie -- Lonnie Cumberland OutStep Technologies Incorporated EMAIL: Lonnie(a)OutStep.com : Lonnie_Cumberland(a)yahoo.com The Basis Express Virtual Office & Data Backup and Recovery Services URL: http://www.basis-express.com "The Virtual Office without boundaries!!!"

1 0

RE: FW: cygwin/wine port
by Steven Edwards March 23, 2002

March 23, 2002

> What's the advantage of this? You'd still have to use the wine kernel > right? I'd loe to be able to get a relay trace from an app > running under > windows, but if you still have to use the wine kernel, there > isn't much > advantage is there? Yes, you see the problem and the limitations we currently have. The reason why this isn't 100% possible is because dll separation isn't complete. Have a look at the the internal Wineserver functions and the debugging code that the dlls depend on. This was discussed a little at wineconf. Patrik Stridvall is doing the MS_VC++ port of wine and I'm working on the mingw/cygwin port. Once wine can be built on these platforms it will be easier for us to find/fix WINEisms in the DLL's and work around/fix them. On platforms where we don't need a wineserver this is a bitch. I need to be able to build the wine dlls under mingw for ReactOS. ReactOS uses its own makefile/helper makefile system without GNU autoconf/automake. Rather then import the wine dlls as we have done in the past, hack on them for a while, then fight to merge changes back in, I want to do a clean port to cygwin/mingw that can upgraded independently of the rest of the ReactOS system. This helps us and this helps wine by giving wine another platform to work on and moving ReactOS along. ReactOS has a win32k.sys that provides the kernel mode portion of the NT-like win32 subsystem. What we are lacking on the ReactOS project is the user space side. The wine dlls provide this completion of the win32 subsystem. /* never mind that we don't have windowing working yet =P */ The way we have worked around the bugs in the wine dlls is that we have added support to our NTDLL.DLL for the debugging features of the wine portion of the Win32 subsystem. I don't know if this will work or not because well we don't have windowing working yet. Once DLL separation is complete, there should be nothing left in the DLL's other then the debugging stuff that will cause a issue with portability to any OS. Steven _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1