On March 18, 2003 23:11, Alex Pavloff wrote: <clip>
> I'm trying to think of gui apps that have been ported from Unix (any
> variant) to Windows. Can't think of any off the top of my head.
<clip>

Most of the better CAD and CAE software originated on Unix and were later ported to Windows. Until a few years ago, there weren't any CAD packages which originated on Windows that weren't fairly pathetic. The CAD vendors were interested in PCs because the hardware was cheaper than the workstations they had been using. I'm not sure if anyone really saved any money on this idea at the time though, because everyone seemed to have no end of PC software problems, especially with the video and graphic tablet drivers.

With PCs becoming more powerful and Linux being so cheap, some of the high end software seems to be going *back* to Unix (Linux) and away from Windows (that's if they ever left Unix to begin with). You can get supercomputers and computing clusters which use Unix, but there isn't anything equivalent to this for Windows, and its nice (or even imperative) to be able to send big models to a compute server for simulation. Standardising on Linux lets the software vendors keep a single code base instead of having to target two operating systems simultaneously. Since everyone wants to share models between customer and supplier, this seems to be driving the market towards the higher end software whether you need the power or not.

This is obviously an esoteric example, but this branch of the thread isn't really talking about anything important anyway.

> Cross platform development
> is hard, irregardless of where and which way you're trying to go. As
> stated earlier, Qt is proprietary on all platforms save Linux, and gtk
> doesn't work worth a damn on Windows. FLTK is stale. wxWindows is
> probably the best choice of all, but even then it suffers in its range of
> controls compared to any of the native toolsets.
<clip>

I was under the impression that the big problem with GUI type apps is the GUI toolkit, rather than the actual OS. Moving between one GUI toolkit and another on the same operating system (even with the same actual GUI) seems to be as big of a problem as moving between operating systems.

There seems to be a lot more interest in cross platform development lately. I think that a lot of this has to do with the fact that computing these days is less and less about PCs, and more and more about connecting things together, especially things which are *not* PCs. Even mainframes and minis are making a big come back, except that they're now called "servers". Looking only at what is happening on desktop PCs means missing a lot of the overall picture.

************************
Michael Griffin
London, Ont. Canada
************************

 

(In this connection, very recently I have collected an abstract on " detecting races in relay ladder logic programs" from EECS department, University of California. This is in Pdf format and size is 238 kb. I don't know how I will send this to you all. May be this will be benicificial to RLL programmer.)

 

Hi Alex

I'm gonna save the moderator some trouble and close it up here. I am bringing up engineering points and receiving personal slams in return. Soon after this point, _I_ get censored.

[email protected] wrote:
> ------------ Forwarded Message ------------
> From: Alex Pavloff
>
>>But my tools are portable, free, and work well everywhere except
>>Windows. Let's stick to the point.
>
> No Curt, they're not. Did you read my point? Qt, your GUI toolkit of
> choice, is not free (speech OR beer) on Windows.

I can work with gtk or a half doxens others that are. If I were a purist I probably would.

>
>>But, why _can't_ anyone who isn't an MS partner do well with Windows?
>
> I was not aware Borland or Metrowerks were Microsoft partners, yet they seem
> to do well with Windows.
Actually, Borland was a party in the complaint regarding Secret API's and the resulting disadvantage. Not sure about Metroworks.

>
>>It certainly isn't my fault. Or yours. And many vertical GUI apps have
>>gone from UNIX to Windows. There never was much shrinkwrap for UNIX.
>>StarOffice/OpenOffice and Netscape/Mozilla come to mind as crossplatform
>>but they were pretty much snuffed in the MS world and are now coming
>>from the other side.
>
>>But has much to do with monopolies.
>
> Yes Curt, we know. If we want to know about your opinions on monopolies we
> can go read Slashdot for 5 minutes.
>
I don't frequent Slashdot, it has little relevence to automation.

>
>>Can you run it anyplace else?
>
> No, but my customers don't run anything besides Windows on the desktop, so
> who cares?
>
There are many who would probably like any alternative, So I care.

>
>>>And you get this 25% figure from... where? How do you
>>calculate this? Do
>>>you could all dynamically linked libraries? The entire
>>
>>Windows kernel?
>>
>>>GDI? What?
>>
>>Working set refers to the code that resides in core while an app
>>is running. It is an estimate as I haven't seen tools for Windows.
>
> So you made the number up.
Call it an educated guess from the footprint of a "Hello World" Windows program. MS isn't talking.

>
>>More of what is running
>>in a Linux app is in portable OSS parts not strictly part of Linux.
>
> Here's the problem.
>
> OSS != Portable. You are under the impression that the two are equal.
> They're not.
>
No, OSS is more portable and portability is much better between OSS systems and compatibles than closed systems. That is obvious.

>
>>But is it portable?
>
> No, but my customers don't run anything besides Windows on the desktop, so
> who cares?
>
>>I can if I want to. I can write to SVGAlib or X or Qt or even write
>>directly to the framebuffer. The low level ones would be non-portable
>>of course, except to 100 or so other versions of Linux at the source
>>code level.
>
> X is an API.
> QT is an API.
>
> Over the last 5 years using various flavors of Linux/Xfree86 and Windows,
> Linux/X has been slower and much worse than Windows as a GUI environment.
> I've used both systems. You haven't.
Yes, design for modularity and portability has disadvantages as well as advantages. At the end of the day, WIndows stuff runs on Windows. OSS stuff runs just about everywhere else. And often on Windows too.

>
>>What I was implying is that you will add another layer as you use the
>>windows stuff no matter what. I doubt that would be as efficient as
>>a native app.
>
> You think writing X or QT calls means that you have a native app?
No I think weiting to X or Qt is more portable.

>
> <snip rest of the post>
>
> Curt, its obvious you haven't done much GUI development or Windows
> development. As usual, you're spouting FUD (Windows is slow! Microsoft is
> evil! Open source magically makes the world a better place!), and I have
> neither the time nor desire to argue with a zealot that doesn't even care to
> get the facts on the opposite side of their point correct.
>
>>Sorry Alex, but having no good OS choices at work really bugs me.
>>It may eventually drive me away from automation altogether. But,
>>I'll do what I can to change it first. For everyone's freedom and
>>to advance the state of the art.
>
> Reposting slashdot rants does nothing for freedom, advancing state of the
> art, or changing anyone's mind. Get off the soapbox, go write some code,
> come back when you have an alternative.

I leave it as an exercise to the reader as to who has ranted through this whole thread.

Regards

cww

> Alex Pavloff - [email protected]
> Eason Technology -- www.eason.com

 

> From: Curt Wuollet
> To: [email protected]
> Subject: Re: SOFT: What are the software/language used to
> develop the RSLo gix-500 or Step-7?
>
> Hi Alex
>
> I'm gonna save the moderator some trouble and close it up here.
> I am bringing up engineering points and receiving personal slams
> in return. Soon after this point, _I_ get censored.
The automation list has the right to not post anything they feel like. They're not the government, so it isn't censorhip. If they decide to throw away every post from people born on Thursdays away, more power to them!


> > From: Alex Pavloff
> >
> >>But my tools are portable, free, and work well everywhere except
> >>Windows. Let's stick to the point.
> >
> > No Curt, they're not. Did you read my point? Qt, your GUI
> toolkit of
> > choice, is not free (speech OR beer) on Windows.
>
> I can work with gtk or a half doxens others that are. If I were a purist
> I probably would.
Err, I also already pointed out that gtk barely works on Windows and is far behind the current version for Linux.

> >>But, why _can't_ anyone who isn't an MS partner do well
> with Windows?
> >
> > I was not aware Borland or Metrowerks were Microsoft partners, yet they
seem
> > to do well with Windows.
>
> Actually, Borland was a party in the complaint regarding Secret API's and
the resulting disadvantage.
> Not sure about Metroworks.


Borland's complaint was that Microsoft's _Application_ software itself was exploiting secret APIs -- not that Microsoft tools were the only ones that could exploit APIs. When it comes to development on a Windows platform, there is nothing inherent about Visual Studio that makes it the only choice for Windows development. Visual Studio doesn't magically make more APIs available. If you can access an API in Visual Studio, you can access it from anywhere.

> >>Working set refers to the code that resides in core while an app
> >>is running. It is an estimate as I haven't seen tools for Windows.
> >
> > So you made the number up.
>
> Call it an educated guess from the footprint of a "Hello World"
> Windows program. MS isn't talking.
MS isn't talking? They don't have to. Off I go.

The following program

#include <stdio.h>

int main() { int i; printf("Hello World!\n"); scanf("%d",&i); return 0; }

Default settings used in all cases, which use shared libraries/DLLs.

Run under Windows, compiled via Visual Studio 6.0 with Release mode default settings, memory info determined via Norton Process viewer:

45KB executable, Memory usage - Image: 1244KB

Compiled under gcc 3.2 with -02, looking in /proc/<pid>/status

12KB executable, Memory usage - VmSize: 1324KB.

Seems to me that there ain't much of a difference here. Your mantra of "performance is always better on Linux because Microsoft APIs suck" is, well, not as absolute as you would believe.

> No, OSS is more portable and portability is much better between OSS
> systems and compatibles than closed systems. That is obvious.
No, its not. I see GUI software portable between variants of UNIX. I see GUI-less software portable between Windows/*ix/MacOS. I see new front-ends bolted onto command lines tools ported from Unix to Windows (see Autocad and lots of other expensive software for indications of this).

The only portability advantage of OSS is that a user, if he wanted to, could take the time and port the system over himself. The fact that this software is open source doesn't magically wave the technical problems away.

> Yes, design for modularity and portability has disadvantages as well
> as advantages. At the end of the day, WIndows stuff runs on Windows.
> OSS stuff runs just about everywhere else. And often on Windows too.
OSS stuff runs just about everywhere else? Lets look at an example. Mozilla, which runs on Linux/Windows/Mac, wrote their own GUI toolkit, ported that to every platform, and then wrote Mozilla to that. It was the skill of the engineers (most of them Netscape employees being paid to do this, by the way) and the fact that Mozilla and their toolkit is open source is utterly irrelevant.

> >>What I was implying is that you will add another layer as
> you use the
> >>windows stuff no matter what. I doubt that would be as efficient as
> >>a native app.
> >
> > You think writing X or QT calls means that you have a native app?
> No I think weiting to X or Qt is more portable.
Writing to X means you're portable to all the X servers in the world. Congratulations, you can now run your application on every flavor of Unix. Call me not so impressed, because I don't think anyone will really care that your automation app can run with recompilation on AIX, HP-UX and Solaris.

Coming back to QT - writing to that means that you've got non-standard C++ code and going to platform other than Linux means that you're going to have to fork over cash and step away from the GPLed code. That's not exactly what you're hoping for.

> I leave it as an exercise to the reader as to who has ranted through this
whole thread.

I'm the one posting number and examples to working software. You're the one half-remembering old court cases.

Alex Pavloff - [email protected] Eason Technology -- www.eason.com

 

Please, I beg... I'm actually here to read and learn from you all. Please as you use abbreviations, please do well to also add the meaning of those abbreviations, it will go a long way to help me understand the comments I'm reading... Thank you'll.