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

timegettime - WinMM.dll funciton

by Ann and Jason Edmeades

I was trying to debug a DirectX8 simple sample, and found a bug in timegettime. Once this call has been made, my program never exits, probably because of the launched thread? Can anyone take a look at this? I'll happily test it :-) For now I have commented out that call and the pgm exits fine. It is also worth noting that the values I get back dont seem anything like on windows (I know the magnitude is based off when the timer thread gets kicked off, but I am talking about the deltas between two successive calls). Jason

Jan. 16, 2003

Re: Implementation of "start" command

by Dan Kegel

Sylvain Petreolle wrote: > Dan, > It was already discussed when Dustin was trying to handle the > autorun.inf files. > If you want to do this, use cygstart. > Could be funny if we merge it. > > http://www.winehq.com/hypermail/wine-devel/2002/12/0279.html Cygwin is GPL, but the registry-sensing changes have to go directly into ShellExecute, which is LGPL. Emulating them in start is not really an option. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 16, 2003

Re: Implementation of "start" command

by Sylvain Petreolle

Dan, It was already discussed when Dustin was trying to handle the autorun.inf files. If you want to do this, use cygstart. Could be funny if we merge it. http://www.winehq.com/hypermail/wine-devel/2002/12/0279.html > BTW, with this implementation, > start notepad > works, and > start wordpad > will probably work if you have the right registry entry (attached), > but > start foo.txt > probably won't... I'll try it out, and maybe improve ShellExecute if > needed. > > Also, start takes a number of switches; I'll try to implement them > soon. > - Dan > > -- > Dan Kegel > http://www.kegel.com > http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 > > REGEDIT4 > > [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App > Paths\WORDPAD.EXE] > @="C:\\Progra~1\\Access~1\\WORDPAD2.EXE" > > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 16, 2003

Re: Implementation of "start" command

by Sylvain Petreolle

It conflicts with vim's view, /bin/view. --- Alexandre Julliard <julliard(a)winehq.com> a écrit : > Dan Kegel > 'view' is not installed in /usr/bin, and 'start' shouldn't be > installed there either, it's very likely to conflict with something > else. Since we install the .exe.so in /usr/lib/wine it will be > available from wcmd anyway, and you can run it directly from the Unix > cmdline with 'wine start', which is acceptable IMO. ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 16, 2003

shlwapi/path test compilation error

by Francois Gouget

This test does not compile on Windows. There is a header include problem but changing them to the following solves the problem: #include "windef.h" #include "wtypes.h" #include "shlwapi.h" #include "wininet.h" #include "wine/test.h" #include "wine/unicode.h" However we then have problems with missing declarations on Windows: path.c(58) : warning C4013: 'UrlHashA' undefined; assuming extern returning int path.c(59) : warning C4013: 'UrlHashW' undefined; assuming extern returning int path.c(83) : warning C4013: 'UrlGetPartA' undefined; assuming extern returning int path.c(85) : warning C4013: 'UrlGetPartW' undefined; assuming extern returning int path.c(99) : error C2065: 'URL_PART_HOSTNAME' : undeclared identifier path.c(100) : error C2065: 'URL_PART_PORT' : undeclared identifier path.c(101) : error C2065: 'URL_PART_USERNAME' : undeclared identifier path.c(102) : error C2065: 'URL_PART_PASSWORD' : undeclared identifier path.c(103) : error C2065: 'URL_PART_SCHEME' : undeclared identifier path.c(104) : error C2065: 'URL_PART_QUERY' : undeclared identifier -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

Jan. 16, 2003

Problem compiling current CVS on Redhat 8

by Martin Cracauer

wine/dlls/comcat/: comcat_private.h:45: conflicting types for `ClassFactoryImpl' comcat.h:49: previous declaration of `ClassFactoryImpl' [more of same error for ther types] The two struct definitions actually are the same typedef struct { /* IUnknown fields */ ICOM_VFIELD(IClassFactory); DWORD ref; } ClassFactoryImpl; However, the gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) on Redhat 8 rejects the redefinition of the extern class which follows: extern ClassFactoryImpl COMCAT_ClassFactory; Is it neccessary to declare these types two times and/or include both *.h files? I also get this: gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -fPIC -D__WINESRC__ -D_REENTRANT -o comcat_main.o comcat_main.c In file included from comcat.h:28, from comcat_private.h:29, from comcat_main.c:21: ../../include/wine/obj_base.h:26:2: #error DO NOT INCLUDE DIRECTLY Martin

Jan. 16, 2003

Re: Implementation of "start" command

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > I'd be ok with a wine bin, but I don't think FHS or LSB > define a program called "start", so there's not much chance of clash > if we install 'start'. And 'start' is *very* handy. > > (And we already have a clash ... should we rename programs/view > to not clash with vi's view alias, or is 'view' specified by windows?) 'view' is not installed in /usr/bin, and 'start' shouldn't be installed there either, it's very likely to conflict with something else. Since we install the .exe.so in /usr/lib/wine it will be available from wcmd anyway, and you can run it directly from the Unix cmdline with 'wine start', which is acceptable IMO. -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2003

Re: Implementation of "start" command

by Dan Kegel

Dimitrie O. Paun wrote: >>You might think so, but on WindowsMe at least, it's a >>separate executable, C:\windows\command\start.exe > > Indeed, but I'm a bit worried of poluting the Unix command > line namespace with such a Windows specific feature... > > With your command, what's the difference between > > start prog > > and > > prog & Easy: "prog &" doesn't look for the program in App Paths like start does. Also, once I make sure "start datafile" works, that will let you open the file with the appropriate windows app much easier than remembering the path to the program. > If I'm using bash, I expect Unix-like behaviour. > I only expect Windows behaviour if I use wcmd. > So maybe we can keep it as a separate program, > but install it in a different path that's searched > by default only in wcmd? Say $prefix/wine/bin? > Or $prefix/bin/wine? What does FHS say, if anything? I'd be ok with a wine bin, but I don't think FHS or LSB define a program called "start", so there's not much chance of clash if we install 'start'. And 'start' is *very* handy. (And we already have a clash ... should we rename programs/view to not clash with vi's view alias, or is 'view' specified by windows?) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 16, 2003

Installing IE5.5

by Shachar Shemesh

I managed to install IE5.5 using the following procedure: 1. Download the IE5.5 base install from MS 2. Set .wine/config as suggested a few days ago (ver=nt40, setupapi=builtin, *=native,builtin) 3. Using the latest Wine (20030115), run the setup tool 4. I, personally, made two sessions. One downloading everything, and the other for installing. 5. Install just the basic IE. No Connection wizard or anything else. 6. When setup finshes (and you get an error in processing the reboot) - wait for all wine instances to exit 7. run wineboot. 8. One of the programs initiated by wineboot fails to run (starts winedbg), just shut it down. 9. That's it - IE works, sortof. I'm hoping this proves useful to everyone. Shachar

Jan. 16, 2003

Re: Add check to SetMenuItemInfo

by Greg Turner

On Thursday 16 January 2003 11:44 am, Mike Hearn wrote: > I think you're right in that a full test case is needed, but I can't > do that (at least, not in C, if Object Pascal is acceptable I might > be able to do so). Why can't it be done in C, out of curiosity? Please forgive me if paying attention to the rest of this thread would have answered this question :( Also: I spent the past 5 years programming Object Pascal. It would be great (for me, at least) if we could make tests in Object Pascal, but it's hard for me to imagine how that could ever be a wine-compatible approach? Is there even an OSS compiler for Object Pascal? Even if there is such a thing, I don't think it would be of much utility without the wine headers being also ported to Object Pascal, a huge task in itself. Just wondering, no flame intended :) -- gmt "If everyone is thinking alike then somebody isn't thinking." --George S. Patton

Jan. 16, 2003