November 2003 - Wine-Devel - list.winehq.org

Re: Mmsystem API timeGetTime

by Casper Hornstrup

> -----Oprindelig meddelelse----- > Fra: Eric Pouech [mailto:pouech-eric(a)wanadoo.fr] > Sendt: 30. november 2003 16:39 > Til: Casper Hornstrup > Cc: wine-devel(a)winehq.com > Emne: Re: Mmsystem API timeGetTime > > I see two ways of doing it: > - either use a function pointer to ReleaseThunkLock & > RestoreThunkLock > which will be initialized if mmsystem is loaded (as we do for most of > the 16 bit functions we need) > - or load by hand these two function with GetProcAddress, and > handle the > case where they are not defined. > I'd vote for the first one. ReleaseThunkLock and RestoreThunkLock need only be called in mmsystem.dll? How about this patch?

Nov. 30, 2003

Re: Splitting out shared Win16/Win32 code

by Casper Hornstrup

> -----Oprindelig meddelelse----- > Fra: Eric Pouech [mailto:pouech-eric(a)wanadoo.fr] > Sendt: 30. november 2003 16:35 > Til: Casper Hornstrup > Cc: 'wine-devel' > Emne: Re: Splitting out shared Win16/Win32 code > > > Casper Hornstrup wrote: > > Dlls/winmm/lolvldrv.c has a function (MMDRV_Message) shared by the > > Win16 and the Win32 implementation of mmsystem. Since it is > shared by > > both mmsystem.dll and winmm.dll, all Win16 APIs used in the shared > > functions will be imported by the Win32 implementation (winmm.dll) > > also. On ReactOS no such APIs exist so the library will not load. > I don't see any 16 bit (exported from mmsystem.dll) function > called from > this MMDRV_Message function. Could you elaborate a bit more ? > winmm should be able to be compiled without the mmsystem support (the > contrary is not correct, but you don't need it in ROS AFAICT). > A+ You're right. I should have written MMDRV_PhysicalFeatures. See attached patch. Casper

Nov. 30, 2003

Re: [Curses] Choose curses so library at startup (4/5)

by Peter Berg Larsen

On Sun, 30 Nov 2003, Eric Pouech wrote: > > I would agree with you allmost any time. But (of cause there is a but) we > > are only using functions that was standard pre waaay old and I did > > actually spend some time looking for functions/types etc. and nothing has > > changed. As we are not touching internal stuff, allocating structs or > > termcap/terminfo etc. I am convinced that they are binary compatible (and > > I ran wine with some of the oldes curses lib I could find). > > the point is not only at function prototype level, lost of curses > functions are defined as macros, and this can change from implementation > to implementation. Hence the .so / header peering and the rest... Yes you are right. But I ask for a pratical argument for why is shouldnt be binary compatible. The subset we are using is so small that is was defined (syntax and sematics) mandentory for a curses library back in 95 (before linux 2.0.0). Looking at this subset in the ncurses code shows that functions/types/structs/macroes have not changes since.

Nov. 30, 2003

Re: kernel: implement a few morevxd ioctls

by Eric Pouech

Juan Lang wrote: > ChangeLog: partially implement DeviceIoControl for > VDHCP, VNETBIOS, and VNB, gets rid of FIXMEs for some > apps. > > In particular, ipconfig.exe and winipcfg.exe work more > completely (and less slowly without the FIXMEs). Hope > to see fewer bug reports complaining about the FIXMEs > too, since they usually didn't hurt anything. just for performance reasons, which don't you declare your fonction pointers as static ? (this would also prevent from bumping the load count of the DLL you use every time the app issues a deviceioctl call). A+ -- Eric Pouech

Nov. 30, 2003

Re: debugger problems

by Chris Morgan

Nope, still doesn't appear to work. Rein, you see the same? Chris On Sunday 30 November 2003 11:08 am, Eric Pouech wrote: > Chris Morgan wrote: > > Still isn't working with build from todays cvs. Is this patch in there? > > it seems that AJ applied it after your mail had been sent > A+

Nov. 30, 2003

Re: Nice work - OpenOffice 1.1 under WINE

by Steven Edwards

--- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > On November 29, 2003 08:33 pm, Steven Edwards wrote: > > If anyone is interested in a good > > hobby project a Winelib port of this would be nice to see. > > Yes, but before we can attempt that, we need MinGW support in > OO, and AFAIK, that's not supported just yet. Does anyone know > of any (current) effort to remedy that? There is nothing on the website regarding the Mingw port except that they are looking for people. I have CC'd the Sun contact regarding this on the email. Hello Martin! Is there any news on the Mingw port of OpenOffice? I have just run 1.1 under WINE and it runs nearly perfectly. We are interested in the Mingw as we would like to recompile it for Winelib. Thanks Steven __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

Nov. 30, 2003

Re: Nice work - OpenOffice 1.1 under WINE

by Steven Edwards

It is in the default mode. I just installed WINE from CVS on my slackware server and used the sample .config in the documentation directory. I dont know what mode WINE defaults too as the Winver option is commented out in my .config. I made no changes to WINE to get OpenOffice 1.1 to install. The only problem I had was with the programs .exe themselves (And this may have been my fault). I upgraded a existing OO install I had copyed over the network to my linux box. This didnt work so I had to reinstall OO from the ZIP file on the website. It renamed the existing soffice.exe to soffice.old. I could not run any of the other *.exe in the OO directory. Once I renamed the program back to soffice.exe I was able to load the writter and the spreadsheet componates with little trouble. I didnt use tools/wineinstall to compile so I got a ton of warrnings about missing OLE and COM stuff from winedefault.reg but once I loaded the registry it functioned at 99% perfection. Thanks Steven --- Shachar Shemesh <wine-devel(a)shemesh.biz> wrote: > Is this in NT or Win9x mode? If the later, did you have to manually > do > anything regarding unicows? > __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

Nov. 30, 2003

Re: Last Comdlg16/32 split patch

by Steven Edwards

Whoops!!!! Here it is for real. Thanks Steven --- Steven Edwards <steven_ed4153(a)yahoo.com> wrote: > After this is just header cleanup for the MS_VC and Mingw ports. > > Changlog: > Split the Win16/32 color dialog by duplicating two internal > functions. __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

Nov. 30, 2003

Re: debugger problems

by Eric Pouech

Chris Morgan wrote: > Still isn't working with build from todays cvs. Is this patch in there? it seems that AJ applied it after your mail had been sent A+ -- Eric Pouech

Nov. 30, 2003

Re: Mmsystem API timeGetTime

by Eric Pouech

Casper Hornstrup wrote: > How can this API be implemented so it does not have to use > ReleaseThunkLock and RestoreThunkLock (at least the Win32 > version)? > > DWORD WINAPI timeGetTime(void) > { > /* FIXME: releasing the win16 lock here is a temporary hack (I hope) > * that lets mciavi.drv run correctly > */ > DWORD count; > ReleaseThunkLock(&count); > RestoreThunkLock(count); > TIME_MMTimeStart(); > return WINMM_IData->mmSysTimeMS; > } > > > I see two ways of doing it: - either use a function pointer to ReleaseThunkLock & RestoreThunkLock which will be initialized if mmsystem is loaded (as we do for most of the 16 bit functions we need) - or load by hand these two function with GetProcAddress, and handle the case where they are not defined. I'd vote for the first one. A+ -- Eric Pouech

Nov. 30, 2003