Well, it's been a while since the last update, so I thought it'd be worthwhile to write about where we're up to. Looking at the TODO list on WineHQ, it seems the remaining work falls into two areas: * A bit of documentation stuff (rather worryingly "fix the docs build system" says a patch was submitted last *year*, but is still labelled as work in progress!). * Configuration, ie winecfg and an auto setup wizard thingy. John K Hohm has been making great progress lately with making DLLs self register, but unfortunately nobody has really stepped up to work on winecfg. We may or may not get the patches from Mark it seems :| There are a few other things, like DLL separation, and completing the work to make DLLs self register. I have a whole load of time with not much to do during September, so I might sit down and try and get some patches off for winecfg, seeing as merging in Oves OLE code is going to be slow work at my current rate of patch committing :( Is there anything else we might need? I'm tempted to say that having InstallShield work is a priority, as it seems to have broken quite a bit lately. On the TODO list it says that some window management hacks exist but more debugging work is needed - does anybody know the status of that? A lot of InstallShield installers at the moment fail due to that X11 ConfigureWindow error - how hard is this to fix? Having a wine.inf to set up a new installation, does anybody have details on that? Is this just a case of eating our own dogfood, or is it really a must have for 0.9? thanks -mike
On 25 Aug 2003, Mike Hearn wrote:
* A bit of documentation stuff (rather worryingly "fix the docs build system" says a patch was submitted last *year*, but is still labelled as work in progress!).
As we discussed during the IRC session, this is not a blocker. Essentially I need to get back to it and resubmit some patches that have fallen off Jeremy's radar.
* Configuration, ie winecfg and an auto setup wizard thingy. John K Hohm has been making great progress lately with making DLLs self register, but unfortunately nobody has really stepped up to work on winecfg. We may or may not get the patches from Mark it seems :|
Yes, this one is a bugger. Mark, what is that status on those patches? If you have anything, it's better to send them in so others can pick up where you guys left off.
There are a few other things, like DLL separation, and completing the work to make DLLs self register.
This is critical, IIRC. John just submitted some more patches, but I have no idea how much work there's left. John, can you give us a status update on the DLLs self register task?
Is there anything else we might need? I'm tempted to say that having InstallShield work is a priority, as it seems to have broken quite a bit lately.
IIRC, Alexandre also wanted InstallShield to work properly for 0.9.
On the TODO list it says that some window management hacks exist but more debugging work is needed - does anybody know the status of that? A lot of InstallShield installers at the moment fail due to that X11 ConfigureWindow error - how hard is this to fix?
That's Alexandre's turf -- anything new in that area?
Having a wine.inf to set up a new installation, does anybody have details on that? Is this just a case of eating our own dogfood, or is it really a must have for 0.9?
I guess a bit of both. I'm not sure it's a blocker for 0.9, but if we have the self register stuff in place + the configuration cleanup, we might as well do it, and have a more modular installation... -- Dimi.
On Mon, 2003-08-25 at 18:51, Dimitrie O. Paun wrote:
As we discussed during the IRC session, this is not a blocker. Essentially I need to get back to it and resubmit some patches that have fallen off Jeremy's radar.
OK, that sounds good.
Yes, this one is a bugger. Mark, what is that status on those patches? If you have anything, it's better to send them in so others can pick up where you guys left off.
I just prodded Mark on MSN. I'm looking over the code now, and have a few questions about how to proceed. The primary issue is that we can't have the same setting pulled both from the config file and the registry, can we? So, as winecfg gradually gets more functional, parts of the config file will stop being referenced in favour of reg entries set via winecfg, but not all parts of winecfg will actually do anything. So: 1) How do we stop users being confused because they updated and now their config file doesn't seem to work anymore? 2) How do we stop users being confused because they started winecfg but the changes they make don't always take effect? Possibilities include: * Warnings on startup if a part of the config file exists. IE if we move version settings into the registry, output err: lines if those keys are in the config file to get the user to remove them. * Disabling any controls that don't do anything in the winecfg program, so the user can't edit them.
This is critical, IIRC. John just submitted some more patches, but I have no idea how much work there's left. John, can you give us a status update on the DLLs self register task?
Why is it critical?
IIRC, Alexandre also wanted InstallShield to work properly for 0.9.
That's good to hear.
On 25 Aug 2003, Mike Hearn wrote:
I just prodded Mark on MSN. I'm looking over the code now, and have a few questions about how to proceed.
Yay!
The primary issue is that we can't have the same setting pulled both from the config file and the registry, can we?
No. winecfg should not care at all about the config file. It should get to the values through registry calls, as we do all over Wine ATM. This calls will be routed to the values from the config file for now, but we'll switch them to go to the real registry when we're ready. For writting, we should also use the registry functions. I'm not sure what would happen now if you're trying to write config values through the registry, they may get saved in the registry. Which is just cool, it just means that winecfg will not be really function until the big switch, but that should be in the near future :)
1) How do we stop users being confused because they updated and now their config file doesn't seem to work anymore? 2) How do we stop users being confused because they started winecfg but the changes they make don't always take effect?
Possibilities include: * Warnings on startup if a part of the config file exists. IE if we move version settings into the registry, output err: lines if those keys are in the config file to get the user to remove them. * Disabling any controls that don't do anything in the winecfg program, so the user can't edit them.
I don't think it makes sense to plan for the long haul -- we should get it over with this transitional period sooner rather than later. I think it's acceptable to just leave the current warning about the fact that winecfg is non-functional. When we switch, we'll drop the warning and we're done. -- Dimi.
On Mon, 2003-08-25 at 22:06, Mike Hearn wrote:
Yes, this one is a bugger. Mark, what is that status on those patches? If you have anything, it's better to send them in so others can pick up where you guys left off.
So, Mark has sent me his work, unfortunately not as a patch against CVS so I'll have to do some merging in. It implements the GUI (but not backend) for drive editing. Having answers for the issues I raised before would make doing this a lot easier. I couldn't find the section that turned the config file into the registry entries, for instance :( Fortunately, I don't think it's all that necessary in order to do a bit of work here..... thanks -mike
On 25 Aug 2003, Mike Hearn wrote:
So, Mark has sent me his work, unfortunately not as a patch against CVS so I'll have to do some merging in. It implements the GUI (but not backend) for drive editing.
Cool. I think it would be very useful to have a list of missing GUI elements for our config values. Right now it's all foggy on where we are with this effort. -- Dimi.
Mike Hearn wrote:
Is there anything else we might need? I'm tempted to say that having InstallShield work is a priority, as it seems to have broken quite a bit lately.
Well, if development after 0.9 is going to focus on correctness while getting to 1.0, lots of conformance testing is a must. I really was looking forward to write a testing application that runs all the tests, but I can't figure out why make crosstest is not working. (It's something to do about linking with ntdll.) If crosstest was working, the meta-test program could be built as part of daily wine builds. Windows testers (myself included) could download the daily crosstest and automatically upload results into some stats page on winehq. regards, Jakob
--- Jakob Eriksson <jakob(a)vmlinux.org> wrote:
Well, if development after 0.9 is going to focus on correctness while getting to 1.0, lots of conformance testing is a must. I really was looking forward to write a testing application that runs all the tests, but I can't figure out why make crosstest is not working. (It's something to do about linking with ntdll.)
If crosstest was working, the meta-test program could be built as part of daily wine builds. Windows testers (myself included) could download the daily crosstest and automatically upload results into some stats page on winehq.
Can you rename mingws libmsvcrt.a or libntdll.a and see if that fixes it? On Windows with Mingw+MSYS I have to rename libmsvcrt.a to build the tests. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Steven Edwards <steven_ed4153(a)yahoo.com> writes:
--- Jakob Eriksson <jakob(a)vmlinux.org> wrote:
I can't figure out why make crosstest is not working. (It's something to do about linking with ntdll.)
Can you rename mingws libmsvcrt.a or libntdll.a and see if that fixes it? On Windows with Mingw+MSYS I have to rename libmsvcrt.a to build the tests.
Seems like it does! Actually, I changed -lntdll to -lmsvcrt on the command line, but all the same. Now can somebody try whether http://afavant.elte.hu/~wferi/advapi32_crosstest.exe works on Win9x? Feri.
Ferenc Wagner wrote:
't figure out why make crosstest is not working. (It's something to do about linking with ntdll.)
Can you rename mingws libmsvcrt.a or libntdll.a and see if that fixes it? On Windows with Mingw+MSYS I have to rename libmsvcrt.a to build the tests.
Seems like it does! Actually, I changed -lntdll to -lmsvcrt on the command line, but all the same.
Now can somebody try whether http://afavant.elte.hu/~wferi/advapi32_crosstest.exe works on Win9x?
Mingw crosstest and build still has some problems and some of the import libs are not correct. I will not have time to look at this for a while and I dont cross-compile so if anyone is interested have at it. Thanks Steven
Ferenc Wagner wrote:
Now can somebody try whether http://afavant.elte.hu/~wferi/advapi32_crosstest.exe works on Win9x? Feri.
Passed all tests on Windows ME. (ME is of the 9x family.) regards, Jakob
I've been able to find a lot of pages on how to run debug commands when trying to run WinApps, but they all seem to be oriented towards programmers working on modifying the code. I'm not a programmer, so my work would be more towards trying to figure out what combination of native vs builtin DLLs to use, what other DLLs I need to track down, what registry entries to modify, etc. For example; one of the apps I'd need to figure out is eBay's TurboLister (sometimes known as TurtleLister or TurdLister; it's for posting ebay auctions). I know it needs MSIE, but beyond that it still has other problems. I managed to get the install to run under Crossover Office, but then it crashes about 1 minute into using it. So what I need is a site with information on how to kludge an installation to run some particular app.
Steven Edwards wrote:
--- Jakob Eriksson <jakob(a)vmlinux.org> wrote:
If crosstest was working, the meta-test program could be built as part of daily wine builds.
Can you rename mingws libmsvcrt.a or libntdll.a and see if that fixes it? On Windows with Mingw+MSYS I have to rename libmsvcrt.a to build the tests.
Rename ntdll into what? :-) Sorry if I am being thick. Jakob
On Wed, 27 Aug 2003, Jakob Eriksson wrote:
I really was looking forward to write a testing application that runs all the tests.
Yes, that would be very nice indeed. Such a test shell should be something like the JUnit stuff (http://www.junit.org). Here are few things that I'd want in such an app: -- it should be a single executable (.exe preferably) containing all unit tests -- when started, it should go through these steps: * display a dialog explaining what it is and what it would do. The dialog would have OK/Cancel buttons * if OKed to proceed, the program should extract the tests, run them, and collect results, inspect the system. While doing these, it should inform the user what is going on ("Extracting tests...". "Running test X", etc.) The failed tests should be listed below. * when done, it should present the user with 3 buttons: o View Report o Send Report o Cancel * on "Send Report", the report should be emailed to a special mailing list, from where it's later picked up by some scripts and analysed. * We should be able to disable the UI via a command line switch, to allow for automatic execution.
If crosstest was working, the meta-test program could be built as part of daily wine builds. Windows testers (myself included) could download the daily crosstest and automatically upload results into some stats page on winehq.
Yes, that would be the idea. With such a setup, we can have a well-known URL (such as http://www.winehq.org/winetests.exe), and you guys can set up fully automated download-test cycles at predetermined intervals. -- Dimi.
Dimitrie O. Paun wrote:
something like the JUnit stuff (http://www.junit.org). Here are few things that I'd want in such an app: -- it should be a single executable (.exe preferably) containing all unit tests -- when started, it should go through these steps: * display a dialog explaining what it is and what it would do. The dialog would have OK/Cancel buttons * if OKed to proceed, the program should extract the tests, run them, and collect results, inspect the system. While doing these, it should inform the user what is going on ("Extracting tests...". "Running test X", etc.) The failed tests should be listed below. * when done, it should present the user with 3 buttons: o View Report o Send Report o Cancel * on "Send Report", the report should be emailed to a special mailing list, from where it's later picked up by some scripts and analysed. * We should be able to disable the UI via a command line switch, to allow for automatic execution.
This is almost exactly what I had in mind, save some details on how the reporting back to the Wine project should be done. Jakob
On Thu, 28 Aug 2003, Jakob Eriksson wrote:
This is almost exactly what I had in mind, save some details on how the reporting back to the Wine project should be done.
Cool -- I'm glad we're on the same wavelength. As for reporting back, email is one idea. It has a number of advantages: -- can be archived, forwarded, etc. -- delivery is asynchronous -- we get web access to the archives for free -- we don't have to worry about naming -- people can review such reports right from their mail clients -- it is safe and secure The only question is: how hard is it to send an email through the Win32 API (sorry, never used that before)? Other options would be to setup a web download area, or a dedicated ftp site. But these are tricky in other ways. -- Dimi.
Dimitrie O. Paun wrote:
The only question is: how hard is it to send an email through the Win32 API (sorry, never used that before)?
No idea about using Win32 specific facilities for mail-sending, but I have SMTP client code using Winsock to do this in a touch over 100 (dull, uninteresting) lines. The way I do this is to specify my own mail server by default, skipping any local servers. If the user can't do that (firewall reasons, etc.), I provide the option for them to configure their local mail server (also From: address, etc.) -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com
On Thu, 28 Aug 2003, Jon Bright wrote:
No idea about using Win32 specific facilities for mail-sending, but I have SMTP client code using Winsock to do this in a touch over 100 (dull, uninteresting) lines. The way I do this is to specify my own mail server by default, skipping any local servers. If the user can't do that (firewall reasons, etc.), I provide the option for them to configure their local mail server (also From: address, etc.)
Sounds interesting -- can you LGPL that code, so we can potentially make use of it in winetests? -- Dimi.
and whats more is that it can even be fully automated for the testers, as they can use windows task scheduler to download and run the tests and send it back to the list.. so microsoft has made 1 thing so far that is to our advantage >:-D --- "Dimitrie O. Paun" <dimi(a)intelliware.ca> wrote:
On Wed, 27 Aug 2003, Jakob Eriksson wrote:
I really was looking forward to write a testing application that runs all the tests.
Yes, that would be very nice indeed. Such a test shell should be something like the JUnit stuff (http://www.junit.org). Here are few things that I'd want in such an app: -- it should be a single executable (.exe preferably) containing all unit tests -- when started, it should go through these steps: * display a dialog explaining what it is and what it would do. The dialog would have OK/Cancel buttons * if OKed to proceed, the program should extract the tests, run them, and collect results, inspect the system. While doing these, it should inform the user what is going on ("Extracting tests...". "Running test X", etc.) The failed tests should be listed below. * when done, it should present the user with 3 buttons: o View Report o Send Report o Cancel * on "Send Report", the report should be emailed to a special mailing list, from where it's later picked up by some scripts and analysed. * We should be able to disable the UI via a command line switch, to allow for automatic execution.
If crosstest was working, the meta-test program could be built as part of daily wine builds. Windows testers (myself included) could download the daily crosstest and automatically upload results into some stats page on winehq.
Yes, that would be the idea. With such a setup, we can have a well-known URL (such as http://www.winehq.org/winetests.exe), and you guys can set up fully automated download-test cycles at predetermined intervals.
-- Dimi.
===== -- Dustin Navea Minor Contributor, http://www.winehq.com Bugzilla Janitor, http://bugs.winehq.com Network Admin, irc://irc.blynk.net (down) __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
participants (9)
-
Dimitrie O. Paun -
Dustin Navea -
Ferenc Wagner -
Jakob Eriksson -
Jakob Eriksson -
James E. LaBarre -
Jon Bright -
Mike Hearn -
Steven Edwards