- Wine-Devel - list.winehq.org

mvcrt patch
by Waldek Hebisch Jan. 7, 2002

Jan. 7, 2002

Enclosed is a patch (diff to 2001.12.26 snapshot) which impements stdio buffering in msvcrt. Since I cannot make Visual C binaries could anybady with Visual C++ test it? I have testet it with mingw32 and I incude my test program (iotst.c). The program prints a line indicating which test it is making and then complains about failures. Comment 1: current builtin msvcrt fails test1 (and few other as a consequence). Some native versions of msvcrt fail test 8. Comment 2: I wrote the test the way naive programmer would wrote it (IMHO). Now I think that for a testing framework we need an assert-like macro to make checking and printing code shorter and to have uniform printouts. I ommited some tests that require multiple processes (expandig file while it is read, checking that stdio buffers got flushed at exit) - I guess that doing such test in portable way is quite tricky. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

cutting teeth
by Shane Shields Jan. 6, 2002

Jan. 6, 2002

hello everybody, just want to let everyone know that i (shane shields) have joined the mailing list and downloaded the latest cvs. what i want to know now is what can i do i have some c experience but mostly dos (and some windows), vb (but i dont think its relevent) and i know the windows os quite well. as i converted to linux 8 months ago and totally removed windows i would like to help with wine development with the aim of not having to use any proprietry dlls at all (to do with the core os that is). i have looked at the 20011226 version and noticed that the ole functionality is virtually nonexistant. is anyone working on that? or is there a better way to cut my teeth with wine programming. suggestions, directions and flames welcome. just remember that i am relatively new to linux programming. looking forward to joining the community Shane Shields _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Re: WinSpool Ordinal Addition
by Alexandre Julliard Jan. 6, 2002

Jan. 6, 2002

"Mark G. Adams" <mgadams(a)sympatico.ca> writes: > I came across a program which imports a function from winspool.drv via > ordinal instead of via name. Now back in February, a patch from Huw Davies > was committed which removed all the ordinals from the spec file for winspool > (see http://www.winehq.com/hypermail/wine-cvs/2001/02/0016.html) I don't > know what the reason was (maybe some were wrong?), so I've attached a patch > which re-adds the ordinal for the one function this program requires. What app is that? None of the winspool.drv I checked have PrinterProperties at ordinal 201, so I don't see how this could work. Or does it just want to have something there? does it work if you put a stub at 201 instead of PrinterProperties? -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: PATCH: Euro
by Patrik Stridvall Jan. 6, 2002

Jan. 6, 2002

> This patch changes the NLS currency of all Euro countries to > use the "EUR" > as international currency and the euro-sign (iso-8859-15, > character 164). Hmm. While I'm do not doubt that some users of Wine might find this useful, Wine is supposed to do what Windows does and if Windows does something wrong Wine usually should as well. If I'm not mistaken the .nls contains that default values. It is entirely possible to change the currency and such in the registry to specify things differently for each user. That said I would find it unlikely that this patch would cause any serious problem. After all, as I said, the user can specify whatever currency it likes after the defaults have been set and every application is supposed to be able to handle it. So I do not really oppose the patch. It is more the principle I'm intrested in: Under what circumstances should Wine change the behavior if Windows does something in the wrong way?

4 3

Re: MSDOS Error Table Handling
by Ove Kaaven Jan. 5, 2002

Jan. 5, 2002

On Thu, 3 Jan 2002 ccrayne(a)crayne.org wrote: > - /* We will use a snippet of real mode code that calls */ + > /* We use a snippet of real mode code that calls */ > /* a WINE-only interrupt to handle moving the requested */ - > /* message into the buffer... */ > + /* message into the buffer... ... > - INT (WINE-only interrupt) If that's what you need, I suggest allocating a DPMI Real-Mode Callback thunk using DPMI_AllocInternalRMCB(). (There's an example of how to use it in dosaspi.c... you give it a Wine-implemented function, and it returns a real-mode address that DOS apps can use to call it... the only thing to keep in mind is that it's the Wine function's responsibility to pop the real-mode stack)

2 5

Re: ReadFile() question (Bug?)
by Mike McCormack Jan. 4, 2002

Jan. 4, 2002

Hi Martin, The console doesn't use an fd, so no fd will be fetched in FILE_GetUnixHandle. (have a look at server/console.c) Mike > Btw, > > in the code in ReadFile() / WriteFile() handling consoles, > shouldn't there be a > close (unix_handle) > statement before calling ReadConsoleA() / WriteConsoleA() ? > > Martin ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

SHGetSpecialFolderLocation function
by Chris Green Jan. 4, 2002

Jan. 4, 2002

Hi, I've been looking into this function, trying to work out why ms office 97 can't install under Wine. (I've also been looking at the handling of command-lines when new processes are spawned, as office's setup program spawns a process called acmsetup with a string of command-line options, and it seems that wine manages to insert an extra " at the end of the command line.) What I've found though with the SHGetSpecialFolderLocation, is that it seems to me that it is designed to allow the caller to pick an arbitrary value for the CSIDL, and that this will cause windows to create a new CSIDL. As the function's implementation currently stands, it has a hard-coded table of possible CSIDLs, and rejects calls with unknown CSIDLs. Has anyone else looked at this function, and does anyone have any comments or suggestions on ways to address this? I'm thinking that these values probably need to go into the registry, or something, rather than being stored in the code... regards Chris Green

1 0

msnbc news alert installer: "Unable to start browser"
by Dan Kegel Jan. 4, 2002

Jan. 4, 2002

While doing research for my site on the Microsoft antitrust trial ( http://www.kegel.com/remedy/ ), I came across a nasty little EULA for a product called MSNBC News Alert. The EULA is at http://www.msnbc.com/tools/newsalert/naeula.asp and says > MSNBC Interactive grants you the right to install and use > copies of the SOFTWARE PRODUCT on your computers running validly > licensed copies of the operating system for which the SOFTWARE > PRODUCT was designed [e.g., Microsoft Windows(r) 95; Microsoft > Windows NT(r), Microsoft Windows 3.x, Macintosh, etc.]. It'd be nice to know how close Wine is to being able to (a) install and (b) run this on a fake windows installation, as this may have some bearing on whether Microsoft is damaging anybody with this exclusionary EULA. (Besides, how could I resist? That EULA practically begs to be disobeyed!) So I downloaded it from http://www.msnbc.com/tools/newstools/d/news_alert.asp and ran it, but it failed with the dialog box "News Alert and Windows were unable to start your default browser to access the following URL..." Can anyone have a look at what's wrong (presumably Wine doesn't implement browser control, or I don't have a browser registered?) I'm running Wine release 20010731 (my, that's old!) The output of wine -debugmsg +all is at http://www.kegel.com/wine/newsalert/log.bz2 and is 328KB compressed (200 MB expanded!) I can't see anything obvious, but then I'm out of practice. (You probably just want to download the executable and try it yourself.) Thanks, Dan Kegel

5 6

Wine Tasklist
by Francois Gouget Jan. 4, 2002

Jan. 4, 2002

Hi, I would like to establish two Wine tasklists in Wine's bugzilla. * the first list would contain the items listed in my previous 'Call for Volunteers' emails. This would make it easier to keep track of these tasks. * the second list would contain more complex and general items like 'DCOM support'. For the first list, refer to my previous 'Call for Volunteers' emails. I think I will start it from there and we can update it after that. For the second list, I included a first draft below. I would like your comments on it, especially with regard to the status of some of these items, and suggestions if you see missing items. I know we already have a 'Wine 1.0' and 'Wine 1.x' tasklists'. There may be some overlap but I think the intent is different. * My intent with these two new tasklists is to advertise what we want to do to potential contributors. So the idea is to then add a page to the WineHQ web site that would list all the ways one can contribute to Wine: maintaining an application entry in the Application Database, helping users on the mailing lists, buying Wine based applications, and of course contributing code. And for this last item, these lists would provide a good starting point, both for developpers with little time and for developpers who want to invest themselves more heavily in Wine. * Then unlike the 1.0 and 1.x tasklists, these new lists would not be tied to a specific Wine release or date. I hope to produce a draft of this web page in the coming days. In the meantime let me know if I missed things in the list below. For each item I tried to indicate the rationale behind the task, and point to the corresponding bugzilla report if there is one. Wine tasklist ------------- * Make the registry loadable on demand - when working from a Windows partition the registry is big. - this causes wineserver to allocate a lot of memory - this has a big impact on startup times - a 'database' based registry may be more robust * Rasterizer - to paint into a DIB we have to copy the IB contents into an X bitmap, call X functions to modify the bitmap, often only to have to copy the result back to the DIB when the application tries to read it. Imagine it for eash SetPixel operation! - a rasterizer would be able to perform these operations directly on the DIB and thus provide better performance, at least in some situations. - it would also provide better color accuracy: the X server often only supports a few bit depths so that if the application works on a 24bpp DIB but the X server is in 16bpp mode, 3bits are lost per color component. * Cross process messages - used by many applications - needed for DDE (bug 95) - Alexandre, you worked on this recently, right? Is this working now? - See bug 93 * Out of proc COM - Needed for Installshield 6 - Would probably help with at least some functionality of a host of other applications * DCOM support - same as out of proc COM but network transparent - should be interoperable with Microsoft's implementation so that, in a company setting, processes running in Wine can connect to servers running on whatever Windows server are present. * Better multi-user support - how to get per-user registry files - how much per-user setup is really necessary? (create a '.wine' directory, create per user registry files, who does that, ...) - is it possible to share a single read-only 'c:\' drive? What do we need to get parity with an NT environment? - is it possible to share a read-only 'system.reg' file? - what is the impact of a 'load on demand' registry? Could we share a single registry server? - what would be necessary to share a single - there are many options that need to be investigated and documented... * UNC path handling - for drives '\\.\e:', devices - for network paths - there's been a patch related to this recently but I believe it does not cover all cases - integrate with Samba to handle network UNC paths - provide a way to mount/unmount drives at runtime, especially network drives. One should be able to disable this in the config file (for security reasons). - Support for 'persistent' mounts... will require modifying the way w specify which drives are mounted where. - provide an applet to mount/unmount drives while Wine is running. * Native Alsa support - Alsa is the future of sound in Linux: should be integrated in 2.5 - Could it offer capabilities that OSS does not offer? - Other platforms may not support Alsa any time soon so we must keep OSS too - Anti-rational: Alsa includes an OSS compatibilty mode that seems to work pretty well - see bug 324 * aRts support - On an OSS system when the aRts daemon is running Wine cannot access the sound device - aRts makes it possible to send the sound other the network. This kind of functionality is great for a thin-client environments: setup a server and have the sound sent to each terminal ("You've got mail" ;-). Supporting aRts in Wine would let it integrate perfectly in such an environment. - this could either be native support, or making Wine compatible with artsdsp. The current problem may be related to the -Bsymbolic link option. - see bug 325 * ESounD support - Same thing as for aRts - see bug 326 - Making Wine compatible with artsdsp may also make it compatible with esddsp (and vice versa). * Write a regedit replacement - used by some installers to create registry keys - we can limit the functionality to just that although since Wine has a registry we should probably provide a tool to browse/edit it. - will be more important once we have a database based registry for the load on demand functionality * Write a regsvr32 replacement - used by some installers * Fix the desktop mode - If a process running in desktop mode start another, the new process creates a new desktop - the background is black - one cannot start a specific application in desktop mode. You have to modify the config file. * Compile with STRICT on - better type safety - reveales all the 16/32bits hacks - see bug 90 * Dll separation - to allow us to swap native dlls in and out with less problems - to make the dlls more independent of each other and make it easier to treat them as independent projects - see bug 96 * HEAP_strdup* removal - Alexandre said some day that they will go away - Part of the dll separation? * Move the winsock16 code to wsock32 - winsock16 is more related to wsock32 than to ws2_32 - ws2_32 is the new API. This would leave us with a clean 32bit implementation of the new API that is not encumbered with 16bit hacks. * Check .spec file completeness - we need complete spec file to know where we stand - determine what's new in WinMe, Win2000, WinXP - check that the ordinals/absence of ordinals is correct - I have scripts that can be used as a starting point * Winedbg expression handling - when modifying the contents of a variable there can be mixups where the debugger modifies its own memory instead of that of the debugged process. * Winedbg g++ 3.0 support - The debugging format and the ABI changed in g++ 3.0 and winedbg does not support the new ABI. - This prevents debugging of C++ Winelib applications - This is especially troublesome for MFC Winelib applications - Eric, you worked on this recently, do you know if this is a thing of the past or is it possible that there are still problems (I did not test recently) * Better memory allocator - some memory allocation/release patterns cause the current allocator to be relatively inefficient - see threads on wine-dev (Ove/Gav hit this problem) * Winelib richedit support - one of the things needed by MFC - the API seems at least partly supported, but the headers are very incomplete - see bug 330 * Visual C++ project support - make it possible to generate a Winelib project from a Visual C++ project - this should be done by extending winemaker - see bug 61 * Specify how to compile and package the MFC - many applications use the MFC. To make Winelib useful it is necessary to make it easier to compile the MFC and MFC-based applications - winemaker has some support for the MFC. But it makes suppositions about how the MFC were compiled (library names, etc.). So it is necessary to document how to get something that works well - see bug 110 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 145 = 1! + 4! + 5!

5 9

ReadFile() question (Bug?)
by Martin Wilck Jan. 4, 2002

Jan. 4, 2002

Btw, in the code in ReadFile() / WriteFile() handling consoles, shouldn't there be a close (unix_handle) statement before calling ReadConsoleA() / WriteConsoleA() ? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0