listview expert required (again)
another bug description for listview (native listview works as expected here) configuration : - a listview in autoarrange mode - adding item one after the other - say the first item is created with the selection (LVIS_SELECTED) - some more items are inserted without the selection - in some cases, the selection will move to the newly inserted item instead of remaining on the first item (likely some internal index is not recalculated in autoarrange mode) A+ -- Eric Pouech
Re: [ANN] Conformance testing campaign
It will not receive EXIT_PROCESS_DEBUG_EVENT, only EXCEPTION_DEBUG_EVENT first with ExceptionCode = STATUS_BREAKPOINT, then with ExceptionCode = STATUS_ACCESS_VIOLATION continually. it's likely the child process seg faults somewhere, and the test doesn't handle it. why the child seg faults is another story... A+ -- Eric Pouech
Re: Where to put static libs?
Juan Lang wrote: --- Eric Pouech <[EMAIL PROTECTED]> wrote: I'm in the process of rewriting the SMB code to use winsock name lookup and socket calls without NetBIOS first, and to fall back to NetBIOS (using the Netbios() function) second if that fails. beware that you cannot directly call wsock32 functions (nor netapi32) from ntdll. Ah! I wasn't aware of this. Why not? because we don't allow, in Wine, for (direct) circular dependencies on modules: wsock32 => kernel32 => ntdll you can always doit by handle, with LoadModule/GetProcAddress pair A+ -- Eric Pouech
Re: Where to put static libs?
I'm in the process of rewriting the SMB code to use winsock name lookup and socket calls without NetBIOS first, and to fall back to NetBIOS (using the Netbios() function) second if that fails. beware that you cannot directly call wsock32 functions (nor netapi32) from ntdll. I'd like to expose some SMB functions so that named pipes and files to UNC paths use the same library of SMB functions. A couple of netapi functions (NetServerEnum and NetShareEnum) need to create SMBs also, and I'd like to implement them--they can be used to implement "network neighborhood." if you really want to share the code, better implement the TDI interface to linkage points in ntdll and make netapi32 depend on it, but that may be a bit overkill for the moment. A+ -- Eric Pouech
Re: Where to put static libs?
Juan Lang wrote: Any advice on where to put code that needs to be shared by multiple dlls? I'm tweaking the SMB code right now, and I'd like to reuse it in netapi32 (to implement some of the Net functions) as in kernel32 (for CreateFile and CreateNamedPipe). I'm thinking a new directory in libs (libs/smb). Any better ideas? first of all, most code dealing with file/pipe opening will be moved from kernel32 to ntdll (at least the core) moreover, the SMB code (currently) is more a proof of concept than a full implementation of SMB (using SAMBA if possible would of course be preferred) the internal NTDLL interfaces for handling file systems are likely to evolve very shortly I also assume that you're referring (parly) to NetBios resolution if so, then copying the code might not be a wrong answer for now if not, please explain what you want to do in more details A+ -- Eric Pouech
Re: Really slow named pipes
Nope ;) I think there was a problem when you tried to attach that :-)
oops (took the file from the wrong dir...)
A+
--
Eric Pouech
Index: dlls/kernel/sync.c
===
RCS file: /home/cvs/cvsroot/wine/wine/dlls/kernel/sync.c,v
retrieving revision 1.36
diff -u -r1.36 sync.c
--- dlls/kernel/sync.c 18 Aug 2003 20:03:00 - 1.36
+++ dlls/kernel/sync.c 25 Aug 2003 18:38:18 -
@@ -1162,7 +1162,7 @@
/* from completion sakeness, I think system resources might be exhausted before
this happens !! */
if (hr == INVALID_HANDLE_VALUE) return FALSE;
-hw = CreateFileA(name, GENERIC_WRITE, 0, sa, OPEN_EXISTING, 0, 0);
+hw = CreateFileA(name, SYNCHRONIZE|GENERIC_WRITE, 0, sa, OPEN_EXISTING, 0, 0);
if (hw == INVALID_HANDLE_VALUE)
{
CloseHandle(hr);
Index: server/named_pipe.c
===
RCS file: /home/cvs/cvsroot/wine/wine/server/named_pipe.c,v
retrieving revision 1.26
diff -u -r1.26 named_pipe.c
--- server/named_pipe.c 18 Jun 2003 19:45:22 - 1.26
+++ server/named_pipe.c 25 Aug 2003 18:38:36 -
@@ -627,7 +627,7 @@
{
server->state = ps_idle_server;
reply->handle = alloc_handle( current->process, server,
- GENERIC_READ|GENERIC_WRITE, 0 );
+ GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE, 0 );
server->pipe->instances++;
release_object( server );
}
Re: Really slow named pipes
So the problem appears to be that in the new implementation, the write to the pipe is being blocked on every call, until a read has happened. What should be happening is that the write should only block if the pipe is full. Does that help someone know where to look? does this help ? A+ -- Eric Pouech bash: wine: command not found
Re: Console regression?
[EMAIL PROTECTED] wrote: 000a: get_console_input_info( handle=(nil) ) [snip] if (!console && !geterror()) set_error(STATUS_INVALID_PARAMETER); is directly responsible for the error. the error is more that the handle passed to get_console_input_info in the server is nil, so server cannot find the object for that the point is to know why you get a nil value for stdinput handle could you compare the two server traces before and after the trace ? TIA -- Eric Pouech
Re: listview expert required
implements what you described. thanks... works like a charm now impressive turn around time btw!! A+ -- Eric Pouech
Re: listview expert required
Dimitrie O. Paun wrote: On Fri, 22 Aug 2003, Eric Pouech wrote: some apps of mine needs this to get going: can someone with good listview knowledge confirm ? (or find the correct fix) -if (uView == LVS_REPORT && (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT)) +if (uView == LVS_REPORT /*&& (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT)*/) If you do this, you will be able to select a row in REPORT mode when you are not in LVS_EX_FULLROWSELECT, when you just click in a sub item. This is easy enough to test (I can't do it right now, sorry), and if that's how the native control behaves, then let's just get rid of it. What's the problem with your app? but here's the differences I get between running native Win98 comctl and Wine's builtin listview: multicolumn, in report mode, without LVS_EX_FULLROWSELECT extended style message concerned: NM_CLICK notification for left click in LV (mainly in a column for any subitem) native: iItem: always set to -1 iSubItem: set to the subItem of the column clicked builtin: iItem: set to the row number iSubItem: always set to 0 (Note: I don't like either the iItem value I get from the native DLL (didn't test LVM_GETITEMHITTEST information though) also, as a noted difference, in selection. Wine's only draws a dotted rect around the selected item (or row in full row select mode). In native, the rect interior is grayed if the control doesn't have the focus, and filled in blue if control has the focus. if everything goes smoothly full code of the app should be posted this weekend (app will allow, among other things, to enable/disable debug channels on any running wine app) A+ -- Eric Pouech
listview expert required
some apps of mine needs this to get going:
can someone with good listview knowledge confirm ? (or find the correct fix)
TIA
--
Eric Pouech
Index: dlls/comctl32/listview.c
===
RCS file: /home/cvs/cvsroot/wine/wine/dlls/comctl32/listview.c,v
retrieving revision 1.357
diff -u -r1.357 listview.c
--- dlls/comctl32/listview.c24 Jul 2003 00:03:13 - 1.357
+++ dlls/comctl32/listview.c22 Aug 2003 20:30:27 -
@@ -5822,11 +5822,11 @@
opt.x = lpht->pt.x - Position.x - Origin.x;
opt.y = lpht->pt.y - Position.y - Origin.y;
-if (uView == LVS_REPORT && (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT))
+if (uView == LVS_REPORT /*&& (infoPtr->dwLvExStyle & LVS_EX_FULLROWSELECT)*/)
rcBounds = rcBox;
else
UnionRect(&rcBounds, &rcIcon, &rcLabel);
TRACE("rcBounds=%s\n", debugrect(&rcBounds));
if (!PtInRect(&rcBounds, opt)) return -1;
if (PtInRect(&rcIcon, opt))
Re: wcmd patch
Eric Pouech wrote: Oleg Prokhorov wrote: Hello wine-patches, Changelog: Fixes two problems: GPF when no extension was specified. No handles were inherited in CreateProcess, all child console programs were silent the second part is wrong. a child process should inherit its parent input/output stream even if we don't inherit all the handles. But the bug still exist as of today. I'll look into it. after some more testing, it turns out Oleg was right (and his fix too). So, Alexandre could you commit the second part of this patch. Sorry for the noise A+ -- Eric Pouech
Re: wcmd patch
Oleg Prokhorov wrote: Hello wine-patches, Changelog: Fixes two problems: GPF when no extension was specified. No handles were inherited in CreateProcess, all child console programs were silent the second part is wrong. a child process should inherit its parent input/output stream even if we don't inherit all the handles. But the bug still exist as of today. I'll look into it. A+ -- Eric Pouech
Re: RFC: evolution of file management
Can't really answer your question, but on the kernel mailing list, There has been some discussion of whether these attributes should be exposed from mounted fat partitions: The fat fs maintainer has a patch, and is wondering what to do with it. (The patch exposes the fat attributes as extended attributes) See the thread titled "[RFC] ioctl vs xattr for the filesystem specific attributes". yup that would help (to expose FAT attributes) my only remark is that we need to open the file in order to get its attributes I wonder if there would be an impact performance wise -- Eric Pouech
Re: RFC: evolution of file management
Keith Matthews wrote: On Tue, 19 Aug 2003 23:48:53 +0200 Ferenc Wagner <[EMAIL PROTECTED]> wrote: Do we need attributes like hidden, system, etc? Feri. More to the point we need attributes to allow support of NT ACLs. I've been looking at the problem and progressing only very slowly, some of the problems are technical, others are nothing to do with Wine at all. At the level we are dealing with here the essential problems (for those who have not examined the issues) are :- Not all supported O/S s offer ACLs. Those that do support POSIX ACLs which do not map exactly to NT ACLs Even in Systems which do support POSIX ACLs there is no guarantee that all disc filesystems at any one host will offer it, Of the Linux filesystem types only XFS supports ACLs out of the box. Work is in progress for ReiserFS and due to start for JFS. There is a patch for ext2/3. One map currently favoured is to use ext2/3/Reiser for the root filesystem and XFS for (some of) the rest). All of the systems that do support ACLs use Extended Attributes to store them. I am still looking at limitations on number of EAs, but there is a possibility that an extreme case on NT may not be supported on Linux. Since I've not yet got round to looking at TrustedBSD there's potentially another can of worms there. My conclusion is that we do (regrettably) need a VFS layer to harmonise handling of all this lot and respond correctly when wine-ver is 9X. I think Wine's goal is to provide this kind of feature of top of what the underlying OS provides (this is also the case for DOS HIDDEN and SYSTEM attributes => there are not available in standard Posix FS, so are managed by wine(*)). So IMO, file (protected by ACL) access should be provided by the underlying OS. ACL manipulation (from windows to posix - even if 1003.1e hasn't been voted by POSIX) should be added (I'm not sure we have a 1:1 mapping anyway) however, I don't understand your remark about the winver 9x... IMO, if the Linux user mounts a NT partition with ACL (and has the proper privileges) it should run Wine on this partition rather transparently (except for ACL manipulation function) it's not my goal to support: - real FS mounting in wine => this is the job of the OS, not wine's - a real VFS (as Linux does) - the (V)FS I'm talking about is more related to adaptation (as you mention), but I'm not sure I got you right A+ (*) except files starting with a . which get the HIDDEN attribute -- Eric Pouech
Re: RFC: evolution of file management
Martin Fuchs wrote: Hello Eric, Hi Martin thanks for the comments the device concept will disappear and be replaced by a "path gate": in NT-Win32 name space, point where to convert from a NT-path to a Unix-path for example, assuming we have created a path-gate from \\??\c: to /mnt/windows, the NT-path \\??\c:\foo\bar will be transformed into the unix-path /mnt/windows/foo/bar It would be good to implement this "path gates" as near as possible like the way it is implemented in Windows NT/XP. This mapping is done using the NT object namespace. Object namespace is another virtual tree structure similar to a file system or the registry. It is accessed by functions like NtOpenDirectoryObject(), NtOpenSymbolicLinkObject(), NtQueryDirectoryObject(), NtQuerySymbolicLinkObject(), ... There has been a tool in the internet called "winobj.exe", with which you can examine this internal NT object namespace. However it is not compatible to XP, I don't know, if someone has yet updated it. But I do have a own program which can display it also for XP. Drive mapping is stored as symbolic links for example at "\GLOBAL??\D:". This links point to the partitions, like e.g. "\Device\HarddiskVolume3". There are also the ArcNames, which you can find in the NT bootloader config file "boot.ini". At "\ArcName\multi(0)disk(0)rdisk(0)" you can find another symbolic link to "\Device\Harddisk0\Partition0". I do know how it's implemented in NT. anyway, there are a few differences between ROS and Wine: - in common, we do need to have the same interface as Windows do. This only applies to interface living in user land. - kernel land is another matter. ROS needs to stick to NT's behavior, Wine needs to convert calls to what Unix does provide. - ROS needs to mount physical drives, Wine makes (it's the current implementation, this is open to discussion) part of the Unix file hierarchy visible from the windows part Regarding file support, the minimal things Wine need to do is: - support the same file naming as NT does (mainly the \??\ part of the NT name space), the rest is not absolutely needed. Currently, Wine does not implement a unique name space for all the objects (as NT does, using sub dir for some differenciation) but rather different name spaces - to allow the mapping from a NT path to a unix path, there are two simple ways to do it: => use all NT name space and somehow inject Unix file name space (/ and all the subdirs) in it => store the unix information (the path in the unix / hierarchy) as a specific attribute of the NT name space (at least the \??\ subtree) I chose the second approach (you're more proposing the first one) because I felt it was more suited to wine behavior. Concerning NTDLL's directory objects, I'm still wondering if we need (in Wine) to implement them. It's indeed needed in NTDLL's interface (object attribute for instance) and implements part of the "path gate" (especially some attributes like case sensivity in further lookups...). So, this is still part of the open questions I have (I may start without directory objects, and add them later on). One of the strength of current NT name space is the orthogonality which is used across all objects in NTDLL (for example, in handle management, or sending requests - thru IRPs - at all the objects). The good side is to be able to convert an operation on a file into an IRP which is send to the FS which handles the file, which can in turn send it or transform it to another part... As wine implements a more monolithic approach, and since we don't have this orthoganility available today, I'm not yet convinced we need to stick more to the NT behavior than what I described above as the minimal requirements. A+ -- Eric Pouech
RFC: evolution of file management
in the process of separating ntdll from kernel32, one of the next hurdle if the implementation of NtCreateFile. Since it's rather a core API, some thoughts are needed. Moreover, there are a few shortcomings in current file handling we might want to address. The goal of this small RFC is to: 1/ gather all known shortcomings of current file implementation 2/ propose some solutions and roadmaps for the implementation feel free to add your own remarks to these lists. 1/ shortcomings --- 1.1) no dynamicity in DOS drive management: user should be able, in his/her session(1), to either change the mapping of a DOS drive letter, or mount a SMB share somewhere...) 1.2) mounting should be done session wide and not process wide, and of course shared across processes 1.3) ntdll and kernel32 are not separated regarding file management 1.4) devices (vxd and DOS) management is still a hack 1.5) it may be necessary to introduce a notion of filesystem for some operations (open, read, write, seek, close, dir_enum, ioctl) in order to support several FS (unix, smb...) 1.6) poor management of ejectable devices 1.7) short/long file name conversion should be consistent (across several processes in the same session, across several sessions) Note: (1) a session is linked to a running instance of the wineserver 2/ proposal --- 2.1 "path gates" (target: 1.1, 1.2, 1.3/partly, 1.4/partly, 1.6/partly) all file names will be handled using the NT-style: + DOS paths (C:\foo\bar) into \??\C:\foo\bar + network paths (\\station\foo\bar) into \??\UNC\station\foo\bar + DOS device names (CON) into \??\CON + NT device names (\\.\PhysicalDrive0) into \??\PhysicalDrive0 + a VXD ?? (normally \\.\VFD) into \??\VFD the device concept will disappear and be replaced by a "path gate": in NT-Win32 name space, point where to convert from a NT-path to a Unix-path for example, assuming we have created a path-gate from \\??\c: to /mnt/windows, the NT-path \\??\c:\foo\bar will be transformed into the unix-path /mnt/windows/foo/bar the path-gate will hold the current options that the device currently does (case sensivity, fixed/removable...) path-gates will be stored in the server (they are session wide) management of VxD and devices could benefit from it: they could be path gates pointing to them selves (or nothing ?) 2.2 FS (target: 1.4/partly, 1.5/partly, 1.6/partly) I'm still wondering if we really need a FS (even a very simplistic one) in Wine 2.3 short/long file names (target 1.7) since current short file name management seems satisfactory, there's no need IMO to move short/long names conversion in the server -- Eric Pouech
Re: REGRESSION: environment variables no longer possible
Alexandre Julliard wrote: "Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: Actually it's just the format of the Wine config has changed. Now all environment variables should be surrounded by the percent signes (%HOME%), and are handled by the normal registry code. Alexandre has changed the sample config as well. Actually the format of the config has not really changed, most entries have been behaving that way for a long time already. I just made the drives part of the config behave like all the other entries. Attached patch is rather useless, but however it makes the old profile code be consistent with the new behaviour. A better approach is to completely remove environment handling from profile.c. Yes, I think environment handling should be left to the application. I (incendentally ) had the same patch in my tree that what Alexandre committed yesterday. I'll send the removal of env handling later on today. A+ -- Eric Pouech
Re: GetLastError strangeness with FindClose
You're missing my point (or maybe you're not and you just don't agree with me - in either case, let me make my point in a clearer way). If windows doesn't say it won't change the last error, we, as programmers, should assume that it might. In my experience, a large number of functions that set last error on failure set it to ERROR_SUCCESS on success. For the few that don't, I would consider this an oversight on MS's part, and I wouldn't expect it to exist in all implementations of a particular function (across OS versions). let's just test Alex small test program on various platforms and see what gives... A+ -- Eric Pouech
Re: GetLastError strangeness with FindClose
Kelly Leahy wrote: Your test doesn't make much sense. The call to FindClose should be done after you check the result of GetLastError, since FindClose change the last error to ERROR_SUCCESS if the close operation was successful. From your test results, it seems that the FindClose implementation on the version of windows you're using doesn't seem to do this. I would consider this a bug in windows, not a bug in Wine. If a programmer relies on this behavior, it's their fault, not MS's or Wine's fault that their code does not work AFAIK, it's never said that a successful function call should set the last error to 0. This only thing MS claims is that when a function fails, the last error is set to a error code explaining that error. Moreover, wine's goal is not to make a better design than windows, but to mimic windows behavior. So, if FindClose doesn't change the last error on success, wine should do the same (especially if some known program depends on it) A+ -- Eric Pouech
Re: dlopen libncurses.so in wineconsole (take 3)
Dimitrie O. Paun wrote: On August 14, 2003 10:00 pm, Mike McCormack wrote: +#ifdef HAVE_NCURSES_H +char *ncname = SONAME_LIBNCURSES; +#else +char *ncname = SONAME_LIBCURSES; +#endif Since we're doing this dynamically, shouldn't we also determine at runtime if we should use ncurses or curses? It would make a lot more sense, as we typically compile on one box, and run on another... it would be great, but that may be hard to do. some (n)curses functions are implemented as macros (and you don't know for sure which). So, a strong rule to be sure everything works correctly is to run with the curses package that the one you compiled with... A+ -- Eric Pouech
Re: GetLastError strangeness with FindClose
Alex Pasadyn wrote: So, it looks like somewhere in FindClose Wine is resetting the last error. I started digging through there and the functions it calls but I was unable to find where it was getting reset. Can anyone shed some light on this? Is there any way to break on that value changing? GlobalUnlock does set last error to 0 if it's unlocking the last lock. A+ -- Eric Pouech
Re: cab_G_00-pre1 (RFC)
Looking at msvcrt's code, it starts to look like a bit much. Take a peek at dlls/msvcrt/file.c, "_open" and "MSVCRT__sopen" functions to get an idea of what I was hoping to avoid. msvcrt does a lot more than you need (and also a bit more than the standard C library). Looking at dlls/kernel/file.c, somehow things are much simpler (!?). I will do some experimentation with "_lopen" and co. (and read the api doc on MSDN) but presumably -- hopefully, judging by the names -- the "_l" API's will be close enough to "_open" & co. to avoid some cut-and-paste development. Normally, the _l* API is very close to the C standard library, but moving to the win32 API is not too hard. If not... there's more than one way to skin a cat. Windows surely does provide lots of tools for this to happen A+ -- Eric Pouech
Re: cab_G_00-pre1 (RFC)
Dmitry Timoshkov wrote: "Eric Pouech" <[EMAIL PROTECTED]> wrote: Why don't you use _lclose, _lcreat, _llseek, _lopen, _lread, _lwrite exported from kernel32? except for _lopen which differs a bit from CreateFile, but why not using ReadFile, WriteFile, CloseHandle... Because they look too hard for Gregory... Did you read the whole thread? yes I did... but I don't so many differences between read and ReadFile... which is not as easy for open vs. CreateFile as I wrote A+ -- Eric Pouech
Re: cab_G_00-pre1 (RFC)
Dmitry Timoshkov wrote: "Gregory M. Turner" <[EMAIL PROTECTED]> wrote: One ritual is that you should not use msvcrt from other dlls, this will cause trouble with apps that use the Unix libc. Is it OK to do LoadLibrary/GetProcAddress, or is that equally problematic? Why don't you use _lclose, _lcreat, _llseek, _lopen, _lread, _lwrite exported from kernel32? except for _lopen which differs a bit from CreateFile, but why not using ReadFile, WriteFile, CloseHandle... A+ -- Eric Pouech
Re: Translating wine programs
[EMAIL PROTECTED] wrote: I've started with an easy thing, the wine clock, please let me know if I've done this properly. mostly yes. Don't forget to tag the string table as LANGUAGE LANG_ITALIAN, SUBLANG_DEFAULT A good way to test it (especially for resources in programs/ subdir) is to run the application with the correct locale, and you should see the interface in Italian. BTW, is properties valid in Italian (just wondering if you didn't forget to translate this menu) A+ -- Eric Pouech
Re: 5 Wine-Tests fail on FreeBSD 5.1
I think more that's a discrepency in OSS handling between linux & *BSD
(or a more subtle bug somewhere)
could you rerun with WINEOPTIONS="-debugmsg +wave,+dsound,+wavemap"
back from vacation...
the trace only shows a decent startup and a wait for incoming audio
packets, which never show up.
Let's take this further. I wrote to you/this list, about winedbg
crashing on startup _every_time_. And I suspect it's this TEB thingy (I
have no clue what a TEB is, but I really think something is broken
there).
a TEB is a thread environment block: a user land structure describing a
thread status. TEB is usually stored in a page, which is pointer by the
fs register. there's a field in the TEB which holds its linear address.
Hence, getting the linear address of a TEB is written fs:0x18.
Thread commutation (from a scheduler point of view) is (almost as simple
as) changing the value of fs (there's also stack switching, context
switching...).
Anyway, your back trace information don't absolutely show that the TEB
get screwed up. Since getting the TEB linear address is inlined, gdb
sure has a hard time getting the value from the stack (as it may get
overwritten by upper calls).
It doesn't mean however that TEB doesn't get overwritten. In gdb, you
should check:
1/ at thread startup, where TEB is located, and which is the value of fs.
2/ on each lookup, check if fs value changed, and if TEB struct at
address gotten from 1/ is still ok. You would want also to check that
LDT entry for fs is still correct.
Now back to "wine winedbg winemine".
it should be run as winedbg winemine
wait4: Interrupted system call
wait4: Interrupted system call
does this help ?
Index: ptrace.c
===
RCS file: /home/cvs/cvsroot/wine/wine/server/ptrace.c,v
retrieving revision 1.26
diff -u -u -r1.26 ptrace.c
--- ptrace.c6 May 2003 00:21:21 - 1.26
+++ ptrace.c15 Aug 2003 12:38:14 -
@@ -149,6 +149,7 @@
thread->unix_tid = -1;
thread->attached = 0;
}
+else if (errno == EINTR) continue;
else perror( "wait4" );
return 0;
}
A+
--
Eric Pouech
Re: Problem with wcmd in wineconsole ?
Sylvain Petreolle wrote: Using dos32a (free replacement of dos4gw) with wineconsole, I dont get any text output from it under wcmd. that's a regression in CreateProcess in IO inheritance Dan Kegel already complained about it a few days ago I'm working on it, there should be a patch this week-end A+ -- Eric Pouech
Re: DRIVE_GetUnixCwd and drives other than the current one
Troy Rollo wrote: It appears that Wine is storing and using a "current directory" for each DOS drive. According to some testing we have just done on Windows 2000 and Windows 98, Windows only stores a current directory for the current drive. We've just implemented the behavior you describe in ntdll. (except for the part on cd D: with curr drive already being D: which I'm not sure we have set correctly). However, kernel hasn't been updated (yet) to use ntdll for files & path related functions. This should be done in the coming week^H^H^H^Hmonths A+ -- Eric Pouech
Re: Is wine a debugger?
But yes, the Wine debugger loads as a new process only after a crash is detected. What is happening is the program is poking around in memory somewhere and seeing something different from what it expects. since we get a SIGTRAP more likely an int 3 instruction under windows (9x), if the program is run under a debugger, the debugger will get the interruption. some protection mechanism set their own exception handlers (allowed under 9x) to detect whether a debugger is present (the handler is called only if no debugger is present) so setting the windows version in wine to NT will let the program (if correctly designed) to use some other mechanism and you may succeed in running your program A+ -- Eric Pouech
Re: can't redirect stdout?!
Dan Kegel wrote:
Eric Pouech wrote:
Dan Kegel wrote:
OK, so with the normal X11 driver, you can no longer
redirect stdout from commandline apps under Wine;
the output just vanishes if you try to send it to a file.
it works just fine here (at least for simple programs).
does your program involves the creation of a child process, which
actually does this output (this may be indeed broken)
Not sure. It's ss.exe from MS Source Safe. Next time I
try it I'll check for child processes.
you could also try this patch to see if this helps
A+
--
Eric Pouech
Index: scheduler/process.c
===
RCS file: /home/cvs/cvsroot/wine/wine/scheduler/process.c,v
retrieving revision 1.225
diff -u -r1.225 process.c
--- scheduler/process.c 3 Jul 2003 18:23:10 - 1.225
+++ scheduler/process.c 12 Aug 2003 19:33:12 -
@@ -329,7 +329,10 @@
/* Create the process heap */
current_process.heap = HeapCreate( HEAP_GROWABLE, 0, 0 );
-if (info_size == 0)
+if (main_create_flags == 0 &&
+ process_pmts.hStdInput == 0 &&
+ process_pmts.hStdOutput == 0 &&
+ process_pmts.hStdError == 0)
{
/* This is wine specific: we have no parent (we're started from unix)
* so, create a simple console with bare handles to unix stdio
Re: can't redirect stdout?!
Dan Kegel wrote: OK, so with the normal X11 driver, you can no longer redirect stdout from commandline apps under Wine; the output just vanishes if you try to send it to a file. it works just fine here (at least for simple programs). does your program involves the creation of a child process, which actually does this output (this may be indeed broken) A+ -- Eric Pouech
Re: dlopen libncurses.so in wineconsole
Mike McCormack wrote: This patch doesn't include changes to configure. Run autoconf to regenerate it... several comments to this needed patch: 1/ in configure.ac why not checking also for curses if ncurses isn't present ? BTW, you can also remove the ncurses library lookup in configure.ac, we no longer need it. 2/ in curses.c some of the functions we use in curses.c can in fact be macros in some curses' implementations. According to my doc, this includes initscr, intrflush, nodelay, noecho. So, you could pass LOAD_FUNCPTR a boolean not to fail if the symbol is not found (for those functions), and not #define initscr to p_initscr if initscr is already #define:d +if( !WCCURSES_bind_libcurses() ) +return FALSE; you'd better return init_failed from the enum instead of a boolean here A+ -- Eric Pouech
Re: Once again: Wine without X?
Dan Kegel wrote: 29 CharLowerA 697b6 564 SystemParametersInfoA 697f8 387 LoadStringA 6981e 39 CharToOemA 69810 43 CharUpperA 697c4 418 OemToCharBuffA 697d2 300 GetSystemMetrics 697e4 I wish one day things could be made right... buffer upper/lower case manipulation has nothing to do with the windowing system... anyway, so it goes in Redmond. so an empty "None" graphical driver is the easiest way to go. That'd be nice. A commandline option would be optimal. .wine/config entries wouldn't be as useful, since sometimes you want to run them different ways, and editing one huge config file is a pain to script anyway. I don't think Alexandre would like the command line option (at least as it is) to the main wine executable, but that's another story. A+ -- Eric Pouech
Re: [RESENT]: Fixed winedbg example configuration
BiGgUn wrote: set to "Y" ? It's set to 'Y' that's (maybe) why it doesn't get overwritten... It's likely keys will be reordered if you set it to N A+ -- Eric Pouech
Re: [RESENT]: Fixed winedbg example configuration
BiGgUn wrote: did you wait for wineserver to terminate before checking they have not changed ? yep in your config, do you have [registry] "SaveOnlyUpdatedKeys" = "N" set to "Y" ? A+ -- Eric Pouech
Re: Serial comm overlapped IO problem
Rein Klazes wrote:
Hi,
Recent commits
http://www.winehq.com/hypermail/wine-cvs/2003/06/0232.html and
http://www.winehq.com/hypermail/wine-cvs/2003/07/0090.html
broke communication with my online banking program girotel.
does this patch help ?
A+
--
Eric Pouech
Index: dlls/ntdll/file.c
===
RCS file: /home/cvs/cvsroot/wine/wine/dlls/ntdll/file.c,v
retrieving revision 1.28
diff -u -r1.28 file.c
--- dlls/ntdll/file.c 11 Jul 2003 21:44:17 - 1.28
+++ dlls/ntdll/file.c 17 Jul 2003 18:36:23 -
@@ -401,6 +404,16 @@
ret = register_new_async(&ovp->async);
if (ret != STATUS_SUCCESS)
return ret;
+if (flags & FD_FLAG_TIMEOUT)
+NtDelayExecution( TRUE, NULL );
+else
+{
+LARGE_INTEGER timeout;
+
+/* let some APC be run, this may read some already pending data */
+timeout.s.LowPart = timeout.s.HighPart = 0;
+NtDelayExecution( FALSE, &timeout );
+}
return io_status->u.Status;
}
switch (type)
Re: [RESENT]: Fixed winedbg example configuration
BiGgUn wrote: I still agree with Alexandre here. Order of keys in registry doesn't matter when loading, moreover, next time wine exits, the keys get automatically reordered (and saved), How do you explain that keys stay in the same order i typed them ? did you wait for wineserver to terminate before checking they have not changed ? A+ -- Eric Pouech
Re: question about WINE MSVCRT
Jonathan Wilson wrote: I notice that WINE has a clone of MSVCRT. I also know that MSVCRT exports some C++ symbols. How does WINE and its clone of MSVCRT and its build system handle the differences in name mangling between MSVCRT and GCC? MSVCRT is the the C (and C++) run time library for MS Visual C/C++ compiler. It's not intended as gcc's CRT (which got linked anyway to any winelib program). A+ -- Eric Pouech
Re: Once again: Wine without X?
Dan Kegel wrote: OK folks, it's time for my semiannual "I need Wine to run a commandline program, but can't get it to work" rant. First try: just do a default installation of wine-20030709. Log: $ wine -- /dos/d/vss/win32/ss.exe Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: x11drv: Can't open display: $ echo $DISPLAY $ That should have worked, since ss.exe doesn't use any GDI functions. drivers are loaded for USER, not GDI. So the first question is where does ss.exe pull USER32.DLL from ? Is this the recommended way to run console wine programs without any $&[EMAIL PROTECTED] curses stuff kicking in and without X? wine pgm.exe if pgm.exe doesn't depend on user & gdi (but that's not your case). And is there a chance of setting this behavior on a program-by-program basis? AppDefaults appears to be keyed off the driver already, so is probably not able to say "these apps should not use x11drv or ttydrv". It wouldn't be very difficult to set the User32 Driver on a pgm per pgm basis. A+ -- Eric Pouech
Re: [RESENT]: Fixed winedbg example configuration
These are two separate changes: a) Wine's registry needs to preserve ordering (c++ builder, presumably among others) b) BiGgUn wants to reorder the winedbg lines for some reason. I'm not saying he's right (I don't understand why he wants to reorder things like that), but I am saying that if he is wrong, it's not because this would be reordered anyway. Basically, I'm not supporting his patch, I'm saying Alexandre's reason for rejection is wrong. I still agree with Alexandre here. Order of keys in registry doesn't matter when loading, moreover, next time wine exits, the keys get automatically reordered (and saved), so I don't understand the need of the key reordering. A+ -- Eric Pouech
Re: 5 Wine-Tests fail on FreeBSD 5.1
The Backtrace now looks like this:
(gdb) bt
#0 0x5c236783 in read () from /usr/lib/libc.so.5
#1 0x5c0b11ee in wait_reply (cookie=0x5d252d44) at ../../include/winnt.h:1622
#2 0x5c0b1483 in NTDLL_wait_for_multiple_objects (count=1, handles=0x5d252e10, flags=4,
timeout=0x0) at sync.c:580
#3 0x5c0b14d8 in NtWaitForMultipleObjects (count=1, handles=0x5d252e10, wait_all=0,
alertable=0 '\0', timeout=0x0) at sync.c:598
#4 0x5c096bab in WaitForMultipleObjectsEx (count=1, handles=0x5d252f44, wait_all=0,
timeout=4294967295, alertable=0) at ../../scheduler/synchro.c:134
#5 0x5c096a8a in WaitForSingleObject (handle=0x3c, timeout=4294967295)
at ../../scheduler/synchro.c:62
#6 0x5d00e1a7 in wodPlayer (pmt=0x0) at audio.c:1409
#7 0x5c0976f1 in THREAD_Start () at ../../include/winnt.h:1622
#8 0x5c0b16ab in SYSDEPS_StartThread (teb=0x5d253000) at sysdeps.c:141
In frame #6 I have these values:
(gdb) p wwo->msgRing
$4 = {ring_buffer_size = 64, messages = 0x5c363bf8, msg_tosave = 0, msg_toget = 0,
msg_event = 0x3c, msg_crst = {DebugInfo = 0x0, LockCount = -1, RecursionCount = 0,
OwningThread = 0x0, LockSemaphore = 0x0, SpinCount = 0}}
(gdb) p dwSleepTime
$5 = 4294967295
And the line number on frame 1 is bogus again:
I don't think so. Gdb displays the inline function (from winnt.h) which
is used in wait_reply... hence the output.
Perhaps FreeBSD uses different registers? (I really don't have a clue).
It should work the same as Linux here...
I think more that's a discrepency in OSS handling between linux & *BSD
(or a more subtle bug somewhere)
could you rerun with WINEOPTIONS="-debugmsg +wave,+dsound,+wavemap"
TIA
A+
--
Eric Pouech
Re: Help with Errors on Darwin
Pierre d'Herbemont wrote: #9 0x00692108 in LoadLibraryExA (libname=0x1 , hfile=0x16fb990, flags=0) at ../../loader/module.c:699 the libname value is strange (especially, if called in load_driver, with a buffer from the stack as libname)... so either the debugger reports bad values (which can be the case :-(, or this shall be the first thing to look after A+ -- Eric Pouech
Re: build wine as shared library
Bill Medland wrote: Where are they please? http://www.winehq.com/?issue=171 A+ -- Eric Pouech
Re: Running acrobat reader using wine
Mike Hearn wrote: It's trying to load Video For Windows. I don't know if wine emulates that or not, but you might be able to install it from an MS update somewhere, if you can find one. no, msvfw32 is loaded, it's the dependency on winmm that cannot be loaded. something is broken in your configuration. A+ -- Eric Pouech
Re: [RESENT]: Fixed winedbg example configuration
Jon Bright wrote: Alexandre Julliard wrote: "BiGgUn" <[EMAIL PROTECTED]> writes: Changelog: Reorder lines for a typical winedbg configuration. Your patch is wrapped; but anyway I don't see any reason to change that, keys are sorted when registry files are saved so the order doesn't matter. This needs to change, though - for example, the tool palettes in C++Builder appear in the wrong order because of this. I really don't see how changing the configuration (in a no op way) of the debugger would fix some window related issue elsewhere and if it's the case, it means something is severely broken in some other place => this is not the correct fix A+ -- Eric Pouech
Re: build wine as shared library
There is a patch from (http://www.openlinksw.com/mono/) to build wine as shared library. I would like to know if wine will be soon merge this patch? as a whole no (it will break lots of things in current wine). Maybe some parts could be merged, but the core will likely not be in wine. See the minutes of the latest (and first) wine tech meeting where the discussion took place. Is there an other way to embed ActiveX, or any windows component, like DirectX plug-ins, in Gnome application? try to make two different apps. A+ -- Eric Pouech
Re: 5 Wine-Tests fail on FreeBSD 5.1
Ulrich Spoerlein wrote: Now what exactly is this code waiting for? Why doesn't it get any data from fd 12? (And what are fds 12 and 13 (msg_pipe[0] and msg_pipe[1] anyway)? the pipe is used to synchronize messages between the main thread (the one which sends data to be played) and the player thread. Try to change dlls/winmm/wineoss/audio.c to not define USE_PIPE_SYNC and let us know if it changes something. A+ -- Eric Pouech
Re: Loader fix for pathes differing by extra backslashes
Mike McCormack wrote: Hi, The loader seems to have a problem with extra backslashes in module pathnames. If "c:\\windows\\system\\ole32.dll" is loaded and unloaded, then "c:\\windows\\systemole32.dll" is loaded, there will be trouble, as the loader does not recognise these two as the same module, yet dlopen does. Did you test what Windows does in that case ? (I also wonder where the double backslash comes from). A+ -- Eric Pouech
Re: Official MS symbol sets
Mike Hearn wrote: Hi, http://www.microsoft.com/whdc/ddk/debugging/symbolpkg.mspx I assume people have looked at this before - how easy are they to match up with Wine, and do people use them for debugging faults in native code? I never tested this before. It depends on which debugger you're using. WinDbg (the MS one) should be easy to use, but you'll miss the native part. WineDbg has some support for loading PDB files, but the latest formats are likely not to be supported, so YMMV. A+ -- Eric Pouech
Re: Doom Legacy / Problems with DOS & and winedbg
Sylvain Petreolle wrote: you shouldn't need to change the mode, why do you want to switch to mode 32 ? since it complains in vm86 mode, I tried something different (all the others :)) since the pc has changed between the two exceptions, I assume several int 21 take place in a row. yes, this is a dos prog... wich makes use of the long filename functions of win95. so, if you use cont at the second exception, you're stuck as for the first one. So, you should use pass if you want the execution to be correct (even the second time) this is why I tried to switch to mode 16/32, to have no more problem (do you know how many int calls are made in a dos prog ? ;) in that case, you can use a different technique. Add a DebugBreak(); call in the offending function, and run the program without the wine debugger. The first time the offending func will be used, the debugger will be opened (if this lets you go further without passing all the time) As of today, there's no automated way of passing N times, nor ignoring a given exception (we could add what gdb does: a mapping of behavior between a given exception (signal in gdb) and the behavior: enter debugger, pass exception, continue, exit...) A+ -- Eric Pouech
Re: Doom Legacy / Problems with DOS & and winedbg
Sylvain Petreolle wrote: Unfortunately, winedbg complains on the first int21 call : First chance exception: interrupt 21 in vm86 mode in vm86 code (00d4:045e). How can this be avoided ? do you get the winedbg prompt or not ? if so, 'pass' should do. This works, thanks. But the same error appears on the next interrupt call. I tried 'mode 16' and 'mode 32' but they seem to do nothing. I stay in vm86 mode. you shouldn't need to change the mode, why do you want to switch to mode 32 ? since the pc has changed between the two exceptions, I assume several int 21 take place in a row. so, if you use cont at the second exception, you're stuck as for the first one. So, you should use pass if you want the execution to be correct (even the second time) A+ -- Eric Pouech
Re: Doom Legacy / Problems with DOS & and winedbg
Sylvain Petreolle wrote: Trying to debug a problem into INT21_CreateDirectory, I want to run doom3.exe into winedbg. (DL tries to create the directory in %HOME%, set to /home/something... LOL) Unfortunately, winedbg complains on the first int21 call : First chance exception: interrupt 21 in vm86 mode in vm86 code (00d4:045e). How can this be avoided ? do you get the winedbg prompt or not ? if so, 'pass' should do. A+ -- Eric Pouech
Re: More Info and a call for help
Robert Lunnon wrote: I am having problems with this Program, Little Fighter II, and also the installer that comes with the Worms II demo, both internet downloadable. Anyway both of these faults might be due to stack overflows or overwrites, especially the Worms II one below. What variable controls the size of the stack allocated to a thread ? Hi Robert. Worms2 installer installs (more or less correctly) on Linux. So, this is likely a Solaris porting issue. Thread size is set when creating the thread, with some guard pages (but it should be at least 1 MB) the crash way be caused by a stack corruption (ie a function pops one dword too much). you could look at this with -debugmsg +relay. The Fault indicates that the exception occurs at eip 0xddb2484a: and the address of the fault indicates it also is at 0xddb2484a which would indicate that it had trouble fetching the instruction ??? insn is pop %es, so a wrong selector value on the stack will cause the exception A+ -- Eric Pouech
Info on windows server 2003 (new APIs)
http://msdn.microsoft.com/msdnmag/issues/03/06/WindowsServer2003/default.aspx well, not too many surprises here (most of the new APIs already existed in XP) A+ -- Eric Pouech
Re: Patch ntdll/kernel32: #27 take III, possible console regression
Jukka Heinonen wrote: It seems that this patch (ntdll/kernel32: #27 take III) makes console input handles use edge triggered semantics. Which means that these handles only signal when new input is queued and not when console input buffer has unread data. there's a bug but because I use a semaphore to keep track of input record queue len, but this semaphore is decremented twice: - a first time in the wait operation - a second time while actually reading an input event whereas it should be actually only decremented once (I'm still looking for my worn out brown paper bag) I'll send a fix later on today. -- Eric Pouech
Re: Localization to the Portuguese
Marcelo Duarte wrote: Hi, I intend to perhaps keep the support the Portuguese language and to other tasks. Please, in any modifications to the resources, it would like to be informed to translate them, because I can be the support to Brazilian Portuguese language in the Wine. good to have someone to this in charge... Alexandre, the portuguese of Brazil is slightly different of Portugal, but ALL files *Pt.rc that I encountered is brazilian portuguese (because "File" is translated to "Arquivo" in Brazil and to "Ficheiro" in Portugal, etc). The questions are: I need to separate them? Which is the correct behavior? Since there are differences, and if you're ready to support those different, then we can always create two sets of resources for portugese: one for portugese from Portugal, another one for brasilian portugese. Note, that windows consider Brasilian portugese to be the default sublang for all portugese:s (which seems to me a bit ackward, but South America is likely closer to Redmond than Lusitania...) A+ -- Eric Pouech
Re: ntdll/kernel32: #27
Alexandre Julliard wrote: Eric Pouech <[EMAIL PROTECTED]> writes: as I wanted console handles to be managed by wineconsole, it was cleaner IMO to let them be transparently handled on the client side If you really prefer in the long run to keep the handles managed by wineserver, then the server should manage them transparently I'm not sure I follow you. They can't be handled transparently on the client side, the client has to check for console handles in functions like ReadFile, and convert them to whatever is appropriate, whether that means a server handle or a wineconsole handle. So it seems much cleaner to always intercept console handles in the client, rather than intercepting some of them and passing others straight through to the server. Whether or not they turn out to be implemented in wineconsole ultimately is a different issue IMO. In the patch I sent you, the interception is made on the client side. By transparently, I meant the obfuscation/deobfuscation mechanisms. The full discussion we have is around passing console handles to the server. The client already intercepts any handle and checks whether it's a console handle or a regular ntdll handle. If it's a console handle, then implementation is passed to console functions (ReadConsole for ReadFile and so on). The discussion we have (at least as I understand it ;-), is whether we should manage, on the client side, console handles: - as obscure values passed by the server (except for the two low bits set to 1) (this is the current patch implementation) - or as regular winserver handles with the two low bits set to 1, which means cleaning up those bits before sending the handles to the server the transparency I was talking about referred to how the client should manage the handles if we had to move console handle creation out of wineserver A+ -- Eric Pouech
Re: ntdll/kernel32: #27
My objection is not so much the obfuscation itself (though I think it's safer to only touch the lower two bits), but the fact that the server knows about it. This handle manipulation must be purely client side, the server must not have to know about it at all; all handles passed to the server must be normal handles. as I wanted console handles to be managed by wineconsole, it was cleaner IMO to let them be transparently handled on the client side If you really prefer in the long run to keep the handles managed by wineserver, then the server should manage them transparently A+ -- Eric Pouech
Re: ntdll/kernel32: #27
Alexandre Julliard wrote: Eric Pouech <[EMAIL PROTECTED]> writes: - this patch partially implements this scheme. It's partial because console handles are still handled by wineserver. Their value is however obfuscated so that we can track their real usage. IMO you shouldn't need to have any obfuscation code in the server at all. If you need that, something is wrong with the design. I don't need the obfuscation at all (just setting the two lower bits of the handle to 1). I used obfuscation to make it easier to track bugs. I'll resubmit without the obfuscation macros. - next step would mean implementing the console handle management outside of wineserver (likely in wineconsole) I'm not convinced we really need that; IMO it's OK to keep them in the server, as long as we can identify them as console handles from the client. I was what I really wanted to move to wineconsole was the content of screen buffers (which are copied twice currently and which I find rather bad). Of course, we could split handle management and object management in two different locations (wineserver resp. wineconsole), but this will complicate things IMO and as any performance enhancement, it doesn't need to be done immediately (there are some other items to focus on) A+ -- Eric Pouech
Re: wineconsole init
PETREOLLE Sylvain wrote: Could we have settings that avoid the error message about ncurses ? To have working non-buffered keyboard input in dos programs, I must disable curses support. non buffered input should work the same way in either curses or user backends in wineconsole so removing the error message will not fix the real cause of the bug A+ -- Eric Pouech
Re: Process termination & exit code
Alexandre Julliard wrote: Eric Pouech <[EMAIL PROTECTED]> writes: as reported by Igor Sysoev on WD, exit process code wasn't properly implemented on *BSD it appeared (thanks Igor for all the testings and traces) that after terminate_process request was issued, the client/server pipe got closed because the running thread was actually killed, erasing the exit_code that terminate_process had set. This patch actually fixes it. I don't think we need a new thread state just for that; how about something like this? I agree that it would better without a new thread state But it seems that in the case of a process termination with ExitProcess(0), your proposal will never set the exit code to 0 and always return an exit code of STILL_ACTIVE. A+ -- Eric Pouech
Re: SoftICE for wine
Gerhard W. Gruber wrote: On Thu, 12 Jun 2003 18:51:52 +0200, Eric Pouech <[EMAIL PROTECTED]> wrote: what didn't you like in gdb and winedbg ? The interface is quite annyoing. A lot to type again and again. In pICE I have all the relevant information at one glance. I was also thinking of adding user space support, so that you can use pICE also as a normal debugger with a user space GUI. I think there may be already some support for such a feature but I didn't have time to look at all the code. try ddd (or kgdb) Also I didn't manage to get hardware breakpoints to work and I got no response on my question about this. what was the issue ? ROS port uses a specific device driver, which will be fun to implement in wine Could you tell me a bit more about this? it seems that pice in ros needs a specific device driver, I assume it : 1/ implements low level CPU management (ie fault detection...) 2/ implements some kind of terminal emulation (screen shall be shared between debugger and debuggee) (including screen & keyboard) which I think will be hard to implement (with pice current architecture) winedbg has been inspired by gdb, but it is not an extension of gdb (as a standalone debugger). But, you're may be talking of the proxy feature of winedbg which lets gdb talk to wine thru gdb's remote protocol Ah. Because of this I thought that winedbg would be a frontend like wdb. Only that it is no GUI frontend but a code frontend. that's why you can use any graphical frontend to gdb (which will then talk to wine thru winedbg) and gain every feature at once A+ -- Eric Pouech
Re: SoftICE for wine
Gerhard W. Gruber wrote: Three weeks ago I was trying to find a crash in Agent. Since I don't know the code of wine so well I tried to do this with a debugger. My experience was rather frustrating. GDB and winegdb are not exactly what I call userfriendly. On a Windows system I would have found this error within a few hours but I didn't come to terms with winedbg and gdb. So I was looking for an alternative and I found a project on sourceforge named pICE. what didn't you like in gdb and winedbg ? trying to port pice to wine would be rather an heavy task I don't really what you will gain with pICE > This project was abandoned about two years ago, but I was interested in it and now I got the administration for it. pICE is a kernel debugger for linux similar to SoftICE and I thought it would be nice to have such a tool. My intention is to add extensions to support wine debugging as well (this was my primary reason) and now I would like to know if this is would be of interest to you as well I personnaly don't see an interest. It's already a burden to maintain winedbg, so maintaining a second debugger doesn't seem right to me and if yes (what I hope :) ) what extensions are needed in order to support wine. ROS port uses a specific device driver, which will be fun to implement in wine > I guess that winedbg is similar in that respect that it is also an extension of gdb, am I right? winedbg has been inspired by gdb, but it is not an extension of gdb (as a standalone debugger). But, you're may be talking of the proxy feature of winedbg which lets gdb talk to wine thru gdb's remote protocol If somebody knows the details I would like to hear it. But don't expect anything soon because I still need to dig into the code of pICE to make it stable first. Again, I don't see what pICE will bring you that you don't have in gdb or winedbg. IMO, you should start by explaining this. A+ -- Eric Pouech
Re: Debuging Wine
When using "so" mode this error is generated. I added "_ftol" in libmsvcrt.so and that error is no longer generated. Is that right thing to do ? so is now obsolete... there's only choice between native and builtin A+ -- Eric Pouech
Re: Discovering which critical sections threads are in
The null ebp at the top is kind of odd, I think this stack might be the result of a demarshalled RPC call. But anyway. As you can see it's blocking on a critical section, but I don't know how to find out which thread has got suck inside it. I tried putting trace statements in Rtl(Enter/Leave)CriticalSection, oops, not a good idea, wy too much spew there to be useful. So, what I'd like to know is whether there is any way to find out which thread has entered that critical section. Also, is this even a good idea, or is there a better way to debug thread deadlocks? thanks -mike normally there's a message printed out when a critsect times out like: section 0x12345678 myCS wait timed out, retrying (60 sec) tid= and the tid gives you the thread id of the thread holding the cs then, you can use it for example in 'bt ' to get a backtrace of that particular thread and look at what it's doing A+ -- Eric Pouech
Re: WinHelp and reassigning bugs
however it says I can't CC or reassign it to him as the email address I used, [EMAIL PROTECTED], is not a valid bugzilla account. mu bugzilla account is pouech at winehq.com Basically, the guy has some details on the undocumented parts of how the winhelp protocol works.. except that the described problem is a pure window messaging issue, and is not winhelp related (winhelp uses WM_WINHELP and not the WM_HELP you're talking about) so the bug should be set in ui category, not winhelp A+ -- Eric Pouech
Re: winedgb problem
Raphaël Junqueira wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, i have bit problem with winedbg whil trying to debug Unreal2 demo ;( This game seems to use exception for error handling and at first exception it breaks, and after i try 'pass' or 'cont' and the games never continue (the dbg remains in exceptions stack) ;((( while running without winedbg i have no problem (well i crash later, and i want to debug this crash but unreal2 catch it, print the stack and exit) Have you an idea why ? no try walk except between each call to pass and check whether the seh frams change or not A+ -- Eric Pouech
Re: Wineconsole init
Sylvain Petreolle wrote: its in text format, fails the same way if I remove all html content. http://www.winehq.com/hypermail/wine-patches/2003/06/0093.html send me the text file you're patching with, I'll have a look at it A+ -- Eric Pouech
Re: Wineconsole init
[EMAIL PROTECTED] wine]$ patch -p0 <~/0093.html is the patch format html or text... if the former, then it'll likely fail A+ -- Eric Pouech
Re: d3d8 compile issues
Ann and Jason Edmeades wrote: Ok, I wonder if this change will do it for you: At the top of device.c #ifdef HAVE_GL_GLEXT_H #include #endif #ifdef HAVE_GL_GLX_H #include #endif Jason nope, doesn't work A+ -- Eric Pouech
Re: glext missing
Ann and Jason Edmeades wrote: Oops - Looks like a check got missed. Change the top of device.c to add: #ifdef HAVE_GL_GLEXT_H<--- Add this #include #endif< and this #include Note the #include may need to go inside the #ifdef. that won't be sufficient. In my case, I do have glext.h but I don't have glxext.h. Sounds like we need some further check (configure, GL versions ...) for glxext.h A+ -- Eric Pouech
Re: d3d8 compile issues
Ann and Jason Edmeades wrote: FYI If you are having problems compiling d3d8, add the following to d3d8_private.h after the APIENTRY #define /* Temporary hack for compile */ typedef void (APIENTRY * PFNGLSECONDARYCOLOR3FEXTPROC) (GLfloat red, GLfloat green, GLfloat blue); typedef void (APIENTRY * PFNGLSECONDARYCOLOR3FVEXTPROC) (const GLfloat *v); typedef void (APIENTRY * PFNGLSECONDARYCOLOR3UBEXTPROC) (GLubyte red, GLubyte green, GLubyte blue); typedef void (APIENTRY * PFNGLSECONDARYCOLORPOINTEREXTPROC) (GLint size, GLenum type, GLsizei stride, const GLvoid *pointer); typedef void (APIENTRY * PFNGLCOLORTABLEEXTPROC) (GLenum target, GLenum internalFormat, GLsizei width, GLenum format, GLenum type, const GLvoid *table); typedef void (APIENTRY * PFNGLPOINTPARAMETERFEXTPROC) (GLenum pname, GLfloat param); typedef void (APIENTRY * PFNGLPOINTPARAMETERFVEXTPROC) (GLenum pname, const GLfloat *params); Raphael - I'll let you fix this issue properly.. :-) Jason I've got some different issues. first, GL/glxext.h (included from d3d8/device.c) doesn't exist on my machine then, in d3d8/utils.c, GL_ALPHASCALE, GL_PRIMARY_COLOR, GL_CONSTANT, GL_PREVIOUS are not defined, causing some more errors A+ -- Eric Pouech
Re: GetExitCodeProcess always returns 1, nmake problem
Igor Sysoev wrote: In the mail list archive I saw that some people use wine to run nmake. I just wonder if they are able to build a complex ehough makefile without nmake's switch "-i". In my wine enviroment every program that nmake runs always returns exit code "1" and nmake terminates further building something like: - NMAKE : fatal error U1077: 'c:\vc\bin\cl.exe' : return code '0x1' Stop. - So to ignore exit codes I used to set nmake's switch "-i". I made small test case that show that wine always set exit code to "1" despite the passed value. Under Windows NT p1 outputs: - executed exit code: 0 - while under wine-20030508 on FreeBSD 4.3 p1 outputs: - executed exit code: 1 - this works just fine on linux could you rerun your test with -debugmsg +server and send me the log A+ -- Eric Pouech
Re: CreateFile("conin$") issue
Oleg Prokhorov wrote: Hello Eric, Tuesday, June 3, 2003, 2:54:46 AM, you wrote: EP> no, wine doesn't create a win32 console (which is needed by opening EP> conin$, which open the input of the win32 console attached to the EP> running process). running wine simply redirects the Win32 standard EP> handles to unix 0/1 (whatever they are) but doesn't create any console. What's the purpose of this separated functionality ? In the other words why wine doesn't open console by default ? because some people don't want a wine console and are looking for the standard unix one instead... using wineconsole (instead of wine) is the preferred way to go I've got some problems with wineconsole (latest CVS) and my Mandrake 9.1. EP> what type of problem ? it prints error message: err:wineconsole:WINECON_Init failed to init. first of all, do you have (n)curses installed ? if not, that's the issue if yes, could you send me a -debugmsg +server,+wineconsole,+console trace ? TIA A+ -- Eric Pouech
Re: msdos/int21 CREAT special cases
Ferenc Wagner wrote:
Eric Pouech <[EMAIL PROTECTED]> writes:
_lcreat16 (and al.) is in fact a 16 bit function, implemented in
krnl386. so, normally it wouldn't be accessible from 32 bit DLLs (we
can do it in some cases, but the least we do, the better it is).
So, if the same behavior (as _lcreat16) can be obtained with other 32
bit APIs (like _lcreat or CreateFile), that'd be better. Beware, that
_lcreat16 is different from _lcreat (search path order for example is
not the same).
Thanks for the clarification! Given the definitions
HFILE16 WINAPI _lcreat16( LPCSTR path, INT16 attr )
{
return Win32HandleToDosFileHandle( (HANDLE)_lcreat( path, attr ) );
}
HFILE WINAPI _lcreat( LPCSTR path, INT attr )
{
/* Mask off all flags not explicitly allowed by the doc */
attr &= FILE_ATTRIBUTE_READONLY | FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM;
TRACE("%s %02x\n", path, attr );
return (HFILE)CreateFileA( path, GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE, NULL,
CREATE_ALWAYS, attr, 0 );
}
I could easily change my patch to call _lcreat() or
CreateFileA() instead of _lcreat16(), but I am not sure if
that would be right, since the differences you mention do
not seem to be implemented, and I could not find any
documentation on them. In sight of this, what do you
recommend? The conformance tests do not show any anomaly in
the behaviour of _lcreat(), but it may be only that these
aspects simply are not tested.
you're right, I was in fact referring to the differences for
OpenFile between 16 and 32 bits. Replacing _lcreat16 by
Win32HandleToDosFileHandle( (HANDLE)_lcreat( should be just fine
A+
--
Eric Pouech
Re: CreateFile("conin$") issue
EP> for this call to work correctly, you must run your app in a console. EP> using wineconsole instead of wine should fix it Isn't there any way to make 'wine' work also ? no, wine doesn't create a win32 console (which is needed by opening conin$, which open the input of the win32 console attached to the running process). running wine simply redirects the Win32 standard handles to unix 0/1 (whatever they are) but doesn't create any console. I've got some problems with wineconsole (latest CVS) and my Mandrake 9.1. what type of problem ? A+ -- Eric Pouech
Re: kernel32 file operations and wildcard filenames
Rolf Kalbermatter wrote: those functions are likely to be rewritten RSN (and DOSFS_GetFullName may even disappear) So I'd suggest rather starting by writing test cases for those functions so we could use those tests when the rewrite is going to take place I see the point here. Any ideas about the timeframe? we need a rather step by step approach here, so the complete time frame could be several months. my point in previous mail was not to stay, stop all work on these issues, but rather be aware that some changes are underway. Help is making thoses changes happen is always welcomed ;-) > Is this about calling into NTDLL instead of implementing it all in kernel32? it depends wether the functionality exists in ntdll or not. for the move operation, we're likely to keep the existing framework: - check if source file exists - try to move it (calling ntdll.NtSetFileInformation with FileRenameInformation class) - this function will be implemented as a Unix rename - if it fails (different drive for example), then a pure copy will be implemented One question I have is how to proceed with those tests? Adding them all to the current wine tests would create serious troubles unless we fix the according issues in the already existing kernel32 functions as well, in spite of the coming rewrite. there's the wine_todo expression in tests which marks a test as passing on windows and failing under wine. that's the good way to do it (check that the test passes, here that a given error is reported while trying to move a file to a non correct filename) A+ -- Eric Pouech
Re: CreateFile("conin$") issue
Oleg Prokhorov wrote: Hello , I've been examining compatibility of OpenWatcom C/C++ compiler with Wine. And it works just fine except one thing. So I request for your help to eliminate it, it looks easy but covers wine client/server stuff, which is not so trivial. for this call to work correctly, you must run your app in a console. using wineconsole instead of wine should fix it A+ -- Eric Pouech
Re: msdos/int21 CREAT special cases
Ferenc Wagner wrote: Pouech Eric DMI AEI CAEN <[EMAIL PROTECTED]> writes: please stop using krnl386.exe export when possible (especially for dos emulation which is going out of kernel32/krnl386.exe combo). So, if CreateFile can do, please use it (ditto for any other krnl386 file related functions) this is needed for proper DLL separation _lcreat16 (and al.) is in fact a 16 bit function, implemented in krnl386. so, normally it wouldn't be accessible from 32 bit DLLs (we can do it in some cases, but the least we do, the better it is). So, if the same behavior (as _lcreat16) can be obtained with other 32 bit APIs (like _lcreat or CreateFile), that'd be better. Beware, that _lcreat16 is different from _lcreat (search path order for example is not the same). HTH A+ -- Eric Pouech
Re: Windows version handling
Thomas Charbonnel wrote: Hi, I reported a crash some days ago, triggered when WritePrivateProfileString is called with a NULL lpFileName. I was advised to test windows' behaviour, which I did. The call behaves differently on Win9x/Me and WinNT/2K/XP. Should I model the patch after this ? If yes, is there an internal Wine mechanism to deal with windows versions, or should I just call GetVersionEx ? it also depends on the behavior if, let say, Win9x crashed and Win NT don't crash and return an error code, then the simplest is to return the error code in all cases (and leave a comment in the code noting the difference with Win 9x) if the differences are more important, then more advanced techniques should be used A+ -- Eric Pouech
Re: Implements languagegroups functions
I wonder if it's possible to force GCC 3.2 to act as a C97 compiler.. It could be used in Wine's configure script to prevent breakage on us poor GCC 2.95.X compilers :-) -std=gnu89 A+ -- Eric Pouech
Re: RtlAtom tests improved
György 'Nog' Jeney wrote: I figured out that the RtlCreateAtomTable function as expecting to get passed in a NULL as the initial Table, otherwise it thinks that the argument is a valid atom table and just returns success. This unfourtuneatly makes the test results that Dimitrie send useless because RtlCreateAtomTable thought I realy did mean Dimitry. didn't you actually mean Dmitry ? ;-) A+ -- Eric Pouech
Re: valgrind for WINE
Apart from the duplication of the signal mechanism, it also introduces races, since we depend on the client to do part of the suspend code. It means the server state will not necessarily match the actual state of the client thread, which could cause trouble. I'm still not convinced we want that in the standard tree. looking at VG MLs, it seems that there's already some ongoing work (http://www.goop.org/~jeremy/valgrind/ get to #77) which would provide a better signal handling, so this might be a way to get through that (I didn't test it though) A+ -- Eric Pouech
Re: OSS Bug
Rod Taylor wrote:
By default it seems to return EINVAL.
Line 953
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/sound/pcm/dsp.c?annotate=1.62
so something like this should do.
A+
--
Eric Pouech
Index: dlls/winmm/wineoss/audio.c
===
RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/wineoss/audio.c,v
retrieving revision 1.81
diff -u -r1.81 audio.c
--- dlls/winmm/wineoss/audio.c 17 Mar 2003 00:00:53 - 1.81
+++ dlls/winmm/wineoss/audio.c 3 Apr 2003 19:47:39 -
@@ -278,7 +278,11 @@
/* turn full duplex on if it has been requested */
if (ossdev->open_access == O_RDWR && ossdev->full_duplex) {
rc = ioctl(fd, SNDCTL_DSP_SETDUPLEX, 0);
-if (rc != 0) {
+/* on *BSD, as full duplex is always enabled by default, this ioctl
+ * will fail with EINVAL
+ * so, we don't consider EINVAL an error here
+ */
+if (rc != 0 && errno != EINVAL) {
ERR("ioctl(%s, SNDCTL_DSP_SETDUPLEX) failed (%s)\n", ossdev->dev_name,
strerror(errno));
goto error;
}
Re: valgrind for WINE
a small contribution (for valgrind) to get current wine running
Adam, I think it would be better if you get all those changes together
for inclusion in vg, if you don't mind
A+
--
Eric Pouech
Index: vg_syscalls.c
===
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_syscalls.c,v
retrieving revision 1.25
diff -u -r1.25 vg_syscalls.c
--- vg_syscalls.c 24 Feb 2003 21:55:34 - 1.25
+++ vg_syscalls.c 2 Apr 2003 19:39:40 -
@@ -647,6 +661,14 @@
break;
# endif
+# if defined(__NR_gettid)
+ case __NR_gettid: /* syscall 224 */
+ /* pid_t gettid(void); */
+ MAYBE_PRINTF("gettid ()\n");
+ KERNEL_DO_SYSCALL(tid,res);
+ break;
+# endif
+
# if defined(__NR_setxattr)
case __NR_setxattr: /* syscall 226 */
/* int setxattr (const char *path, const char *name,
Re: valgrind for WINE
the reason msvcrtd is there is that you need to use it for valgrind to do any checking of the heap - an instrumented malloc (see the changes to ntdll/heap.c) is required to tell valgrind that freshly allocated blocks are uninitialized, and the freed blocks are now invalid. IMO you need msvcrd for running under wine a windows program compiled with both DEBUG turned on, and linking to MSVCRT you don't need msvcrtd at all to run, say, a winelib program with valgrind enabled (I assume this comes from the fact you did most of the testing with a wine running a windows app which has been compiled with the DEBUG flag on) anyway, that's pure semantic. I doesn't change the real benefit behind: being able to run wine under valgrind !! on a more minor side of things, I would keep the VALGRIND prefix in heap.c not sure what you mean here, but the heap.c stuff appears to have been committed (slightly rewritten by the look of it...). To be of ANY use you need the MSVCRTD stuff as well though! basically, partly what Alexandre did to your patch => keeping the code (and macros) which are valgrind related being prefixed with VALGRIND last point, using the .vg extension to the wine script may not be optimal. it won't work (as it is written) for winelib programs (which got started also thru the wine script) one solution would be (to follow your idea) to link (for a winelib app called foo) foo.vg to script wine (and change your rule something like *.vg|*/*.vg). another option would be to embed this support as an option to the wine script (like --valgrind) maybe, this was just a hack to make it easier to use "in tree". not sure people would want a "--valgrind" switch in a (presumably) production winelib piece of software - it would show the world all your bugs ;-) sure!!! that's why putting it in a file external to winewrapper might be a good solution too (lile the .winewrapper) A+ -- Eric Pouech
Re: OSS Bug
Rod Taylor wrote: Found something related: http://news.gw.com/freebsd.bugs/22626 According to it, FreeBSD doesn't have that ioctl as it's always on. what errno value do you get when the call fails ? I'd suggest we ignore the error if ioctl returns -1 with this specific errno (if possible) A+ -- Eric Pouech
Re: valgrind for WINE
Adam Gundy wrote: a new version of the valgrind patch has been uploaded to sourceforge - the only change is a small fix to the signal handling which should prevent "signal handler frame" uninitialized errors. http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46268&atid=445588 comments? bug reports? success stories? did test it yet. As a global note, I think it would be appreciated breaking the patch in smaller bits... it makes it easier to track/follow what happens. For example, I don't see any reason for including the msvcrtd patches into this patch I think that Alexandre is currently integrating (bit per bit) your changes into wine. look for the patch about zeroing the request zones (which is another implementation of your structure packing), as well as local availability of the thread PID on a more minor side of things, I would keep the VALGRIND prefix in heap.c last point, using the .vg extension to the wine script may not be optimal. it won't work (as it is written) for winelib programs (which got started also thru the wine script) one solution would be (to follow your idea) to link (for a winelib app called foo) foo.vg to script wine (and change your rule something like *.vg|*/*.vg). another option would be to embed this support as an option to the wine script (like --valgrind) how are your patches doing on the "other side" (I mean valgrind's) ? A+ -- Eric Pouech
Re: Debugging winedbg
Ulrich Spoerlein wrote:
Can anyone please explain this to me?
every module (in the Wine sense) is create with a .init section. the
code in this section is executed as soon as the module is loader (by the
ELF loader). But the code in this section expects a bit of Wine
environment to be already present (basically the wine executable)
with preloading the .exe.so file, this code gets executed with the wine
executable being loaded
And what would be the easiest way to break into gdb on DEBUG_MainLoop?
add a breakpoint instruction at the start of DEBUG_MainLoop code
__asm__("int 3"); would do
A+
--
Eric Pouech
Re: Some shell32 questions and pictures
Steven Edwards wrote: Hello, I was taking a look at the current shell32 sources from winehq and trying to see if we needed to merge in the reactos shell32 fork stuff. We have forked a small part of shell32 to be able to run the control panel application with our own dll. After doing some testing I wanted to see from you guys if our implementation was right and if it would be accepted to the winehq tree. I was wondering if this really needs to go in to the shell32 or in to the explorer clone. IMO, both are wrong. Rendering of control panel should be done in EXPLORER, looking at the ControlPanel folder. However, the shell folder for the control panel should be finished (which I'm not sure it is ATM) A+ -- Eric Pouech
Re: PATCH: /dlls/ntdll/cdrom.c -- portability breakage
Alexandre Julliard wrote: Gerald Pfeifer <[EMAIL PROTECTED]> writes: How about the following patch? It's needed for compilation on FreeBSD; in case it's not correct, how should we solve the problem? I think the code is wrong, we shouldn't store a Linux-only define in a Windows structure, we should use a Windows define. Any one knows what the right value should be? the code is wrong (evil cut & paste IMO). we should use IOCTL_CDROM_CURRENT_POSITION in FormatCode A+ -- Eric Pouech
Re: [ANN] Wine @ SourceForge
Dimitrie O. Paun wrote: On March 23, 2003 01:50 pm, Eric Pouech wrote: I think we need to define clearly what is going to appear on winehq on one hand, and on SF on the other hand: - which parts/info... are only be hosted on winehq - which parts/info... are only be hosted on SF - which parts/info... are only be hosted on both For now things are pretty clear: -- the "Home" on SF points to www.winehq.org -- we are going to store only downloadable files on SF: - official tarballs - 3rd party support files that we can distribute - as many binary packages as possible (currently, we have binary packages for Debian and Suse, but the respective maintainers have not voiced their opinion on the matter). -- the other SF features (mailing lists, CVS, bug tracker, patch tracker, etc.) are not currently used. However, I will try to monitor the bug & patch tracker in case people start using them. Did I leave anything out? my point was really to ensure that winehq.org will remain the focal point for wine. this seems to be the case for now (but "for now" can always change) A+ -- Eric Pouech
Re: [ANN] Wine @ SourceForge
Dimitrie O. Paun wrote: Hi folks, Some of you probably know that we had a wine project at SourceForge for a long time, but not much was done with it. Recently, we decided to transform it into our official download site: http://sourceforge.net/project/showfiles.php?group_id=6241 It currently hosts source tarballs, support files, and binary packages for FreeBSD, RedHat, and Slackware. Check it out. We invite comments, criticism, and/or praise :). I think we need to define clearly what is going to appear on winehq on one hand, and on SF on the other hand: - which parts/info... are only be hosted on winehq - which parts/info... are only be hosted on SF - which parts/info... are only be hosted on both since, the revamp of winehq is taking place, it may be worthwile to explain this split a little bit more I'm also worried about the sort of trouble we had to maintain all RPM/DEB/... available on winehq, so what's going to change (for good) on SF A+ -- Eric Pouech
Re: PATCH: Implement some missing stuffs (reformated)
BigBun wrote:
your reformating is wrong (the long lines are wrapped)
case TCM_SETPADDING:
- FIXME("Unimplemented msg TCM_SETPADDING\n");
+ TabCtrl_SetPadding (hwnd, wParam, lParam);
return 0;
this is wrong...
TabCtrl_SetPadding is defined as:
#define TabCtrl_SetPadding(hwnd, cx, cy) \
(void)SNDMSGA((hwnd), TCM_SETPADDING, 0, MAKELPARAM(cx, cy))
so, this code will resend the TCM_SETPADDING while processing the
TCM_SETPADDING
-get_server_window_text( hwnd, lpString, nMaxCount );
+get_server_window_text( hwnd, lpString, nMaxCount );
you could also clean up your patch and remove the no op diffs
A+
--
Eric Pouech
Re: wine/controls scroll.c
Alexandre Julliard wrote:
ChangeSet ID: 7402
CVSROOT:/opt/cvs-commit
Module name:wine
Changes by: [EMAIL PROTECTED] 2003/03/07 14:38:20
Modified files:
controls : scroll.c
Log message:
Andrew Johnston <[EMAIL PROTECTED]>
- GetScrollRange zeros the return parameters for no infoPtr
- GetScrollRange, GetScrollPos and GetScrollInfo send a message to the
window for the SB_CTL case
- Moved code for GetScroll* to into worker functions
@@ -1736,22 +1804,18 @@
* RETURNS STD
*/
BOOL WINAPI GetScrollRange(
-HWND hwnd, /* [in] Handle of window */
-INT nBar, /* [in] One of SB_HORZ, SB_VERT, or SB_CTL */
-LPINT lpMin, /* [out] Where to store minimum value */
+HWND hwnd /* [in] Handle of window with scrollbar(s) */,
+INT nBar /* [in] One of SB_HORZ, SB_VERT, or SB_CTL */,
+LPINT lpMin /* [out] Where to store minimum value */,
LPINT lpMax /* [out] Where to store maximum value */)
{
-SCROLLBAR_INFO *infoPtr;
+TRACE("hwnd=%p nBar=%d lpMin=%p lpMax=%p\n", hwnd, nBar, lpMin, lpMax);
-if (!(infoPtr = SCROLL_GetScrollInfo( hwnd, nBar )))
-{
-if (lpMin) lpMin = 0;
-if (lpMax) lpMax = 0;
-return FALSE;
-}
-if (lpMin) *lpMin = infoPtr->minVal;
-if (lpMax) *lpMax = infoPtr->maxVal;
-return TRUE;
+/* Refer SB_CTL requests to the window */
+if (nBar == SB_CTL)
+return SendMessageA(hwnd, SBM_GETRANGE, (WPARAM)lpMin, (LPARAM)lpMax);
+else
+return SCROLL_GetScrollRange(hwnd, nBar, lpMin, lpMax);
}
This patch is wrong the hwnd is in fact a 16 bit window
I've an old win16 app which got broken because of this (wParam got
truncated to a 16 bit value, and of course caused a segfault)
A+
--
Eric Pouech
Re: Regression in latest CVS
Vitaliy Margolen wrote: I got CVS from 3 days ago. No problem there. I'll try to get CVS from 2 days ago & see what's gonna happen. thx, the fix has just been sent to wine-patches A+ -- Eric Pouech
Re: Regression in latest CVS
Vitaliy Margolen wrote: I have a problem with latest CVS in the past several days. Every app locking up. Any suggestions where should I look. It's not a dead loop. Something happening, according to trace. two points: - are you sure you properly recompile all wine files ? (at least regenerating the depends after the cvs update) - try to run the program under a debugger (even gdb if winedbg fails) so that we get a proper stack trace when the program segfaults (in your case, the program has its own fault handler which covers with more smoke the issue) (or try using another application) A+ -- Eric Pouech
Re: #1336: Delete a read-only file says not found
Sylvain Petreolle wrote: Trying to delete a read only file with wcmd actually should fail, option is not yet implemented. But it fails abnormally : it says that the file isnt found. A first test is done to see if no handle can be obtained, it passes. If I enable the --debugmsg +file it returns a GLE 2 fault. (file not found). Comments ? it works as expected here, get an access denied error can you really access your directory (what does wcmd's dir do ?) A+ -- Eric Pouech
Re: wine/loader module.c
> Note that before we go about fixing that we need to check all the callers in Wine, there are many places where we don't expect that behavior. ok, I'll take a look at that Also the GetLongPathNameW call won't do the right for a short buffer either. yes, MSDN is not very clear about what is done when the buffer is too small (actually writting the string or not... which it doesn't when the buffer is too small, in opposition to GetModuleFileName) I only wish that MS could at least be consistent in their API definition, but that's may be too much to be asked A+ -- Eric Pouech
