Folks-

Has anyone worked on getting their OI-based apps to run on OIL? We're working with a Linux distributor to make OI available to all their users, and they were looking for some real world applications.

If any out there, please contact me at mike@revelation.com

Thanks

Mike,

We would like to offer our app as an option on Linux. However, we are using OLEs which are not compatible with Linux. ;(

I believe that it has been discussed that certain things can be done by RTI to make the deployment of an OI app between Windows and Linux possible and "easy" even if OLEs are used.

I'm not complaining as I am very happy with OI. However, I am curious if this restriction will be eliminated? I sure that this may be a major chore so I'm not expecting this to be implemented in 7.12

Thanks,

Ray

I know i am butting in (yeah .. so but I am not sure Mike can do anything about the controls outside of their area .. the SRP controls will need to be checked and hopefully Don will be able to ensure them working in Linux .. we too are looking at running the app we are porting in Linux .. the ole's will be a hurtle

dsig

Actually I think the OLE controls just need to be compiled in the MainWin environment - which basically provides a Win32 API implementation for Linux.

Yep .. but RTI wont be responsible for the OLE controls that developers use

Nope, you'll need your own MainWin toolkit.

At the moment they only seem to be offering an HTTP Status 404. Not a very catchy name really. Hopefully they'll change it once the website is working again .

Hi Ray,

It wasn't an option for you, as you started your port from AREV to OI two years ahead of me, but I have avoided OLE controls in my own port.

I feel that with a little more work, OI native code can provide comparable, or even better, functionality than OLE controls. For this reason, I am working to finish up my OLE-free development framework and release it free as an open source add-on to OI for the Linux enabled.

So what OLE controls would you need to replace?

Gerald

Chris, Dave, or anyone:

Nope, you'll need your own MainWin toolkit.

If I understand correctly, the "MainWin" kit makes possible the use of OLEs in Linux?

Is this something that RTI and each developer will need?

Do you know if RTI have this toolkit?

With this kit, is it just a matter of "recompiling" some code to make the OLE useable in Linux?

Didn't know what was involved in porting OLE to Linux, but I always heard that it was possible so this MainWin was interesting info.

Thanks,

Ray Chan

Gerald,

So what OLE controls would you need to replace?

The questions isn't how many OLE controls needs to be replaced. There aren't that many. However, we have used them extensively, e.g., Tabs. They have really enhanced the look of the application.

Having an app that can go both way Linux and Windows would be appealing. Theorectically, we could, except for the OLEs, as the Basic code should be the same, but we would not be enamored in retro-fitting our forms back to pre-OLEs. It would really hurt our visual senses . The optimal solution for us is to have a world where we could "swing" both way without a lot of hassle. Now that is Power AND Beauty .

Also isn't the printing different under OIL or has this been changed?

How in the world can you give your app away for free?

Ray

RC] If I understand correctly, the "MainWin" kit makes possible the use of OLEs in Linux?

actually it allows you to build OLEs that can be used in either environments.

RC] Is this something that RTI and each developer will need?

I believe this is what RTI used to 'recompile' and otherwise make their code 'Nixable'

RC] With this kit, is it just a matter of "recompiling" some code to make the OLE useable in Linux?

in a perfect world .. yes. But you can't compile the OLE. If don has the source to the oles you are using then he would have to do it.

RC] Didn't know what was involved in porting OLE to Linux, but I always heard that it was possible so this MainWin was interesting info.

If you are only using the OI set of tools then nothing else is needed .. well except possibly printing routines. Not sure yet what RTI has in store for that ..

dsig

Gerald,

I feel that with a little more work, OI native code can provide comparable, or even better, functionality than OLE controls.

Can you clarify what you mean by "a little more work"? It is hard to tell whether you mean Revelation needs to do a little more work to make improve Basic+ or whether you mean the OpenInsight programmer needs to do a little more work to make Basic+ as is provide "comparable, or even better, functionality".

I think it would also be helpful to know how you qualify "better" functionality.

For the sake of a true comparison, let's remove the word "OLE" out of the discussion. After all, as far as OI is concerned, OLE is simply a means of delivering technology written in a different environment into the application. This can also be handled in other ways such as DLL calls.

The real question is, "Can Basic+ provide comparable, or even better, functionality" than other languages? Well if the language being used is a lower level language then I think the answer is a resounding "no". Basic+ itself is an interpreted language which is ultimately managed by a C++ written engine. I fail to see how Basic+ can ever be extended to a point where it can perform better than the foundation it is built upon.

My personal opinion is that Basic+ is awesome for business rules and rapid application development. But it is not well suited (nor is it meant to be) for utilities or high-end GUI requirements. As a case in point, Revelaton was pretty successful with the Database Manager and the Table Builder being ported into Basic+. However, I am dubious that the Form Designer could be moved over with the same degree of success.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Ray,

If you saw some of my native BASIC+ features, you might feel that the appearance of my application, developed entirely with the OI toolset of today, is very competitive. Some of these features came at a significant programming cost, however.

Don is asking how BASIC+ as a language could possibly compare with the C++ it is based on. But this is not at all the issue here. The issue is, does the OI development library today provide adequate capabilities for producing a complete GUI implementation without resorting to OLE or other external code? My answer is, YES! Otherwise, Don, you have seen the interface in ATLAS. Tell me what generic elements are missing from this interface and required by the developer? This is not to demean your own framework and OLE controls, which really are intended to extend the generic OI product in different ways.

Regarding TAB controls, aren't these a part of the native OI interface now, and therefore supported in both OI and OIL? OLE controls can be ported to OIL, but I would prefer to see Revelation Software doing the porting and supporting the resulting product.

The real issue is, how do we get to a world which can "swing both ways," as Ray puts it. I am saying that OI wasn't there when I started, but it seems to be there now. And I would like to help keep OI at the forefront of cross-platform development.

Now Ray, you are asking how I can give my app away. I have no intention of giving away WARES, which is my application. But the tools I use to build it, the ATLAS framework, is never likely to earn me a living. So I am offering to make it open source, open distribution, if it would benefit the OI community. Some developers have already asked for pieces of it – multi-datavolume support, access-restriced menus, task scheduling, index rebuilding – but why not take it all?

Your thoughts are welcome.

Gerald

Ray,

You need something more than the MainWin toolkit – the original source code for your OLE control. This is probably the sticking point with porting OLEs to Linux. Also, after you use the MainWin toolkit, you end up with controls which must be maintained in Windows and re-ported with each design change.

Gerald

Gerald,

Don is asking how BASIC+ as a language could possibly compare with the C++ it is based on. But this is not at all the issue here. The issue is, does the OI development library today provide adequate capabilities for producing a complete GUI implementation without resorting to OLE or other external code? My answer is, YES! Otherwise, Don, you have seen the interface in ATLAS. Tell me what generic elements are missing from this interface and required by the developer? This is not to demean your own framework and OLE controls, which really are intended to extend the generic OI product in different ways.

First, none of this is personal nor do I take it as a criticism of what we are doing.

Second, this is not what you originally said. I was primarily responding to the assertion that Basic+ can "provide even better functionality than OLE controls". Now, if you are qualifying this statement by saying that what you meant is that Basic+ can give us "good enough" GUI but it is better than OLE because it can port to Linux (via OIL) then I don't have a problem with that. But I do consider the face value meaning of your original statement to say something quite different than what you are saying now.

Third, you really are preaching to the choir (with me) regarding the remarkable capabilities of Basic+. Before OLE came along, we (like Sprezz and perhaps a few others) exploited the ability of Basic+, DLLs, WinAPIs, sub-classing, etc., to create some impressive GUI in OI…even when it was still a 16-bit product!

Fourth, you mentioned the "significant programming cost" to get your OI GUI utilities where they are now. I don't think this should be overlooked because it is really significant. Despite the flexibility of Basic+, it really does take a greater amount of time (= money) and effort to create advanced GUI functionality than it does with a lower level language. Furthermore, the more complex the GUI becomes, the slower Basic+ will perform. It also requires a bit of skill and knowledge that many OI developers don't have.

Fifth, you asked me to tell you what generic elements are missing from your interface. Well, you see, this is all a matter of preference and perspective. Honestly, before you developed your OI controls I could have said "nothing". I was willing to say "nothing" when OI was still 16-bit. What do you have that makes your application able to function in ways that it couldn't before? This is not to demean your own toolset, which is quite impressive I'll admit, but it seems to me that we are both trying to provide tools that scratch an itch. In our case, OLE is the best way (for now) to deliver that scratch.

Sixth, again I want to point out that whatever we (i.e. you or us) accomplish it is based upon a lower level foundation that ultimately gives us what we want. As a delivery mechanism, OLE might very well stay limited to Windows. However, the internals of our OLE controls can be delivered in other ways as well. The future of OI and OIL will be very interesting to watch with the radical changes in operating systems on the horizon. It seems that you are able to tap into Linux now since you provide turn-key systems. Our clients, on the other hand, will not see a Linux desktop for at least 5 years (if at all). Therefore we are taking advantage of the best way to deliver high-end GUI and we'll worry about what OIL can support when it becomes necessary. I am fairly confident that if Linux (and OIL) succeed, then by that time Revelation will have opened up a few more doors for us to port our technology over.

Regarding TAB controls, aren't these a part of the native OI interface now, and therefore supported in both OI and OIL? OLE controls can be ported to OIL, but I would prefer to see Revelation Software doing the porting and supporting the resulting product.

This makes sense for common controls, but every development environment relies upon third-party controls to enhance a developer's toolkit. While porting OLE to Linux via MainWin still remains to be seen (this hasn't been proven), the bottom line is whether or not Revelation ports and supports their own product, there still should be a way for participating third-party toolsets to be ported as well. This doesn't mean that Revelation needs to do the porting for us, but we do need to know what path we should follow to get there.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Gerald,

Also, after you use the MainWin toolkit, you end up with controls which must be maintained in Windows and re-ported with each design change.

If OI/OIL provides an alternative way to incorporate custom controls then this won't be true. But you are really stating the obvious. Even OpenInsight itself is victim to this, no?

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Thanks, Don.

You've pretty much said it all. Developers will always expect "something" additional in OI fit their products. You are making that "something" out of OLE, and this suits your clients. I am making that "something" from the BASIC+ tools, because I want portability and future compatibility. I have always understood our different aims, even if I haven't expressed this adequately.

Gerald

Don,

Exactly so. Mike has said that Linux releases lags Windows by a day to compensate for the porting. There was a time, however, when things were worse. AREV for OS/2 stayed at 2.01 level FOREVER because there was no mechanism for porting, and the code never got synchronized for release again. I am afraid of what would happen if responsibility for porting is divided up amongst several parties, and not synchronized. I wouldn't want OIL to fail the way the OS/2 product did.

Gerald

GL] Regarding TAB controls, aren't these a part of the native OI interface now, and therefore supported in both OI and OIL? OLE controls can be ported to OIL, but I would prefer to see Revelation Software doing the porting and supporting the resulting product.

This i think is the most important point.

I would be very interested in learning about your framework.

Yes .. but once again the toolset in under the control of RTI. It is their responsibility to make sure any OLE's that they incorporate into the product can be ported.

umm .. actually .. while i was still product manager for Arev Jim cancelled the OS/2 port. I wont say why i think it was cancelled but it wasn't anything to do with porting. The only problem we had to lick with the port was Write speeds ..

dsig

All-

Just to try and clear things up…

We use MS Visual Studio to write our DLL and EXE files which are used by Windows.

We use MainWin to compile same C++ code into executables used by Linux.

MainWin enables a developer to take their C++ code and compile it into executables as well. It's expensive, and we pay a license for each development copy that we sell. SOme details can be found here:

http://www.mainsoft.com/products/mainwin.aspx

We're looking at Code Weavers as a longer term, cheaper alternative.

Thanks-

Mike Ruane

Revelation Software

ot wanting to dwell on it but the OS/2 product was truely amazing - I remember having about 20 separate sessions open on the one desktop - all functioning beautifully. My understanding was OS/2 product was canned because simply there were no buyers (except me, and perhaps because of a mistaken order).

My understanding was OS/2 product was canned because simply there were no buyers (except me, and perhaps because of a mistaken order).

Oddly enough I am quite surprised with how many developers I meet that claim to have used AREV for OS/2. Based on its demise I would have thought very few people had used it. In my first corporate job with a large insurance company (which is where I learned AREV) OS/2 was the OS of choice but they were using AREV for DOS. I had just begun to install and play with AREV for OS/2 (along with OI 1.0/2.0) when I left the company. I'm not sure what happened to their Revelation applications after I left.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Great and all for the whole thread, but I have a Vice President of Marketing for a major Linux distribution who is ready to offer OIL as a download for their customers (and they have many thousands of customers) and would also like to have some applcations to go with it.

Anyone want to move their app to OIL? Contact me via email and we'll see what we can do to help.

Mike

Yes, AREV for OS/2 died for lack of purchases, but not for lack of would-be purchasers. I migrated my code to the features of 2.12 – printer drivers, non-centralized indexing, etc. – and therefore never got to use the OS/2 product. Yet, all of my sites were running on Citrix multiuser! I better shut up now before I say anything else.

View this thread on the Works forum...