PwrDev on Suse (Linux)

[Edwin Knoppert]

A while ago a test was done to run PwrDev on Linux.
Due the way the form designer worked it did not work correct under Linux.
Since a few weeks i have been rewritting the IDE and the result is now very nice.

You can see it here:

http://www.hellobasic.com/images/pwrdevonsuse1.png

Note that i don't give any guarantee for using PwrDev under Linux.
Crossover (wine) was used to run PwrDev and the PowerBASIC compiler.
To be clear, PwrDev is a Windows application.

Just wanted to share this, i begin to like the Linux os somewhat

[John Spikowski]

Looks great Edwin !

I'm looking forward to continue my testing now that the child form issue is resolved.

BTW: I wonder if Chris ever got EZGUI to run under Wine. I know he submitted the Designer to Codeweavers but at the time he hadn't tested it under Linux yet. I guess he just expected others to test it for him.

John

[Chris Boss]

Yes, I now have the latest version of CrossOver loaded on Suse 9.0 pro and have done some initial testing.

While there is quite a lot that CrossOver supports (in the Windows API) I have already found a significant number of problems with its handling of the API.

I am going to help CrossOver to try to solve some of those problems. I have been contact with their Vice President of sales and their R&D have a copy of EZGUI runtimes and a demo for testing.

Edwin,

feel free to share with me any problems you find with Wine or CrossOver since I have their "ear" at the moment.

Good to see Pwrdev works on Wine/CrossOver.

The key here is to test as many API's as possible on it.

Thats why they found EZGUI interesting, since the runtimes access so many different unique API's , far more than the average program does.

Maybe by sharing experiences working with CrossOver we can help improve the product.

[John Spikowski]

Good news Chris.

I agree with you that ALL PowerBASIC vendors should work together and report Win32API issues they find running under CO/Wine. This helps everyone. (not just PowerBASIC users)

The PowerBASIC (PBWin 8.04) Codeweavers forum is more then likely a good place to meet on common ground issues

PowerBASIC - Codeweavers

John

[John Spikowski]

I'm not playing favorites here but it does speak well for PwrDev for it's design and maintaining a strict win32API direction. The problems Chris is having with EZGUI may not show up on Windows now but as Microsoft depreciates little or non-document API features, this will become more of a problem even for EZGUI Windows users.

Slick comes with a price.

[Eros Olmi]

thinBasic seems working fine under Linux (Wine) and Mac (CrossOver) for Console, Gui and OpenGL scrips.

http://community.thinbasic.com/index.php?topic=1287.0

http://www.codeweavers.com/compatibility/browse/name/?app_id=4352;screenshot=1

thinBasic is 95% PowerBasic coded.

[John Spikowski]

thinBASIC is a wonderful interpreter an should be in every Basic programmers toolbox. The ability to run under Wine is just another testament of the fine job that was done with this product and the compiler that generated it.


John

[Chris Boss]

John,

The problem with EZGUI on CrossOver (Wine) have nothing to do with the design of the product.

The problem results, because EZGUI accesses a significant number of Windows API's and messages.

EZGUI is a complete GUI engine so it handles so many different tasks, that sooner or later it will access some API that CrossOver does handle well.

As an example, the Sprite engine and the DIB engine work great. Actually it worked better than I expected.

A problem that did show up though, was the use of the "Dirty Rectangles" technique to speed up animation. Windows allows you to invailidate a region, rather than a simple rectangle so only parts of the image that change need to be repainted.

CrossOver appears to invalidate the entire client area, no matter what, so the animation slows down significantly.

Another problem showed up with the Thread engine. Likely CrossOver handles threads , but maybe EZGUI's use of ciritical sections to syncronize the threads caused a problem. The Thread engine simply does not work. If CrossOver doesn't support threads, that would be bad, but I am assuming it may simply a problem with critical sections.

The RichEdit support in CrossOver doesn't support a number of features, such as hyperlinks and it does not support EM_FORMATRANGE (or at least to a window DC).

The Control drag engine works well, but EZGUI's drag icon feature for the Listview crashes the app on CrossOver.

The problems I am finding have more to do with CrossOver not fully handling all API tasks yet. They have a ways to go yet.

The people at CrossOver are very interested in testing EZGUI because it does so many API tasks. I doubt there are any applications that access as many different API's as does the EZGUI runtimes.

On the positive side, CrossOver handles ownerdraw quite well. The only problem I saw with that is that for some reason it repaint the background of controls with white before doing the ownerdraw and it causes a terrible flicker effect.

Amazingly, my custom controls worked very well.

As far as following strict API rules, EZGUI does this as well as any other PB tool. I research the API's I use in great detail and I have found no serious problems with the EZGUI runtime on any Windows platform.
My customers tell me it is very stable and reliable on most versions of Windows.
It is reliable on Win95 to Vista.

Remember that EZGUI does many things that no other Visual Designer does so of course it may show up weaknesses in CrossOver not found by other products.
You should see how well its Sprite engine works on CrossOver. The anti-aliasing, animation and alphablending works flawlessly.
If CrossOver could fix the region updating problem, it would be even better.

One reason I posted here, is that because EZGUI does so many API tasks in so many different areas, it is more likely that I will find problems with CrossOver before others do. Because I use a GUI engine, it will be easier for me to find the problem areas and to find the problem API's that need to be fixed.

Other designers may work well themselves, but what really matters is all the API's their users may use if adding code to the app. EZGUI users don't write API code usually. If a problem occurs in their apps on CrossOver, it will be in my GUI engine and I should be able to track down the problem. Those that code using the API won't know whether they will have a problem on CrossOver until they actual test their fully compiled app on CrossOver, no matter how well the designer itself may work.

This appears to be why CrossOver is so interested in EZGUI.

I have been emailing back and forth with their Vice President of sales and they have been very responsive to my emails.
They were the ones that contacted me. Once they saw the description of what EZGUI is, they were very interested in it.
Thats why I sent them a demo version (has the designer) and about 45 test apps and the runtimes so they could do some testing on their own.

[John Spikowski]

Chris,

Have you tried moving a few key Windows DLL's to Linux and replace the Wine built-in's? If nothing else it may be a way to move forward with your testing and narrow where the problems might be.

I solved my .chm help issues in PowerBASIC this way by using Windows native DLL's and OCX's.

As time permits, I'm trying to build a script that will replace all Wine built-ins that their Windows counterparts are better suited.

Based on what I have read, there are only a few must have built-in DLL's to make Wine work. If I can make my Windows based applications run better under Linux using pieces and parts from the Windows OS carcass I left behind then so be it.

John

[Chris Boss]

John,

Unless a Windows operating system DLL is a redistributable one it is illegal to copy it to another PC. Also the redistribution rights likely only apply to a true Windows machine and not a Linux PC.

I want to work on making EZGUI run well (or help improve CrossOver) by finding areas CrossOver is weak in. Just because EZGUI found such weaknesses quicker than other apps, does not mean EZGUI is flawed. It simply means CrossOver has weak areas that haven't been addressed yet.

There could some PB apps which actually use more API's than EZGUI does, but if it doesn't use specific APIs which CrossOver is weak on, then it won't show up problems that are there.

For example how many PB apps (or Visual Designers) use the "dirty rectangles" technique, like EZGUI does ? Likely very few or even none.

So if CrossOver has a problem with updating regions, then it will show up a problem with EZGUI and not other PB apps.

Just because one PB apps shows up more problems when running on CrossOver than do others, doesn't have anything to do with how well the app is written and how compatible it is with Windows itself.

If the application has a good record of compatibility with Windows (which is what it was written for), but it has problems on CrossOver, the problem lies with CrossOver and not the PB app.

Just because PwrDev appears to have less problems with CrossOver than EZGUI has nothing to do with how well written each one is.

The problems with EZGUI were mostly with test apps that fully test many Windows features. The Designer worked quite well actually. The only real problem I had was with the HTML help and that had mostly to do with missing fonts on my Linux install. Linux replaces the fonts in the help file with some ugly looking fonts. Also the HTML help window couldn't be closed. You had to close the app, before the help could close.

The test apps were small EZGUI apps that tested many of the features of the runtime, such as animation, ownerdraw, custom controls, threads, common controls, etc.

[John Spikowski]

Unless a Windows operating system DLL is a redistributable one it is illegal to copy it to another PC. Also the redistribution rights likely only apply to a true Windows machine and not a Linux PC.

Don't confuse redistributable with reuse. I own a registered copy of XP Pro. If I replace the OS on my PC with Linux that once had Windows OS and reuse software I already paid for in a new environment, I can't see where there is a problem.

Sorry, I don't see your point and I think you missed mine altogether. Using native DLL's to troubleshoot Wine is a practice widely used by the community working on the Wine project. You really should spend some time reviewing the Codeweavers and Wine sites. There is a wealth of information there that may save you some time. Since your an advocate, there are extended forums you can search to find solutions or at least recognition to the problems you face.

John

[Chris Boss]

John,

Most Linux users are not going to spend the money for an expensive license to Windows. If a user did purchase a license to XP, it would make more sense to simply set up the PC to duel boot to differen operating systems or to use virtual environment like VMware to run the other operating system.

The purpose of CrossOver (or Wine) is to allow Windows apps to run a purely Linux system without the need for Windows.

Thats what I am talking about. Sure if you buy a Windows license fine, but my concerns are about running Windows apps on a 100% linux system with CrossOver. In that case the Windows DLL's are not an option and to copy them in that instance (without a Windows license) would be illegal. In essence using true Windows OS DLLs is not a viable option for those who want a purely Linux solution.

[Chris Boss]

Actually the better way to test CrossOver with EZGUI, IMO, is to simply run two PC's, one with Windows and the other Linux with CrossOver side by side. Run the same apps and compare the results.

Since it is easy to test specific features with EZGUI, I can compare those specific features and if they don't match, simply examine what API's or messages are being used and then report that to CrossOver.

It is up to them to examine their own code to see how they impliment specific tasks.

Likely in a number of cases, a specific feature is simply not currently supported. The Windows API being as extensive as it is, I really doubt either Wine or CrossOver has even come close to implimenting it all. The functions may be there, but not every feature of the function may be implimented and many messages may not be implimented yet.

The other problem is Wine/CrossOver is not a replacement GUI for the Linux GUI, but it simply converts Windows calls to their Linux GUI counterpart. This means some things in Windows simply can't be implimented or at least exactly as it is in windows.

The real test is to compare a Windows system and Linux system running side by side and examine the differences.

Trying to fudge things by installing true windows OS DLL's on the Linux system make work for some, but it doesn't not make a lot of sense to my way of testing.

[John Spikowski]

*** WARNING *** You are now in a lab environment and should leave all forms of monetary value and purchasing power at the door.

Have you tried moving a few key Windows DLL's to Linux and replace the Wine built-in's? If nothing else it may be a way to move forward with your testing and narrow where the problems might be.

Where did the subject of redistributables and their use under Wine ever get mentioned? Sometimes I wonder why I even bother to try and help.


John

[Chris Boss]

One other point.

It is difficult to be an expert on both the Windows API and the Linux emulators and and the GUIs' they use.

I am an experienced Windows API programmer and all my testing is on Windows systems (from 95 to Vista). If my software runs flawlessly on the operating system it was designed for, then it is well designed IMO and well built.

Now to run such software on an emulator of Windows which depends upon a totally foreign operating system and GUI, if something does not work right, it makes little sense to assume the Windows app is in error.

The greatest likelyhood is that the emulator is in error and it needs to be tweaked to match Windows more closely or that the Linux GUI simply can not handle the task as well as Windows.

The two operating systems (Linux and Windows) are not equal in all things. Linux has a long way to go to get even close to what Windows can do. True it can do many things nearly as well, but it is simply not a replacement for Windows. While it makes sense to try to make ones software more compatible with Wine/CrossOver, one can not expect Linux to run a true Windows app perfectly or even as well.

I am coming at this (working with CrossOver) not with a Linux mindset, but with a Windows mindset. That may seem strange to Linux purists, but IMO it is the best way to improve CrossOver to make it more compatible with Windows. I am not trying to make my software more compatible with CrossOver. I want to help CrossOver to become more compatible with Windows. The first step to that, is to not immediately assume that my software is at fault, rather than CrossOver. I assume that CrossOver may more likely be at fault in fully emulating Windows.

Do you really think that either Wine or CrossOver in its current state is even close to being a perfect emulation of Windows ?

That is hard to believe.

[Chris Boss]

John,


You said to move Windows OS DLL's to Linux.

As I state above, in the case of not having a Windows license (which many Linux users won't have) one can not copy Windows OS DLL's to a non windows PC. I mentioned redistributables, since some Windows OS DLL's are considered redistributables (ie. GDI+) and can be copied to a PC along with ones application, so one may think this would apply to a non-Windows PC as well (so they may think no Windows license is needed), but I would have to think the Windows license would stipulate such redistributables are only for Windows PC's.

The point is, copying Windows DLL's to a Linux PC (except in the case of having a License for Windows which you plan to install on the same PC) is illegal and to expect Linux users to spend the money for a full Windows license (which ranges from $150 to $200) is not a viable solution.

[John Spikowski]

Chris,

This is how Codeweavers works.

They sell an easy to use shell for the Wine project. They are active developers and contribute back all Wine improvements. It is in their best interest to make as many Windows application run under CO/Wine as possible. They make their money in the following ways.

• Selling CrossOver
• Helping companies that want to move their Windows application to Linux without a rewrite.
• Working on Windows software where people have made pledges (bounty) to get the programs working ASAP.
• Working with people like yourself that has found some obscure bug they may have missed. (eat the cost of this and write it off as R&D)

They were over helpful when I mentioned I would like to wrap a few Linux shared object till they realized there wasn't a financial commitment in the future.

Plan on doing most of your debugging on your own and get involved in the Wine forums. There are programmers there that can speak your language.


John

[Brice Manuel]

Chris, I think you misread/misunderstood John's comments. I am sure John will correct me if I am wrong. But here is an objective view after having read everything:

1. John was not implying that PwrDev was better written than EZGUI. John was trying to point out that since EZGUI uses some API calls that are not as widely used as other Windows apps, that would be the reason that some things might not work in Crossover.

John also made a point that reliance on those more obsecure API calls could also lead to problems in future versions of Windows if MS decides to drop support for the older, less used API calls.

John was not trying to say that PwrDev was better or worse than EZGUI or that EZGUI was badly programmed.

2. John was only suggesting you move the Windows DLLs over to Linux for your own diagnostic use to compare them to the ones with Wine to see if it is a problem with Wine's DLLs (The MS ones would work if that was the case) or if it is not the Wine DLLs, but something in Wine itself that hasn't been implemented yet.

John was not implying that EUs should have to buy Windows, or transfer DLLs to Linux or that your program should require Windows DLLs to be installed on Linux so it would run properly.

3. We have yet another thread started by the author of a competing GUI product and instead of discussing PwrDev, the thread has been hijacked and taken over by EZGUI discussion.

[John Spikowski]

Thanks Brice.

John

[Chris Boss]

First, the reason I posted in this thread was to encourage discussion among third party developers like Edwin and myself to help each other find the weaknesses in CrossOver, not to highjack the thread. I have been very complimentary of Edwins tools in the past if one reads my many other posts. Since EZGUI does handle a number of tasks, other tools may not, it is likely I may stumble across problems with CrossOver other may not have yet and this may benefit them.

obscure API calls

Brice, neither you nor John have ever seen my source code so to say that I use obscure API calls is simply being uninformed. Trust me, I research the API docs quite well and the API's I use are not only well documented and likely will be part of the API for a long time, but the code I use is nothing unusual.

The problem is that in writing an emulator of Windows, like Wine/CrossOver there is no way they can emulate everything or support every feature.

For example the EM_FORMATRANGE message for the RichEdit is a well used message, but it appears to be either not supported or broken in CrossOver. CrossOver does not support hyperlinking in the richedit, which is not an old nor obscure API, but is part of the more recent richedit features in Windows (and an important one).

The fact that I quickly found a number of things that do not work on CrossOver does not imply (or prove) I use obscure API's.

I would think that because I have found a number of weaknesses in the current version of CrossOver, it would be helpful to other PB'ers.

Even the people at CrossOver appear to be honest that they have a long way to go. For example I was told they still had problems with DIB's in CrossOver. Amazingly for a feature (DIB's) that they felt they had problems with, EZGUI's use of DIB's work flawlessly. A number of test apps which used DIB's extensively to impliment image filters and animation (sprites) worked great.