wine-devel

wine-devel@winehq.org

11 participants
84461 discussions

Re: Upgrade management
by Mike Hearn 29 Sep '04

29 Sep '04

[CCd wine-devel as I think you meant it to go there originally] Holly Bostick wrote: > Seems to me that whether or not 99% of users will forget is not your > responsibility as developers. Other than making very sure that users > know there is something to remember, further programming against the > possibility that they will forget what you told them not to is more work > for you, simply in order to absolve them of responsibility for their own > system and make things "look good" at all times to those who want > everything "click and run". > > Look at the problems that attitude (and the compensatory measures to > resolve it) has caused Microsoft. I would think that you all have better > things to do with your valuable development time-- namely developing the > actual application, not babysitting me (the user with the mind like a > sieve). Well, there are a couple of good reasons why automatic upgrades are good for us developers: 1) If we don't, we'll just get bug reports due to people not having full upgrades: we already get plenty of bizarre bug reports due to broken packaging, last thing we need is for people to fill bugzilla with even more. And yes some developers do tech support :) 2) We already do a ton of stuff automatically, and nobody ever notices. This strongly implies that automatic setup and configuration does benefit people: I can assure you they noticed when we didn't set up the wine config upstream! We want Wine to have a good reputation for reliability, but currently it doesn't - people run random Foo app, it crashes and burns maybe due to incorrect configuration and they walk away saying "Oh well, Wine is crap, what did I expect?". This happens quite a bit. Ensuring the user is cleanly and transparently upgraded makes things Just Work to a greater extent, which is good for everybody. I'm still not hugely convinced about the backup thing: if you want to back up your configuration before upgrading Wine it's very easy: cp -rv ~/.wine ~/.wine.old ... we could even do that as part of the upgrade process. Possibly we should back up the registry, but not the virtual drive C. The C drive is going to change a lot less than the registry will: a Wine upgrade typically means new DLLs and maybe new registry contents. It rarely means changes to the drive layout. thanks -mike

1 0

How to deal with C++ APIs in wine spec file
by Jia L Wu 29 Sep '04

29 Sep '04

Hi, I have to write a spec file so that a winelib application can use a third party dll. The problem is that APIs in third party dll are written in C++. As c++ names and parameters are mangled, how can i call them in spec file? For example, how can I call a class constructor (which is built form another class) in spec file? Can anyone provide me an example? Thanks. Wu

1 0

Re: Moved some local variables from StartServiceCtrlDispatcherA/W to service environment block
by Alexandre Julliard 29 Sep '04

29 Sep '04

"Alexander Yaworsky" <yaworsky(a)migusoft.ru> writes: > ChangeLog: > > Moved some local variables from StartServiceCtrlDispatcherA/W to service environment block. > Introduced helper function service_ctrl_dispatcher. I don't think you want to pass ASCII strings across processes, there's no guarantee that both processes are using the same codepage. Inter-process communication should always be done in Unicode. -- Alexandre Julliard julliard(a)winehq.org

2 1

Updated winecfg to do list
by Mike Hearn 29 Sep '04

29 Sep '04

OK, well assuming that Alexandre commits the last of my patches to winecfg at some point (I suspect there is a reason they aren't already ...), here is the updated todo list for winecfg based on my last email on the subject: http://www.winehq.org/hypermail/wine-devel/2004/08/0007.html I'm probably not going to do any more work on winecfg for a while. > You probably want to increase the size of the drive mappings list so it > fills the tab, currently there is just a lot of empty space at the top of > the pane now you removed the old stuff. If AJ commits the last two patches, this is done. In fact, the editing has been moved into the main tab, as there isn't much reason to have a separate window for this and it simplifies the UI and code somewhat. > Also we should kill the autodetect button. This is done by > wineprefixcreate these days, or should be. Getting there ... drive autodetection is implemented. The heuristics could perhaps be improved but they'll do for now. But, we need to call it from wineprefixcreate. This means adding code like so to main(): if (argv[0] is "--drive-detect") { gui_mode = FALSE; auto_detect_drives(); return apply_drive_changes(); } > - Drive editing seems broken. The list box only updates the second time I > hit edit. err:winecfg:applyDriveChanges unable to set volume label for > devicename of 'H:\', label of '' With my last two patches, this works for me. > - Browse in the "Add/Edit drive" dialog is a WRITEME Oh hum, good point. I suspect this still does nothing, I don't remember. We need to make sure / is mapped (there is a function to do this in drivedetect.c), trigger the shell directory select dialog, then if we had to map / automatically, unmap it again. Not too hard to implement. We can probably slide this for 0.9, it's not essential. > - Build system isn't right: I did a cvs update but the res files weren't > recreated properly. I had to do a make clean to get the gui updates. Probably my [ab]uses of make depend, can be ignored. > - "Add Application" has poor usability: we always use a file browser > dialog box even though the most common use case is just "foo.exe", ie > the user knows the name and doesn't care about the location. Worse we > start in the c:\windows\desktop folder for some reason, meaning users > might accidentally select a .lnk file! Well, we still use a file open dialog but at least it starts in c:\ now and is filtered on EXE files. If somebody wants to implement a natty dialog like the GNOME run window, go for it! This would be a nice usability improvement, especially if you implemented then used listview tile mode. > - The Add/Remove application buttons are *way* too big! Fixed > - Obviously, once audio autodetection has been moved into the drivers we > need to kill the audio tab. Still needs to be done. Not all that hard. > - Libraries tab just has generally poor usability, actually. The first > item in the radio group is "Builtin" meaning that's the one users are > most likely to select, it should be "builtin, native" followed by "native, > builtin" Lots of tweaks to this tab, I find it a lot more convenient to work with now. The main remaining problem is that enter always triggers OK in the applet itself, and when you're typing in a new DLL you want to add, you want enter to add it not close the window! Not sure how to fix this without messing up the property sheet API. > - We ask the user to understand a magic * symbol to set the default - what > is up with that? Fixed. > - There are no helpful default entries in the drop down box for setting a > DLL override, and when you add one the tree does not expand so to actually > *set* it you have to expand the tree then select the new override. It doesn't use a treeview anymore, but the combo box could definitely use some of the most common entries to give people a hint. > - We have way too many (eg, more than zero) tree controls in this app. Fixed. This simplifies the code enormously. I don't think there's really any problem with selecting the app you want to edit on the first tab and it means there aren't any wierd states anymore where you can have a selection in the treeview that doesn't actually mean anything. The titlebar now reflects the app you're editing. > - Drive mappings list is really unclear, there's no separation between the > "Drive X:" label and the unix path its mapped to. This is improved a bit now too but really I'd like to see us use the listview control with a header control here. So in summary the BIG things we need to do before we can consider winecfg good enough for 0.9 are: * Delete the audio tab and use autodetection at wine startup instead * Add a --drive-detect switch and use it from wineprefixcreate * Update the docs to reflect usage of the new tool (Brian is on this) After 0.9 we can look at more UI improvements, importing some artwork to make it prettier, maybe eliminating the property sheet as that's a big pain to work with (though, it may be also that our control is buggy :), and so on. Probably adding more prefs as well, for things like printing and fonts maybe. I'd like to see us get winecfg to some kind of finished, releasable 1.0 state before the end of the year though and then we can mark that task as done on the TODO list. thanks -mike

1 0

Upgrade management
by Mike Hearn 29 Sep '04

29 Sep '04

There are a bunch of different ways we may want to upgrade the users configuration: - Changes to $WINEPREFIX (~/.wine), for example: - Introducing faked DLL headers - Improved drive detection - Changing the way the registry is stored - Adding stuff to the virtual Windows drive - Modifying the registry - Adding new keys - Adding new appdefaults (default config options should be in the code itself). While we have a policy of not having app-specific hacks in Wine, some situations are very hard to resolve without custom overrides. The Internet Explorer installer does a bunch of things we really don't want it to do. The DCOM installer needs custom overrides to convince it to install. And so on. - Registering new COM DLLs (these all boil down to rerunning wine.inf) - Adding new binaries such as fonts, PE DLLs (think Moz AX control), and so on. These may be placed somewhere in the Wine install directory and then symlinked or copied (presumably linked) into drive C. This leads to the following questions: - How do we know when to upgrade the users wineprefix? - How do we avoid disturbing the users configuration? - What implementation do we use to upgrade it? One potential implementation for knowing when to upgrade the wineprefix is to version it in a similar manner to how we version the wineserver protocol: with a simple incrementing integer. This could be stored in the registry, and Wines initialization sequence changed to be: ... Does $WINEPREFIX exist? No, call wineprefixcreate - Continue with startup + Yes? Check the wineprefix version key, if it is < the + version compiled into the source run + "wineprefixcreate --upgrade $oldversion $newversion", which then + performs the upgrade. If it exits with a zero exit code, the + version key is set to the number compiled into the source. + Then continue with startup If registry access is too difficult here, a simpler implementation could be used: just store the number in a .version file. How do we avoid disturbing the users configuration? Alexandre already laid out the plan for this, which is to have HKLM (HKEY_LOCAL_MACHINE) devoted to the defaults we cunningly choose for maximum kewlness, and HKCU (HKEY_CURRENT_USER) is where the users settings are stored. These override the defaults, meaning we can change the default settings by altering wine.inf, then bumping the wineprefix version so triggering a remerge of the default registry contents. This means modifying each piece of code where we read the registry to figure out a user-configurable option. The algorithm becomes: * Check the relevant key in HKCU, if it exists use it * Otherwise, if it's an appdefault, check the same key in HKLM * Otherwise, use the hardcoded default In most cases, there's no point in duplicating the points at which we can control the defaults, doing it in the code is fine. So, it basically means grepping the source to find out where we read settings from, and changing them to use HKCU instead of HKLM, perhaps also reading HKLM depending on the context of the setting (settings that can be used in appdefaults should check both). I don't know how common these settings are but it might be worth having a utility function either in a DLL or inline in a header to do this. Registry code isn't complicated but it is tedious and easy to mess up, so we might as well reduce code duplication at the same time. I think the best implementation is to keep the code responsible for managing WINEPREFIX in wineprefixcreate, and simply extend this program to handle upgrades as well. OK, so the name will be a bit inaccurate but let's not change it - users are already discovering the new program and getting used to it, no need to modify it now especially as it's mostly an internal program. In the above example the old version and new version numbers were passed to wineprefixcreate but most of the time that information wouldn't be needed, for instance if we were to introduce fake DLL headers we could simply check if they already existed and skip that part if so. I think there's no harm in running wine.inf multiple times, so we could just do that every time for both creation and upgrade. I *think* this addresses most of the issues with upgrades, though I'm sure Alexandre can think of more :) Potential unresolved problems: - [How] do we lock wineprefix during upgrade so other processes that are run hang about until it's done? - Currently moving registry keys about is done actually in the code itself: we copy it across then print a message telling the user to delete the old setting manually. There's a fair bit of evidence that some users simply don't spot/understand these warnings. Also, we want to allow people to upgrade Wine with quite long intervals in between yet eventually this code gets deleted. Maybe a better solution is just to have wineprefixcreate understand how to move registry keys around in response to bumping the version. If the script gets too unwieldy, we could split particular upgrades into separate scripts in $prefix/share/wine. - Are there any wierd setups where parts of wineprefix are shared between different users/systems that we need to take into account? Thoughts? Comments? thanks -mike

4 8

WineHQ Downloads Page
by Adam Schreiber 28 Sep '04

28 Sep '04

Could whoever is responsible for updating the website please change the Download page(http://winehq.com/site/download) to read: "Slackware binary .tgz for Slackware" or "Slackware binary .tgz for Slackware 10" The reference to Slackware 9 is confusing users. Thanks, Adam Schreiber -- Why isn't all of your email encrypted? http://gnupg.org http://enigmail.mozdev.org

1 0

Re: urlmon: IInternetSecurityManager
by Mike McCormack 28 Sep '04

28 Sep '04

Huw D M Davies wrote: > Good catch. This classfactory code is fairly pervasive in Wine. I'll > submit a patch fixing all other occurrences of this in a moment. Maybe we should make a new janitorial task to turn all those class factories into singleton into objects too. It's not necessary to allocate a piece of memory at all for a class factory. Mike

4 5

Re: SystemFunction036 debugging problem
by James Hawkins 28 Sep '04

28 Sep '04

> Is this program linking to SystemFunction036 statically or dynamically? I'm not really sure. Is there another way to tell besides doing a trace+all? > If it is linking dynamically (i.e. with GetProcAddresa), one option to try > is to completly remove SystemFunction036 so it is not exported from > advapi32.dll. It might then be that the apps that call it will see that it > is not present and do something else. Actually I just added the stub to advapi32, because the program will crash when it tries to call an umimplemented function. The main problem is that the program is expecting some result from SystemFunction036 (Filip thinks it might be a random generator thing), but it's next to impossible (or so it seems) to implement it correctly without documentation of what it does. I wanted to be able to see which function calls this to see whether I can get in there and keep it from calling. On Tue, 28 Sep 2004 07:01:33 +0800, Jonathan Wilson <jonwil(a)tpgi.com.au> wrote: > Is this program linking to SystemFunction036 statically or dynamically? > > If it is linking dynamically (i.e. with GetProcAddresa), one option to try > is to completly remove SystemFunction036 so it is not exported from > advapi32.dll. It might then be that the apps that call it will see that it > is not present and do something else. > > Another option is to try to contact the author of the app in question > (MyPhotoCalendars or whatever it is) and ask them about the function. > > -- James Hawkins

2 1

SystemFunction036 debugging problem
by James Hawkins 28 Sep '04

28 Sep '04

It turns out that SystemFunction036 is actually required to do something for MyPhotoCalendars.exe to install correctly because the installer exits with a program-level exception (ie not wine) What I would like to do is run MyPhot...exe with winedbg and then set a breakpoint for SystemFunction036 so that execution will stop when that function is called so I can see who is calling it or something along those lines, but I set the break point and when SystemFunction036 is called, the program doesnt stop at all. winedbg MyPhotoCalendars.exe WineDbg starting on pid 0xa In 32 bit mode. 1249 static inline void WINAPI DbgBreakPoint(void) { __asm__ __volatile__("int3"); } Wine-dbg>break SystemFunction036 fixme:dbghelp:elf_load_debug_info Unsupported Dwarf2 information for ld-linux.so.2 Breakpoint 1 at 0x4089a670 SystemFunction036 [/home/truiken/wine/dlls/advapi32/crypt.c:1914] in advapi32 Wine-dbg>step 1019 ExitProcess( entry( peb ) ); Wine-dbg>step Single stepping until exit from function, which has no line number information. ......... fixme:crypt:SystemFunction036 ( _A)l@H¦X@`ùm@%!D, 256): stub fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE fixme:crypt:SystemFunction036 (H¦X@, 256): stub fixme:actctx:FindActCtxSectionGuid stub! Invalid address (0x00404aa2) for breakpoint 0, disabling it Invalid address (0x4089a670) for breakpoint 1, disabling it Process of pid=0x0000000a has terminated Wine-dbg>bt You must be attached to a process to run this command. Any thoughts? -- James Hawkins

2 1

missing advapi32 prototype: SystemFunction036
by James Hawkins 28 Sep '04

28 Sep '04

While trying to install MyPhotoCalendars, an exception is raised because of a call to the unimplemented function advapi32.dll.SystemFunction036. >From reading the following post, http://www.winehq.com/hypermail/wine-devel/2003/09/0265.html I can see that it won't be very easy to even stub this function because it's a hidden api. What methods could I use to track down any information about this function or its prototype? -- James Hawkins

4 9

Re: urlmon: IInternetSecurityManager
by Robert Shearman 28 Sep '04

28 Sep '04

Huw D M Davies wrote: > Huw Davies <huw(a)codeweavers.com> > Stub implementation of IInternetSecurityManager > Add a classfactory > Fix calling convention of CoInternetCreateSecurityManager > > >+ >+static ULONG WINAPI CF_AddRef(LPCLASSFACTORY iface) { >+ IClassFactoryImpl *This = (IClassFactoryImpl *)iface; >+ return ++(This->ref); >+} >+ > Please try to use Interlocked* functions for ref-counting as it is currently a janitorial task to clean up this type of code and I don't think they are desparate for more work. >+static HRESULT WINAPI CF_CreateInstance(LPCLASSFACTORY iface, LPUNKNOWN pOuter, >+ REFIID riid, LPVOID *ppobj) { >+ IClassFactoryImpl *This = (IClassFactoryImpl *)iface; >+ HRESULT hres; >+ LPUNKNOWN punk; >+ >+ TRACE("(%p)->(%p,%s,%p)\n",This,pOuter,debugstr_guid(riid),ppobj); >+ >+ hres = This->pfnCreateInstance(pOuter, (LPVOID *) &punk); >+ if (FAILED(hres)) { >+ *ppobj = NULL; >+ return hres; >+ } >+ hres = IUnknown_QueryInterface(punk, riid, ppobj); >+ if (FAILED(hres)) { >+ *ppobj = NULL; >+ return hres; > You leak a reference on failure here. >+ } >+ IUnknown_Release(punk); >+ return hres; >+} > >+/***************************************************************************** >+ * IInternetSecurityManager interface >+ */ >+cpp_quote("#define SID_SInternetSecurityManager IID_IInternetSecurityManager") >+ >+[ >+ object, >+ uuid(79eac9ee-baf9-11ce-8c82-00aa004ba90b), >+ pointer_default(unique) >+] >+interface IInternetSecurityManager : IUnknown >+{ >+ HRESULT SetSecuritySite( >+ [in, unique] IInternetSecurityMgrSite *pSite); >+ >+ HRESULT GetSecuritySite( >+ [out] IInternetSecurityMgrSite **ppSite); >+ >+ HRESULT MapUrlToZone( >+ [in] LPCWSTR pwszUrl, >+ [out] DWORD *pdwZone, >+ [in] DWORD dwFlags); >+ >+cpp_quote("#define MAX_SIZE_SECURITY_ID 512") > It is probably better to put this outside the interface declaration as I'm not sure if midl and widl are consistent about not outputting this twice. >+HRESULT SecManagerImpl_Construct(IUnknown *pUnkOuter, LPVOID *ppobj) >+{ >+ SecManagerImpl *This; > >+ >+ TRACE("(%p,%p)\n",pUnkOuter,ppobj); >+ This = HeapAlloc(GetProcessHeap(), 0, sizeof(*This)); > > The convention with COM interfaces is to use the CoTaskMemAlloc / CoTaskMemFree memory management functions instead of the Heap ones (even though they are the same). This is just a slight nit-pick. >+ >+ /* Initialize the virtual function table. */ >+ This->lpvtbl1 = &VT_SecManagerImpl; >+ This->ref = 1; >+ >+ *ppobj = This; >+ return S_OK; >+} > Rob

2 1

Re: PATCH: imagelist: change ERR to TRACE
by Andreas Mohr 28 Sep '04

28 Sep '04

Hi, On Tue, Sep 28, 2004 at 06:44:16AM +0200, Michael Stefaniuc wrote: > Hello, > > License: LGPL, X11 > Changelog: > Michael Stefaniuc <mstefani(a)redhat.com> > - native ImageList_Remove dosn't spit out an error message when > deleting an index out of range so don't do that either Probably true, but native ImageList_Remove doesn't have its whole Windows environment completely buggy either. ;-) IOW: this was perhaps meant for Wine code bug tracking purposes (AFAIK Wine uses imagelists a lot internally, e.g. shell code or so). While an ERR is too verbose, TRACE is ill-suited for that (a wrong index certainly is an anomaly); thus I'd say it should be a WARN. Greetings, Andreas Mohr

2 1

Re: MakeSureDirectoryPathExists improvement
by Alexandre Julliard 28 Sep '04

28 Sep '04

Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes: > @@ -91,13 +91,28 @@ > */ > BOOL WINAPI MakeSureDirectoryPathExists(LPCSTR DirPath) > { > - if (CreateDirectoryA(DirPath, NULL)) return TRUE; > - if (GetLastError() == ERROR_ALREADY_EXISTS) > + char path[MAX_PATH]; > + const char *p = DirPath; > + int n; > + > + if (strchr(p, ':') != NULL) > + p = strchr(p, ':'); > + while ((p = strchr(p, '\\')) != NULL) > { > - SetLastError(ERROR_SUCCESS); > - return TRUE; > + n = p - DirPath + 1; > + strncpy(path, DirPath, n); > + path[n] = '\0'; > + if( !CreateDirectoryA(path, NULL) && > + (GetLastError() != ERROR_ACCESS_DENIED) && > + (GetLastError() != ERROR_ALREADY_EXISTS)) > + return FALSE; > + p++; > } > - return FALSE; > + if (GetLastError() == ERROR_ACCESS_DENIED || > + (GetLastError() == ERROR_ALREADY_EXISTS)) > + SetLastError(ERROR_SUCCESS); > + > + return TRUE; I don't think you want to simply ignore ERROR_ACCESS_DENIED. You should fix your algorithm to not try to create the drive root and then ignore only ERROR_ALREADY_EXISTS. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winecfg: Add Makefile rules to rebuild resource file when translations change
by Alexandre Julliard 28 Sep '04

28 Sep '04

Mike Hearn <mike(a)navi.cx> writes: > Add Makefile rules to rebuild resource file when translations change 'make depend' is a convenient way to do that, maybe you should give it a try ;-) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: stub implementation SystemFunction036
by Filip Navara 28 Sep '04

28 Sep '04

James Hawkins wrote: >+ >+VOID WINAPI SystemFunction036(PCHAR Buffer, INT BufferSize) >+{ >+ FIXME("(%s, %i): stub\n", Buffer, BufferSize); >+} >+ > > If you really want to stub this function then please don't print the buffer contents. It's an output buffer and contains garbage (maybe the garbage means something, but still it's garbage). - Filip

2 1

Re: SystemFunction036 debugging problem
by James Hawkins 27 Sep '04

27 Sep '04

> Is the target (the thing calling SystemFunction036) available to download > anywhere? Yea. here's the link: http://www.download.com/redir?pid=10287361&merid=107235&mfgid=107235&lop=li… On Tue, 28 Sep 2004 07:29:14 +0800, Jonathan Wilson <jonwil(a)tpgi.com.au> wrote: > Is the target (the thing calling SystemFunction036) available to download > anywhere? > > -- James Hawkins

1 0

Problems installing office 2k.
by James Pellow 27 Sep '04

27 Sep '04

Hi List, I just installed wine from cvs as of this morning and am still having problems installing office. I get the following error when starting the installer with the msi debugging channel on: fixme:msi:MsiEnableLogA 00000516 "c:\\windows\\temp\\Office 2000 Professional Setup (0014)_MsiExec.txt" 00000000 trace:msi:MsiEnableLogW 00000516 L"c:\\windows\\temp\\Office 2000 Professional Setup (0014)_MsiExec.txt" 00000000 trace:msi:MsiInstallProductA "/I" "" fixme:msi:MsiInstallProductW L"/I" L"" trace:msi:MsiVerifyPackageW L"/I" trace:msi:MsiOpenDatabaseW L"/I" (null) 0x4055fd78 trace:msi:MSI_OpenDatabaseW L"/I" (null) fixme:msi:MSI_OpenDatabaseW open failed r = 80004005! trace:msi:MsiCloseHandle 405aa5aa Installation of /I () failed. Mike had suggested I not use the builtin msi.dll. Since no native msi system was installed, the office 2k installer to tried to install one resulting in the following error: fixme:thread:NtSetInformationThread Set ThreadImpersonationToken handle to (nil) fixme:thread:NtSetInformationThread Set ThreadImpersonationToken handle to 0x50 err:ntdll:NtQueryInformationToken Unhandled Token Information class 8! fixme:thread:NtSetInformationThread Set ThreadImpersonationToken handle to 0x44 fixme:powermgnt:SetThreadExecutionState (0x80000001): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x80000000): stub, harmless. fixme:thread:NtSetInformationThread Set ThreadImpersonationToken handle to (nil) Installation of /i (REBOOT=REALLYSUPRESS) failed. It is suprising to me that nobody else has reported this office 2k msi problem. I guess everyone is using OpenOffice these days :) I really don't use wine much, but I have been following its progress over the years and compile and test it once in a while. I am happy to do a little more debugging if someone wanted to give me some pointers. Thanks. Cheers, James -- ***************************** James A. Pellow, President Alent Design Solutions www.alentdesignsolutions.com (509) 526-0682 *****************************

1 0

edonkey2000 dll err
by J. Grant 27 Sep '04

27 Sep '04

Hello, As this is an "err, I thought I should post the the devl list. I am using CVS build from 2004-09-20. I am using DLL's copied from working win2k install. It seems quite fatal, any ideas? Kind regards JG c:\opt\ed2k>edonkey2000.exe c:\opt\ed2k>err:module:import_dll No implementation for MSVCRT.dll.??_U@YAPAXI@Z imported from L"C:\\opt\\ed2k\\MSVCIRT.dll", setting to 0xdeadbeef err:module:import_dll No implementation for MSVCRT.dll.??_V@YAXPAX@Z imported from L"C:\\opt\\ed2k\\MSVCIRT.dll", setting to 0xdeadbeef -- Homepage: http://jguk.org/ Blog: http://jguk.org/index.html#blog Radio: http://jguk.org/index.html#radio

3 3

Re: Getting winebuild to work on HP-UX
by Warren_Baird/CSI＠cimmetry.com 27 Sep '04

27 Sep '04

"Eric Frias" <efrias(a)syncad.com> wrote on 09/27/2004 09:52:12 AM: > I don't know if this made it through on Thursday; if not, here's a repeat: I saw it on the archive - sorry I didn't get a chance to respond on Friday. Thanks for the repeat, though - it saves me cutting and pasting from the browser. :-) > I'm afraid I won't be a lot of help right now, but I might be able to offer > some moral support. Well - at this point even moral support would be a good thing... > I've spent several weeks last year trying to get > winelib working on HPUX, but I don't really have anything to show for it. > Before I could get anything working, I had to abandon HPUX and work on > fixing up Linux and Solaris stuff because it was in higher demand. I'll > eventually need to get HPUX working also, but I won't be able to devote too > much time to it for at least a month. My timeline is probably tighter than that - I'm hoping to have winelib working within the next month... So you might be lucky. :-) > I was in the same situation as you are... very rusty at x86 assembly, able > to comprehend a little sparc assembly, but I didn't know a thing about > pa-risc. I was simply typing make, letting it run until it had some error > because HPUX wasn't supported, coming up with some fix for it, and > repeating. Some days I felt like I almost grasped what was going on and how > to fix it, and some days it felt like it was miles away. I never got all of > wine compiling, so I have no idea if any of the fixes I made were correct or > not. I'd be happy to share them with you, but seeing them might do you more > harm than good. Yeah, if you wouldn't mind, send me the patches --- It may give me some useful ideas, at least. > Anyway, good luck, and if you weren't looking for an excuse to learn pa-risc > assembly, well, you have my sympathies. I'm told it builds character :-) :-) then I guess my character is in for a bit of a work-out. <sigh> Thanks, Warren -- Warren Baird, Technical Group Leader warren_baird(a)cimmetry.com Cimmetry System Inc. 514 735 3219 x148

1 0

Wine User Guide changes (RFC)
by Brian Vincent 27 Sep '04

27 Sep '04

With Mike's recent Winecfg patches and the renewed hope we'll cut over to using Winecfg some day, I went through and began updating the Wine User Guide. The focus of the changes thus far was to remove references to the config file and discuss Winecfg instead. Without actually being able to use Winecfg these changes are useless, but it's probably worth looking this over to see whether these docs are headed in the right direction. For now, the biggest changes can be found in configuring.sgml (which translates into the "Configuring Wine" part of the guide.) A diff is available here: http://www.theshell.com/~vinn/wine-user-guide.diff However, this stuff is best looked at as a side-by-side comparison with the existing docs. You can find that here: http://www.theshell.com/~vinn/wine-user-guide.html (Not having looked at Mike's recent patches, I'm sure this will soon be out of date. Things like drive detection are missing. There's also parts that I left undone: such as the printing config, an appendix listing reg keys would be nice once we know what they all are. Other parts probably need a better explanation, such as font configuration. Anything you notice missing is probably worth telling me about, though it won't be hard to find lots of mistakes.) One of the big goals of all this is to reduce the amount of documentation and outdated stuff. Therefore, registry.sgml, printing.sgml, and fonts.sgml have been somewhat merged into configuring.sgml. fonts.sgml contained a lot of outdated info in it that probably caused more confusion than helped. Going forward, we have a lot of documentation in the User Guide about downloading Wine, compiling Wine, CVS, etc; mostly stuff that's already duplicated in some form or another on the web site. I'd like to see as much stuff like that removed from the User Guide as possible, we can simply refer people to WineHQ for more info. (I think the reason for the duplication is that the website docs simply didn't exist when the User Guide was written, now the website has superceded the User Guide.) When it's all said and done we should be left with the following sections: - Introduction - Configuration - Running - Troubleshooting At least, that's the direction I think it should go and at some point I could begin making those changes. Anyone disagree? Any thoughts, comments, concerns, criticisms? -Brian

2 1

tree/list-view slowness
by James Hawkins 27 Sep '04

27 Sep '04

I am currently working on making Kazaa Lite 2.4.3 more usable. The most major problem remaining is that when the user chooses to search for a file on the network, the program slows almost to a halt and becomes mostly unmanageable. The results are displayed in a tree/list-view in the right pane [1]. I've looked into both of the controls, and it seems like the slowness could be coming from their implementation, but even when I set comctl32 to native, the problem remains. Also, I've done a trace+treeview and a trace+listview and only treeview api's seem to be called and not listview. Would it be a possibility that they implemented their own listview? Can anyone describe a method I can use to track down the inefficiency? Thankyou for your help. [1] http://www.andrew.cmu.edu/user/jhawkins/klite.jpeg -- James Hawkins

2 1

Re: Listbox fixes
by Alexandre Julliard 27 Sep '04

27 Sep '04

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > +dlls/user/listbox.c > Draw background of the empty selected item in empty lists > Dont draw a focus rect if we do not have the focus > Dont select items on key up/down in multi-select lists This is causing a test failure: listbox.c:134: Test failed: style 0x8, step step, field selected: expected 2, got 1 listbox.c:134: Test succeeded inside todo block: style 0x8, step step, field selcount: expected 1, got 1 (the second one is a good thing of course...) -- Alexandre Julliard julliard(a)winehq.org

5 6

slovenian keyboard support
by Rok 26 Sep '04

26 Sep '04

I'm using slackware 10, KDE and Wine 20040914 (binary) and have problems using specific letters: ---cut-here--- err:keyboard:X11DRV_ToUniCodeEx Please report: no char for keysym 01E8 (ccaron) : err:keyboard:X11DRV_ToUniCodeEx (virtKey=E2,scanCode=62,keycode=2F,state=10) err:keyboard:X11DRV_ToUniCodeEx Please report: no char for keysym 01C8 (Ccaron) : err:keyboard:X11DRV_ToUniCodeEx (virtKey=E2,scanCode=62,keycode=2F,state=11) err:keyboard:X11DRV_ToUniCodeEx Please report: no char for keysym 01B9 (scaron) : err:keyboard:X11DRV_ToUniCodeEx (virtKey=E0,scanCode=60,keycode=22,state=10) ... ---cut-here--- I'd need letters [cCsSzZ]caron [cC]acute [dD]stroke. Is there any this can be resolved? Thanks! LP,Rok.

2 1

(no subject)
by Arda Ataerkil 26 Sep '04

26 Sep '04

hi. i m new user Linux redhat. jop is Graphic Desgner. i want to shot Win Xp enought for virus and all bad thinks. but i need to use photoshop, flash, and other soft working with Windows. and i learned yesterday "wine" is makeing work with linux this software. is it true. i try to download it . but couldent find anywhere. could you give mea link . where ami download it. At your site too much packages . could you give to me a link all packages at 1 download file. couse i m newer user to diffucult do set up and download it for me at now. Regards.

2 1

Re: wine/loader preloader.c
by Mike Hearn 26 Sep '04

26 Sep '04

Hi Alexandre! What's the reasoning for this change? I thought the preloader should not be built as a PIE because otherwise the kernel could map it into one of the areas we need to reserve. More to the point, the people trying to do this are thinking it will increase security. It won't, even though this code is loaded at a known offset it does not contain any code you could exploit in a return-to-libc type attack and anyway, exploits through Wine are far more likely to come in through the software being run on it than Wine itself. There is a patch in bugzilla (I guess you saw this) to ensure -fno-pie and -fno-stack-protector is passed to gcc for the preloader. thanks -mike > Log message: > Support compiling with -fPIC for people who somehow think this is a > good idea.

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel