January 2006 - Wine-Devel - list.winehq.org

Re: setupapi: unimplemented function setupapi.dll.SetupPromptReboot

by James Hawkins

On 1/28/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > > Of course, but I was talking about the code, not the data. :) > As for FileQueue handling I prefer to leave this case as a stub for a > while. > If it makes the case your working on work, then it can be left out till later. Are you working on an app that calls this function? > BTW, James, maybe are you were working on this function by yourself > already? > Na, I'm working on SetupGetInfInformation and related query functions as a fix for bug 4355, but after I get these in I'm heading back to advpack. -- James Hawkins

Jan. 28, 2006

Re: setupapi: unimplemented function setupapi.dll.SetupPromptReboot

by James Hawkins

On 1/28/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > > > > I looked at the ReactOS implementation and saw that it was #ifdefined > > out, so I also assumed that wasn't code we should be porting back to > > Wine. Steven's comments verify this. > > Do they? Steven talks about ReactOS, not about Wine. If you really want to know if it's OK to copy it from ReactOS into Wine, ask Steven specifically. Otherwise you can try it out and see if it works. > Then we can simply remove #if 0 and be fine. No? No, you'd have to add the string resources for the shutdown message. You'd also have to add handling for the FileQueue parameter because it's missing in ReactOS. > > I think we still should able to test the reboot, only that this requires > new functionality to be added to winetest*.exe application: winetest > should be able to interrupt its execution, then it should resume it after > the reboot. IMHO that's not impossible. > If there's enough demand for that functionality, then eventually someone would implement it, though in the case of SetupPromptReboot there are enough ways to test the function without rebooting that reboot testing functionality would be extraneous. A simple way to implement such a feature without having to change the test framework is like so: 1) Add the current test executable to the RunOnce key. 2) Create a test-specific reg value, say DidReboot, that is set to 1 if we reboot. 3) Before calling the function to actually reboot, check the DidReboot value. If it's 1, set it to 0 and skip the reboot call, else set the value to 1 and reboot. -- James Hawkins

Jan. 28, 2006

Re: setupapi: unimplemented function setupapi.dll.SetupPromptReboot

by Saulius Krasuckas

* On Fri, 27 Jan 2006, James Hawkins wrote: > * On 1/27/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > > > > James, I wasn't asking about how should I hack on unimplemented > > function. My interest is focused on work of another guys, which is > > done already. :) > > I based the assumption on your statement, "I stuck upon this function > right now." Yeah, I mean my debugging process has been halted due to a stubbiness (not due to lack of devel-instructions). > You said you were stuck, so I offered suggestions on how to move > forward. OK, next time I will declare I have read the Wine Developers Guide and have been following wine-devel list for a two years already. ;-) > I looked at the ReactOS implementation and saw that it was #ifdefined > out, so I also assumed that wasn't code we should be porting back to > Wine. Steven's comments verify this. Do they? Steven talks about ReactOS, not about Wine. I think Wines ExitWindowsEx() is doing fine for Wine needs. Then we can simply remove #if 0 and be fine. No? > > BTW, how would you ensure that the testing of this function succeeds > > if you pass the flag to it which reboots the machine and probably > > kills the test-process? ;-) > > I was suggesting you write tests for your own testing, not adding unit > tests to Wine's test suite, OK, now I get you, thanks. :) > You won't be able to test a successful reboot in Wine's test suite, but > you can test it with your personal tests. I think we still should able to test the reboot, only that this requires new functionality to be added to winetest*.exe application: winetest should be able to interrupt its execution, then it should resume it after the reboot. IMHO that's not impossible.

Jan. 28, 2006

Re: Win32HandleToDosFileHandle / DosFileHandleToWin32Handle

by Eric Pouech

> I suppose one could do something in the VDM process to mark the file > handles as having multiple references, and then do proper open / close > handling. But that would require a valid JFT anyway. yes, what's currently missing is the JFT layer... one can consider that the Win32HandleToDosHandle (and its friends) to handle the SFT, and allow to bridge between the DOS world and the Win32 world. > So th JFT gives a way to update a reference count in the SFT. but, you'll have to patch every possible file usage in winedos so that you don't mixup sft indexes and jft indexes... > Another place where I think it'll come in handy is for redirection, > where it'll allow for stashing an equivalent of the device info word. > I think this'll make some of the console handling a bit better. you mean regarding the char / block caps for example? not sure we need to store that in the SFT, we can get it back from the win32 handle anyway. A+ -- Eric Pouech

Jan. 28, 2006

NetUserEnum

by suppandi

Hi, I was trying to run notes7 and it was crashing because NetUserEnum() was not implemented. So i tried writing a simple implementation. Could anybody have a look at this, and tell me whats wrong. Now notes just crashes without any doc. unfortunately i amn't a windows programmer to write a simple program to make the call. NetUserEnum(LPCWSTR servername, DWORD level, DWORD filter, LPBYTE* bufptr, DWORD prefmaxlen, LPDWORD entriesread, LPDWORD totalentries, LPDWORD resume_handle) { struct USER_INFO_20 { LPWSTR usri20_name; LPWSTR usri20_full_name; LPWSTR usri20_comment; DWORD usri20_flags; DWORD usri20_user_id; }; switch(level) { case 20: { struct USER_INFO_20 *data; char user[]={'t','e','s','t'}; NetApiBufferAllocate(sizeof(struct USER_INFO_20), (LPVOID *) bufptr); data = (struct USER_INFO_20 *)malloc(sizeof(struct USER_INFO_20)); data->usri20_name = (LPWSTR)malloc(20); memcpy((void*)data->usri20_name,user,4); data->usri20_full_name = (LPWSTR)malloc(20); memcpy((void*)data->usri20_full_name,user,4); data->usri20_comment = (LPWSTR)malloc(20); memcpy((void*)data->usri20_comment,user,4); data->usri20_flags = UF_NORMAL_ACCOUNT; data->usri20_user_id = 1000; *entriesread = *totalentries = 1; return 0; } break; default: FIXME("(%s,%ld, 0x%ld,%p,%ld,%p,%p,%p) stub!\n", debugstr_w(servername), level, filter, bufptr, prefmaxlen, entriesread, totalentries, resume_handle); return ERROR_ACCESS_DENIED; break; } }

Jan. 28, 2006

Re: Win32HandleToDosFileHandle / DosFileHandleToWin32Handle

by Derek Fawcus

On Fri, Jan 27, 2006 at 09:24:13PM +0100, Eric Pouech wrote: > Derek Fawcus wrote: > > I'm looking to do some changes to the wine vdm - or more accurately > > to the winedos dll to make the handling for some DOS applications > > more useful. This is mainly driven from a desire to run DOS apps > > without a wineconsole, so using the unix stdin/stdout/stderr as > > the DOS file handles. i.e. ala the BSD doscmd program; mind it > > also has similar issues (plus I'd have to port it :) > > > > There are a few things I'll have to alter wrt to the existing console > > handling (within winedos), but the main part will be using the JFT > > within the PSP/PDB and creating SFTs. > not sure what you're exactly trying to achieve. > why do you need this ? do you really have programs peeking inside the > JFT/SFT structures ? It's not the peeking, it's to make some other emulation more accurate. I don't anticipate making the SFT look like the DOS SFT, or even having it visible to the DOS/win16 program. It'll be an abstraction within the VDM which is equivalent to a SFT. At the moment, if program 1 opens a file, execs program 2 and then program 2 closes the file, program 1 will no longer have a valid file handle. Or at least that's how I read the code, since there does not seem to be any increment of a reference count across the DOS int 21/4b. I suppose one could do something in the VDM process to mark the file handles as having multiple references, and then do proper open / close handling. But that would require a valid JFT anyway. So th JFT gives a way to update a reference count in the SFT. Another place where I think it'll come in handy is for redirection, where it'll allow for stashing an equivalent of the device info word. I think this'll make some of the console handling a bit better. So at the moment, I'm thinking of something like: struct pseudo_SFT { WORD refcnt; HANDLE win32_file_handle; WORD device_info_word; }; There are also othe bits of the int21.c code which could be simplified if the above existed (possibly by adding more fields). DF

Jan. 28, 2006

Re: setupapi: unimplemented function setupapi.dll.SetupPromptReboot

by James Hawkins

On 1/27/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > * On Fri, 27 Jan 2006, James Hawkins wrote: > > * On 1/27/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > > > > > > Is anyone working on this for Wine? > > > Any ideas about the ReactOS code? > > > > Read through it thoroughly and make note of all the details of the > > function. Then write as many test cases as you can for the function. > > Test the details you found on msdn and any other cases you can think of. > > This should give you a better idea of how to implement the function > > because you'll understand what needs to happen for each particular case. > > James, I wasn't asking about how should I hack on unimplemented function. > My interest is focused on work of another guys, which is done already. :) > I based the assumption on your statement, "I stuck upon this function right now." You said you were stuck, so I offered suggestions on how to move forward. I looked at the ReactOS implementation and saw that it was #ifdefined out, so I also assumed that wasn't code we should be porting back to Wine. Steven's comments verify this. > BTW, how would you ensure that the testing of this function succeeds if > you pass the flag to it which reboots the machine and probably kills the > test-process? ;-) > I was suggesting you write tests for your own testing, not adding unit tests to Wine's test suite, though that's always good. To answer your original question, msdn states that the third parameter of SetupPromptReboot, ScanOnly, is a BOOL that determines whether the user is asked to reboot or not. If ScanOnly is TRUE, the user is not prompted to reboot, and no shutdown occurrs. msdn also says this about ScanOnly: "Use ScanOnly to determine if shutdown is necessary separately from actually initiating a shutdown." You can tests invalid parameters, using a valid FileQueue, see what values are returned etc. You won't be able to test a successful reboot in Wine's test suite, but you can test it with your personal tests. Besides that, you can set ScanOnly to TRUE and you get all the results you would get if the machine were to reboot without actually rebooting the machine. -- James Hawkins

Jan. 28, 2006

Re: USER: creating 16bit windows convert null instances to current process (try #3, should work now)

by Joseph Garvin

It's been a about a month since I sent this in and it still hasn't been applied. Is there something wrong with the patch? Joseph Garvin wrote: > Fixed up the patch according to Dmitry's suggestions :) > > Changelog > Fixed instance = 0 not converted to the current process when making a > window. Broke menus in some apps. (Thanks to Mike) > > >------------------------------------------------------------------------ > >--- dlls/user/win.c.1 2005-12-31 03:03:19.000000000 -0700 >+++ dlls/user/win.c 2006-01-01 01:02:43.000000000 -0700 >@@ -1145,6 +1145,18 @@ HWND16 WINAPI CreateWindowEx16( DWORD ex > cs.cx = (width == CW_USEDEFAULT16) ? CW_USEDEFAULT : (INT)width; > cs.cy = (height == CW_USEDEFAULT16) ? CW_USEDEFAULT : (INT)height; > >+ /* Correct if instance is null now, because later we won't >+ be able to tell the difference between a 16-bit NULL and >+ a 32-bit NULL */ >+ >+ if (!instance) >+ { >+ HTASK16 hTask = GetCurrentTask(); >+ TDB *tdb = GlobalLock16(hTask); >+ instance = tdb->hInstance; >+ GlobalUnlock16(hTask); >+ } >+ > /* Create the window */ > > cs.lpCreateParams = data; > > >------------------------------------------------------------------------ > > > >

Jan. 28, 2006

Re: setupapi: unimplemented function setupapi.dll.SetupPromptReboot

by Saulius Krasuckas

* On Fri, 27 Jan 2006, James Hawkins wrote: > * On 1/27/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > > > > Is anyone working on this for Wine? > > Any ideas about the ReactOS code? > > Read through it thoroughly and make note of all the details of the > function. Then write as many test cases as you can for the function. > Test the details you found on msdn and any other cases you can think of. > This should give you a better idea of how to implement the function > because you'll understand what needs to happen for each particular case. James, I wasn't asking about how should I hack on unimplemented function. My interest is focused on work of another guys, which is done already. :) BTW, how would you ensure that the testing of this function succeeds if you pass the flag to it which reboots the machine and probably kills the test-process? ;-)

Jan. 27, 2006

Re: tape.c: remove bogus breaks

by Hans Leidekker

On Friday 27 January 2006 22:13, Michael Stefaniuc wrote: > are those breaks realy supposed to be there? Smatch was complaining > about unreachable code. No, those breaks don't belong there, your patch is correct. -Hans

Jan. 27, 2006