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

Re: RICHEDIT once again

by Mike McCormack

Krzysztof Foltman wrote: > My rich text control is still far from even semi-complete, but I think > too much is done to start over, so I'm releasing it today. The number > one reason of its incompleteness is that I put more emphasis on making > things work exactly like in the original than on implementing more > functions. Fantastic. This is good work. I haven't reviewed the code in depth, but I think the way forward is to submit an implementation of dlls/riched20 then make that work, and after it's debugged and worked out, rip out the old dlls/riched32 code and forward it to the new completed riched20 code. Code review notes: You've writen the code to deal with unicode as default, which is good, but you need to deal with both ASCII and unicode messages in the window procedure. It might be better to use libwineunicode and kernel32 unicode string manipulation functions rather than msvcrt ones. eg lstrlenW, lstrcpyW, etc. instead of wcslen, wcscpy, etc. Avoid the TCHAR type in Wine code. Similarly, you'll need to use "winbase.h" and friends instead of "windows.h". From what I can see in the old riched32 code, the rtf parser looks quite good, so don't try rewrite that (which from my quick check you haven't). We can merge the parser into the riched20 code quite easily... it's just enters the text into the existing control using EM_SETSEL and some formatting messages. I have a test I can send to you if you wish. Again, my preference is to get this into the Wine CVS sooner rather than later, so others can start helping improve it. Mike

Jan. 30, 2005

Re: Fwd: Re: Q? system wide variables

by Mike Hearn

On Sat, 29 Jan 2005 21:10:33 +0000, Oliver Stieber wrote: > Thought I should send this to winedev as well, is it > just me, or is the reply address set to the sender and > not winedev? It's not just you. It's an annoying default that routinely causes flamewars on every list that uses it. The mailing list software lets you set the reply-to address to the list very easily but comes with a link to a stupid lecture basically saying that people with horribly broken legacy mail clients may be slightly inconvenienced by it. I read it when I set up my first mailing lists and wasn't impressed at all. Anyway, I doubt it'll change anytime soon, you just have to get used to hitting the "reply to all" button instead. For some reason setting Reply-To to the list never causes flamewars <grumble> thanks -mike

Jan. 30, 2005

RICHEDIT once again

by Krzysztof Foltman

My rich text control is still far from even semi-complete, but I think too much is done to start over, so I'm releasing it today. The number one reason of its incompleteness is that I put more emphasis on making things work exactly like in the original than on implementing more functions. It's been neglected for weeks, and only recently I've fixed some old bugs and slowly started implementing the simplest parts of the RICHEDIT control API. I'm still not done with the basic stuff, like undo stack, so there is not much to hack on. On the other hand, it's likely I've made some bad decisions during design, and having someone experienced to look at that seemed to be a good idea to me. Some things look really tricky to implement with the current architecture, like the printing API (it will likely be an ugly hack, but I expect the same from the original, as screen formatting and print formatting may be very different). Some things just need time. I will probably need others' help to do the RTF parser. It's just way too much work. So, if anyone cares: http://foltman.com/richtext-20050130.tar.gz Compile using the recent-ish mingw (plus original SDK richedit header file). Have fun, Krzysztof

Jan. 30, 2005

Re: Q? system wide variables

by Rob Shearman

Jakob Eriksson wrote: > Oliver Stieber wrote: > >> Hi, >> I need to track the 'fake' amount of video memory >> in total, allocated and left for Directx 9 and would >> like to track it across wine so that DDraw, DirectX, >> DxDiag and X11 driver can all sing from the same song >> sheet. >> >> What's the best place to do this? is the registry code >> fast enough or should I add a new function to the X11 >> driver so that I can request and release 'fake' video >> memory and make all other AvailableVideoMemory >> requests ask X11 driver? >> >> I would expect the use to be able to override by the >> initial amount, even if there's code that detects it >> since wine,X and openGL manage video memory >> differently to windows, direct draw and D3D. >> >> > > How will this affect ReactOS? > > They don't use X11. They even plan on loading native > binary 3D drivers. AFAIK, they plan to completely rewrite the D3D layer to not use OpenGL at all and use the native D3D interface, so it won't affect ReactOS at all. Rob

Jan. 30, 2005

Re: Wine packages, universe maintainence, and myself

by Brian Vincent

On Sat, 29 Jan 2005 17:49:01 -0800, Scott Ritchie <scott(a)open-vote.org> wrote: > Hence, I am writing this email. I'd be willing to maintain the Wine > packages for Ubuntu, as well as related ones such as winetools. Anyone willing to maintain packages gets my vote. Thumbs up. > The Wine package at first glance seems a bit different from some Debian > standards, for various reasons. > > First off, even though Wine has some seemingly shared libraries, I > haven't split them off. Speaking as a non-Debian user, that looks good to me. I hate how you can otherwise have lots of little library packages that are otherwise worthless because they must be used together. > We may want to have an entirely new applications menu for Wine. I > envision having Wine installed and then having it create a new folder > Applications->Wine, which will contain the Winecfg program labeled > "Configure Wine" as well as a near empty start menu with Wine's shipped > winelib Notepad program. When other windows programs get installed, > they can be put in the Wine start menu there. It is on my system... > I also had a man message me on AIM thanking me profusely for the Wine > packages. Apparently he had won several hundred dollars using a Windows > poker program via Wine. I'll have to make a note not to try that out - I don't need any more excuses for wasting time. On that note, I'm going to Vegas next week. I plan on bringing down the house, retiring, and buying a small Caribbean island. > Anyway, I'd appreciate feedback and thoughts about this, as well as help > with my package. Meet me in IRC, I'm YokoZar. -Brian ("vinn")

Jan. 30, 2005

Wine packages, universe maintainence, and myself

by Scott Ritchie

Hello, I met some of you on IRC the other night. I am currently the Debian and Ubuntu packager for the Wine project. The "official" Debian maintainer hasn't been updating the packages and refuses to turn them over to me, so we've setup our own apt repository at winehq.org. The packages have been tested a lot, and are also in the Ubuntu backports project working fine. I was wondering what it would take to make them the ones that sit on Ubuntu's repository, rather than the (very old) Debian unstable ones, and from what I heard on IRC it seems like this is a rather doable thing for Ubuntu as we don't have to worry about Debian politics so much. Hence, I am writing this email. I'd be willing to maintain the Wine packages for Ubuntu, as well as related ones such as winetools. There's other work for me to do as well, but I suppose the first step is to coordinate things in here and make this happen. There's quite a bit on my todo list for the moment -Documentation is a seemingly never-ending task, both for man pages and packaging guidelines and such. -The Wine documentation also needs to be moved into the right places. I was recently given a very helpful tip on IRC about making Wine's User Guide work with standard freedesktop.org help interfaces, and I'll be committing the patch upstream shortly. -Tweaking the wine package to get it a bit more right is also important. I've got a bunch of little changes I need to make for the next release written up on my penboard at the moment. Hopefully soon I can start erasing them. -Updating the Wine User Guide itself. I've already got chapter 1, the introduction, finished. Obviously, this is a good thing to do. -Updating the Wine web site to make things easier (example is this page: http://www.winehq.org/site/download-deb ). That site may undergo a slight redesign in the future too. -I've got a special project I've been trying for a while involving porting Miranda Instant Messenger with Winelib. In theory, I could convert it into an Ubuntu package that runs on all arches with the Wine package installed, even though Miranda is a windows program. If this becomes easy it represents an amazingly huge step in application compatibility - it won't be long before we start seeing other OSS apps like DC++ or FileZilla coming into Ubuntu packages. Writing a howto guide for this based on my experience is part of this goal. -The Winelib documentation needs updating as well. I plan on using my experience trying to port Miranda IM to help it out. -Winetools, a useful program for running Wine, also needs packaging. I've got it almost finished at this point, although I need some help with some issues I've been having. More on this in IRC. As for the Wine package itself, the current versions of the Wine and Winetools packages are in my webspace, here: deb http://tuzakey.com/~scott/apt binary/ deb-src http://tuzakey.com/~scott/apt source/ The Wine package at first glance seems a bit different from some Debian standards, for various reasons. First off, even though Wine has some seemingly shared libraries, I haven't split them off. This is because only wine binaries can really use them, and they need the latest version anyway. Both windows apps called with Wine and winelib apps still need to be handled by the same wineserver (in case they message eachother, amid other reasons), and so they are both completely dependent on the Wine binaries anyway. Furthermore, since it's the same wineserver coordinating everything on a system, it needs to have the same library in use - since it's basically impossible to get use out of more than one libwine.so.x in a system, it makes little sense to support this. Secondly, Wine, not being an emulator, has some rather important differences between architectures. Wine really does need 3 different packages for the 3 different Ubuntu arches, as they each have some challenges. The i386 one is the simplest, and is basically standard Wine. The PPC arch can only run winelib apps, so it may need some trimming down and added documentation to prevent confusion. The 64 bit version of Wine represents the most interesting challenge, as Wine will still need the old 32 bit libraries to run 32 bit Windows applications. According to forum posts I've read, Wine packages not currently doing this easily is actually a blocker for some users in switching to 64 bit Ubuntu. Wine has some rather unique things which make it harder to maintain. -Arch issues, like mentioned above -PAX issues will inevitably come up again. This was an issue that came up before, although with Ubuntu using the latest Wine it will certainly be an easier one to tackle. -Until Wine hits a stable release, which seems to be perpetually six months away, Wine is updated monthly. This means an old and possibly unstable version of Wine will perpetually end up in Universe, unless we backport it. This may or may not be a problem from the User's perspective. Either way, I'll make the latest available at winehq.org. Clearly the best long term solution is to move to a more stable Wine release - I've been doing my part to help clear our 0.9 blocker bugs like the lack of documentation, but I can't do much for core Wine development other than cheer on my compatriots. We may want to have an entirely new applications menu for Wine. I envision having Wine installed and then having it create a new folder Applications->Wine, which will contain the Winecfg program labeled "Configure Wine" as well as a near empty start menu with Wine's shipped winelib Notepad program. When other windows programs get installed, they can be put in the Wine start menu there. The PPC arch may have no real need of start menu, though. We can run winelib apps on ppc, such as the hypothetical Miranda-IM package, but it might make sense to put that somewhere other than Wine's start menu (such as Applications->Internet) In fact, we may want to have packaged winelib apps specifically not go in the Wine folder for all arches, even arches that support a Wine start menu. I guess I should make a page for myself on the Ubuntu wiki. I'll likely put a huge todo list for myself up there as well, if for no other reason than to remind me of what I still want to do. I really like what's going on with Ubuntu. Most encouraging are emails I get like the following: ----------------- Dear Scott, I am using your wine packages from: deb http://wine.sourceforge.net/apt/ binary/ deb-src http://wine.sourceforge.net/apt/ source/ and it's just great! Thank you! It would be way cool if your packages could be the official Debian ones. I sincerely hope that some solution can be found, so that it can happen. Best regards, Silvestre ----------------- I also had a man message me on AIM thanking me profusely for the Wine packages. Apparently he had won several hundred dollars using a Windows poker program via Wine. The ability of Wine to put usable icons on the desktop really impresses users, and I really look forward to the day when we can have a usable start menu too. Anyway, I'd appreciate feedback and thoughts about this, as well as help with my package. Meet me in IRC, I'm YokoZar. Thanks, Scott Ritchie

Jan. 30, 2005

Re: Q? system wide variables

by Jakob Eriksson

Oliver Stieber wrote: >Hi, > I need to track the 'fake' amount of video memory >in total, allocated and left for Directx 9 and would >like to track it across wine so that DDraw, DirectX, >DxDiag and X11 driver can all sing from the same song >sheet. > >What's the best place to do this? is the registry code >fast enough or should I add a new function to the X11 >driver so that I can request and release 'fake' video >memory and make all other AvailableVideoMemory >requests ask X11 driver? > >I would expect the use to be able to override by the >initial amount, even if there's code that detects it >since wine,X and openGL manage video memory >differently to windows, direct draw and D3D. > > How will this affect ReactOS? They don't use X11. They even plan on loading native binary 3D drivers. regards, Jakob

Jan. 30, 2005

Fwd: Re: Q? system wide variables

by Oliver Stieber

Thought I should send this to winedev as well, is it just me, or is the reply address set to the sender and not winedev? > > --- Mike Hearn <mh(a)codeweavers.com> wrote: > > Yes, the registry is fine though if you are going > to > > detect this at > > startup it may be worth making it volatile. > > > > I'm not sure it makes sense to have a config > option > > here. How many people > > will think to adjust it? > > > Well, initially I can't won't be able to detect the > value since I don't known of any other way that > talking to the video card and requesting one of it's > registers. (I've got the Matrox g400 code somewhere > on an old HDD written in djgcc for dos about 5 years > ago) Transgaming make this user configurable so I > shouldn't imagine it's an 'easy' task to detect the > top ten cards. > > It could also be handy for stubborn applications > when > I want to lie and don't care how slow the > application > runs (or if it slips into AGP instead of > on-videoboard > ram) you can get something for windows that fakes a > lot of directX functions so that you can play games > that must have pixelshaders 2.0 on older cards just > missing some effects. > > I would send the link, but I can't remember right > now > and I'm just off down the pub. > > I'll start by getting everthing to talk to the > registry and work on the volile bit when we have > some > detection code. > > > > > > > > > > ___________________________________________________________ > > ALL-NEW Yahoo! Messenger - all new features - even > more fun! http://uk.messenger.yahoo.com > ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

Jan. 29, 2005

Re: ole:register_ifstub couldn't get IPSFactory buffer for interface

by Rob Shearman

Mike Hearn wrote: >On Sat, 2005-01-29 at 13:16 -0600, Rob Shearman wrote: > > >>InstallShield uses MIDL-compiled proxies/stubs. The fixme's are from >>functions being executed on the error path, triggered by the pipe >>problem. >> >> > >Hmm, did we remove the 1 || hack while I wasn't watching? I thought we >were going to wait a bit before letting it use its own compiled >marshallers instead of the typelib marshaller. > > No, but it might have interfaces that it cannot marshal without using MIDL-generated proxies. And yes, once we get InstallShield working again we'll have to try and break it again by removing the RegiseterTypeLib hack. Rob

Jan. 29, 2005

Re: Q? system wide variables

by Mike Hearn

On Sat, 29 Jan 2005 19:44:33 +0000, Oliver Stieber wrote: > What's the best place to do this? is the registry code > fast enough or should I add a new function to the X11 > driver so that I can request and release 'fake' video > memory and make all other AvailableVideoMemory > requests ask X11 driver? > > I would expect the use to be able to override by the > initial amount, even if there's code that detects it > since wine,X and openGL manage video memory > differently to windows, direct draw and D3D. Yes, the registry is fine though if you are going to detect this at startup it may be worth making it volatile. I'm not sure it makes sense to have a config option here. How many people will think to adjust it? If so though a (non volatile) registry key is the way forward.

Jan. 29, 2005