Re: placeholder implementation of explorer.exe
Hi! I attached a small explorer like programm onto http://bugs.winehq.com/show_bug.cgi?id=1227 maybe we could port it into c code and include it into wine. It might be a good starting point to start a full featured explorer like programm. (And it's a good test for built in shell32) juergen > I collected my notes about getting msvc4's setup running under Wine at >http://www.kegel.com/linux/winelog.html > I now have wordpad reading .wri files properly under Wine > (needed for the "STL" button). The next problem is that > the setup program does >ShellExecute(..., "explorer.exe", ".", ...) > to pop up an explorer window. > > Well, wine has Winefile, but not explorer.exe. It looks > like the path of least resistance is for me to write a trivial > little explorer.exe that just cd's to argv[1] and fires > up winefile (which always operates on the current directory). > I've written it, and I expect when I add the needed > registry entry, it'll make msvc4's setup's "explore this cd" button > work fine. > > Anyone think that'd be a bad thing to put into the Wine tree? > - Dan > > -- > Dan Kegel > http://www.kegel.com > http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 > > > -- [EMAIL PROTECTED] FAX über T-Online Fax&Fon: 01805 060 334 316 35 (12Cent/Min)
wine-devel@winehq.com
Hi! Since some people recently did work on shell32... Is anybody doing this stuff? juergen -- [EMAIL PROTECTED] FAX über T-Online Fax&Fon: 01805 060 334 316 35 (12Cent/Min)
Re: Bug Fix With Delay load function in Shell32
Hi! This isn't the best solution since GetShellOle() initializes the ole subsystem by calling OleInitialize(). This is not nessesary for _CoCreateInstance(). Bye Juergen > > This fixes a bug in Shell32 where one function caused the function > responsible for setting up the delay load function pointers to assume they > had already been loaded, and they hadn't. > Maybe we should make the hShellOle32 variable static so this can't happen > again. > > ChangeLog: > - Set up all delay load functions in GetShellOle() function to avoid > GetShellOle assuming that they were all loaded when they weren't > > Rob > -- [EMAIL PROTECTED] FAX über T-Online Fax&Fon: 01805 060 334 316 35 (12Cent/Min)
Re: Shell Ordinals
Hi! We have a problem here... win9x and winnt have a very different set of ordinal functions exported. We have to decide what we support. At the moment most ordinals functions are win9x style. We should never mix both cases since then both explorer won't run. I think we don't have any chance to get the win9x explorer running. A long time ago I did a lot of explorer debugging and the nt4 explorer was nearly running since it's not as much involved into the booting of the system as the win9x one. So I would suggest to change the ordinals into the nt ones. It would cause some 9x only functions to be removed. The change of shell32.spec should be done in one go. PS: Since I recently started to do some shell32 work again: Who is doing what at the moment? Bye Juergen > > This includes a few ordinals used by explorer and desk.cpl > There seems to be a conflict between SHLocalAlloc/Free and the ordinals I > have made stubs for (on Win2k SP3 shell32.dll), but I have no way of knowing > which ordinal (if any) SHLocalAlloc/Free should be. > > ChangeLog: > - Implement some PropertySheetExtArray ordinals > - Add some stubs used by explorer > > Rob > -- [EMAIL PROTECTED] FAX über T-Online Fax&Fon: 01805 060 334 316 35 (12Cent/Min)
Re: CoInitialize
Can you send a trace with -debugmsg +ole? juergen On 13 Nov 2002 at 14:39, [EMAIL PROTECTED] wrote: > One of the threads in my app calls CoInitialize, expecting it > to return S_OK (in fact, it's followed by an assert statement > requiring that it returns S_OK). When I run it in Wine, however, > CoInitialize returns S_FALSE, implying that this thread has > already initialized the COM library. Other threads call > CoInitialize, but this is the first time that this thread calls it. > Does Wine initialize COM differently from Windows? Are the other > threads' calls to CoInitialize screwing up this thread's call? > > -Steve > > > -- [EMAIL PROTECTED] FAX über T-Online Fax&Fon: 01805 060 334 316 35 (12Cent/Min)
Re: RPC test code?
>2a) Should the rpc.c "real" test be the client or the server? I can >imagine races either way. Let's say rpc.c is the client. Why not let one process start both (client and server). This process could control both and kill them later... ... or have one executable which can act as supervisor, client or server depending on a command line switch. If started without a switch act as supervisor and start itself again twice with different switches... juergen --- [EMAIL PROTECTED]
wwn141
Just a comment to the mentioned use of LPC to ememinate the server part of rpc: Since wine uses a server every lpc-call causes a lot of context switching. LPC with the wine server will never be as fast as on winnt. -The client would have to wait on the client side what means a client call needs 2 roundtrips to the server. - There are 3 processes playing a role: client, wine-server and the server. Where winnt needs only a context switch between the client and the server and one back, we need at least 6: client -> wineserver (copies request-message to wineserver) wineserver -> client (gives wait handle back) wineserver->server (server wakes up on it's wait handle and gets request-message) ... server is working now ... server->wineserver (server copies replay-message to wineserver) client->wineserver (client is waken up and calls wineserver for data) wineserver->client (client gets replay-message from wineserver) So I would consider a different IPC mechanism for this. Or could we implement LPC in a better way? juergen --- [EMAIL PROTECTED]
Re: Known listview bugs (take 2)
The fix in http://bugs.winehq.com/show_bug.cgi?id=924 looks good. Could sbd send it as a patch ? Thanks Juergen > On Thu, 24 Oct 2002, Dimitrie O. Paun wrote: > > > On October 24, 2002 04:00 pm, Francois Gouget wrote: > > > Argh! I cheated. I used a slightly older Wine and copied the comctl32 > > > dll there. Today I retested with CVS Wine plus the latest X11 patch and > > > got it to work by just replacing the shell32 library with an older one > > > > Can you please search what broke shell32? This is Not Good (TM) > > Winzip was broken on 2002/07/23 by one of the following two patches: > > * http://cvs.winehq.com/patch.py?id=1027475763780155356581421 >Juergen Schmied <[EMAIL PROTECTED]> >- Cleaned up the implementation of shell folders and put them into > separate files >- Fixed some memory leaks >- Some more fixes > > * http://cvs.winehq.com/patch.py?id=102747584224009388063951 >Fixed duplication of definitions between shlwapi.h and >obj_queryassociations.h > > I cannot compile Wine if I only apply the first one. I suspect there is > a problem in the first one but unfortunately it is pretty large: ~4000 > lines > > > -- > Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ > 1 + e ^ ( i * pi ) = 0 > > > --- [EMAIL PROTECTED]
Re: Marshalling code for me to use?
> > and I don't know about anyone else working on it > > (Juergen Schmied is probably busy with other stuff). Yes, I'm not able to do much of work for some month. (Bussy changing nappies...). I was only merging the RPC stuff because I was interested in getting ove's COM stuff into wine. I might start to work there (COM) again sometimes later [or more early if I could pay my bills from it ... - thats life ;-) ] I still have some not-yet-ready-for-submitting LPC stuff in my queue. (If sbd interested...) PS: I found te freedce project at sourceforge. Maybe rpc could borrow (ndr-)code there? juergen --- [EMAIL PROTECTED]
Re: how to declare COM class?
> I declared a COM class best I can from looking at other COM class but I > am getting syntax errors. I could not find any guide/manual on COM > development. > > Can someone help or point to a guide on COM development? A guid might not help much since wine implements com objects with pure C. If you get stuck you could mail your code to this list for help. juergen --- [EMAIL PROTECTED]
RE: New header winternl.h
> And do what? > As I said above wintrnl.h can't include ntddk.h. > > Of course we can just include it as it is and don't use it... I would do nothing as long as nobody needs it. There are many *.h files in the SDK that we don't have and nobody missed them till today. juergen --- [EMAIL PROTECTED]
Re: SHLWAPI IQueryAssociations helpers
> This patch implements the Assoc* functions for SHLWAPI. We need to > decide whether to duplicate or share the code for the underlying COM > object though (i.e. can I include the c file from the shell dir?). Sharing code is never a good idea. Usually windows implements things on one place and we should do so too. The only reason for some code duplication between shlwapi and shell32 is ms moved some functionality from shell32 to shlwapi over time. All the assoc-stuff belongs to shlwapi now. Shell32 uses only this services. juergen --- [EMAIL PROTECTED]
Re: shlwapi cleanup
Are there any ideas if the build process could be fixed? I had a brief look at it and I'm there... juergen On 25 Jul 2002 at 16:34, Alexandre Julliard wrote: > "Jürgen Schmied" <[EMAIL PROTECTED]> writes: > > > --- wine/dlls/shlwapi/Makefile.in 22 Jul 2002 20:32:53 - 1.21 > > +++ wine/dlls/shlwapi/Makefile.in 24 Jul 2002 19:21:55 - > > @@ -4,8 +4,8 @@ > > SRCDIR= @srcdir@ > > VPATH = @srcdir@ > > MODULE= shlwapi.dll > > -# fixme: avoid ole32.dll import > > -IMPORTS = ole32 user32 gdi32 advapi32 kernel32 > > +IMPORTS = advapi32 gdi32 kernel32 user32 > > +DELAYIMPORTS = comctl32 comdlg32 mpr ole32 shell32 version winmm > > Some of these (like shell32) will create circular dependencies. This > must be avoided, our build process doesn't handle that. > > -- > Alexandre Julliard > [EMAIL PROTECTED] > > > --- [EMAIL PROTECTED]
Re: CxxFrameHandler problem
Hmm, I think these FIXME messages should be considered as a real FIXME. The application might throw a exception and catch it later as a normal behaviour. As long as our implementation of CxxFrameHandler does not behave right is has to be fixed. Then we can blame the application. juergen > --- Steven Edwards <[EMAIL PROTECTED]> wrote: > > If anyone is working on the CxxFrameHandler I have > > two > > applications I have been working on that may help in > > testing/tracking down the problems. Currently both > > WinCVS and geoshell suffer from this problem. Both > > applications are GPL so if you need to look at the > > source to find out what is going on you can. > > Steven, these FIXME messages are only traces of an > exception thrown by application and are not related to > real problem in any way. We should find out why an > exception is thrown in the first place. > > I recommend you to to file a separate bug report for > each case. > > Andriy > > __ > Do You Yahoo!? > Yahoo! Autos - Get free new car price quotes > http://autos.yahoo.com > > --- [EMAIL PROTECTED]
Re: SHLWAPI ole32 (delay-load of dlls)
(deleted) > Ifwe should directly link with ole32 then we should probably remove the FIXME from >Makefile.in. > If we follow this path, we should eventually also link with the other DLLs that >version 6 delay > loads instead of being optional as before: apphelp, mlang, comctl32, mpr, msi, >setupapi, > userenv, winmm etc. These are a bit to much dlls whats not on every system. Delay loading ole32 just needs a >= win95 version of ole32 so it shouldn't any problem. The other dlls are (except comctl32) are a problem because we can't expect them to be here. If there is no ole32 wine loads the built in as a fallback. I think it's safe to do a delay loading there. juergen > Cheers, > Jon > > Alexandre Julliard <[EMAIL PROTECTED]> wrote: > "Jürgen Schmied" writes: > > > This is not completely right. shlwapi loads ole32 per delay-load what > > means nearly its linking against it. We don't have anything similar at > > the moment. I don't think we should do anyting by function pointers. > > Maybe we could generate stubs during the build process to implement > > delay loading. It don't looks to hard to implement. > > It's already implemented, you just have to list them as DELAYIMPORTS > instead of IMPORTS in the makefile. > > -- > Alexandre Julliard > [EMAIL PROTECTED] > > > "Don't wait for the seas to part, or messiahs to come; > Don't you sit around and waste this chance..." - Live > > [EMAIL PROTECTED] > > > Do You Yahoo!? > New! SBC Yahoo! Dial - 1st Month Free & unlimited access --- [EMAIL PROTECTED]
Re: SHLWAPI ole32 (delay-load of dlls)
This is not completely right. shlwapi loads ole32 per delay-load what means nearly its linking against it. We don't have anything similar at the moment. I don't think we should do anyting by function pointers. Maybe we could generate stubs during the build process to implement delay loading. It don't looks to hard to implement. juergen On 11 Jul 2002 at 21:05, Jon Griffiths wrote: > Hi, > > SHLWAPI updates continued. > > This patch removes the need for direct linking to ole32, which is > only ever late bound by the real SHLWAPI. > > For fear of patch conflicts with myself, I haven't included a patch > to Makefile.in to remove the import and the FIXME. I'll send this in > a later patch, if need be. > > > ChangeLog: > > Jon Griffiths <[EMAIL PROTECTED]> > > +dlls/shlwapi/shlwapi_main.c dlls/shlwapi/string.c >Remove the need to directly link to ole32. > > > = > "Don't wait for the seas to part, or messiahs to come; > Don't you sit around and waste this chance..." - Live > > [EMAIL PROTECTED] > > __ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com --- [EMAIL PROTECTED]
Re: Crash in SHELL32_ParseNextElement
Im about to do a major update to the shellfolder stuff. Are you aware of any other probkems? juergen On 12 Jul 2002 at 10:11, Gregg Mattinson wrote: > ChangeLog: dlls/shell32/shlfolder.c > - Initialized the pidlOut variable in SHELL32_ParseNextElement to prevent a > crash in some cases. > > Gregg Mattinson > Co-op Developer > Sun Microsystems of Canada > > --- [EMAIL PROTECTED]
Re: Fix nasty little bug in InitializeGenericSF
Sorry for this bug and the waste of time. I'm about to implement a MallocSpy in OLE32 what will catch those corruptions and leaks in general. I already found about 10 leaks in comdlg32/shell32 and ole32 with it... We should do the same in ntdll for the Heap functions I guess... juergen > > This patch fixes a little bug that caused heap corruption (ouch!) when > > running the Finale 2002 installer. > > > > Urg! I'm sorry, I just noticed that Rein fixed this on Tuesday. I just > wasted a lot of time. --- [EMAIL PROTECTED]
Re: Apps that installs VBA
Likely the installer does not find a file with FindNextFile (Error 18 = ERROR_NO_MORE_FILES). The relay-trace with -debugmsg +dosfs,+relay shouls say more. juergen > Installing AutoCAD 14, I get everytimes an error telling that VBA (visual > basic for applications) cannot be installed (the messagebox tells a very very > meaningful 'error 18' (sigh) and aborts VBA setup). > As I've seen that someone is working on visual basic apps (maybe Ann and Jason > Edmeades ?), does someone have an idea of the solution ? > > Regards > > Max > > > --- [EMAIL PROTECTED]
Re: AGAIN: Wine wrongly seeing gdi32 & user32 as native
Last time I had this there where two different sets of wine librarys on my system since a install path was changed. Manually removing all librarys and a make install did fix this. Maybe it helps. juergen > Just setup a clean wine on slack 8.1 and any time I > try to run a GUI app I'm seeing this: > > Warning: loading builtin user32.dll, but native > version already present. Expect trouble. > wine: Unhandled exception, starting debugger... > Warning: loading builtin gdi32.dll, but native version > already present. Expect trouble. > Warning: loading builtin user32.dll, but native > version already present. Expect trouble. > wine: Unhandled exception, starting debugger... > Warning: loading builtin gdi32.dll, but native version > already present. Expect trouble. > > Console apps work fine and I read the thread relating > to this with the tests at > http://www.winehq.com/hypermail/wine-devel/2002/03/0454.html > but havent been able to fix it for these apps. What > else should I be doing? > > Thanks > Steven > > __ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > --- [EMAIL PROTECTED]
Re: Merge rpcrt/ole32 from Rewind
> > I started to merge this files in. This patches are done to a loder wine version so >it does not merge in a clean way. Some code is allready implemented twice. > > So I do: > > - merge as far as I can > > - if a function is implemented twice I comment one implementation out but leave >the code in (mainly the standard marshaler parts). I can't decide how to merge it. > > That's not a merge, that's just copying code around. If you don't know > how to merge that stuff properly, please leave it for someone else like > Marcus. No, the most things I can merge properly but I don't like to decide what implementation of the standard marshaler is better. I can copy Ove's one in a extra file and send it together with the patch so someone else (MM) can merge this part. > > - the final cleanup should be done by the ones who are familiar with that code >(Marcus?) > > - any objections against the rpcrt4 stuff? Ove himself says its not very clean but >we dont have any better code yet. > > I don't know, I haven't seen the patch, it seems the sourceforge > archives don't store large mails. Could you please forward it to me? I can send you the patch against the current tree (I've already merged it) a bit later. juergen --- [EMAIL PROTECTED]
Re: [PATCH] misc/registry.c
Where from do you know windows is in c:\windows on every computer??? Should't it in duty of shell32 to manipulate the ShellFolder entrys? Think it's not as simple as this... juergen > I think that the code to write to HKLM may be slightly > broken though, as I couldn't get any of the hklm > entries in misc/registry.c to be written, except for > the ComputerName one... I dunno, someone wanna have a > look at it? I'm creating a bug for it soon as i send > this out... --- [EMAIL PROTECTED]
Re: More Shlwapi ordinal routines - updated
Hello! I saw your patch today and noticed you are really doing W<-->A conversion for the version* functions. Is there a special reason for this? The A<-->W conversion in shlwapi is only for systems lacking the W-functions like win95 so it's not nessesary to do this for us. It's enough to just forward the entry points to the W-functions in the version.dll. Ciao Juergen -- just done a cvs update on my box after more than a year ;-) --- [EMAIL PROTECTED]
