Common runtime image per OS or strip individually?

Phone:	+49 (0) 9131 18-97393
Fax:	+49 (0) 9131 18-94045

Thanks Karl – 2 inclusive verses 0 separate

 

-----Original Message-----
From: BREITH Karl-Albert FEEC-G (AREVA NP GmbH) [mailto:[hidden email]]
Sent: 14 November 2006 9:43 p.m.
To: Stewart MacLean; [hidden email]
Subject: AW: Common runtime image per OS or strip individually?

 

 

Yes, I make only one runtime image for HP, Linux and Windows XP.

This doesn't cost much memory and no runtime (CPU-time).

But must only be qualified once.

 

Karl

 

________________________________________________________________

Karl-Albert Breith
AREVA NP GmbH
FEEC - G
Freyeslebenstrasse 1
91058 Erlangen

Phone:	+49 (0) 9131 18-97393
Fax:	+49 (0) 9131 18-94045

mail to:  [hidden email]
An AREVA and Siemens company

 

 

---

Von: Stewart MacLean [mailto:[hidden email]]
Gesendet: Dienstag, 14. November 2006 09:33
An: [hidden email]
Betreff: Common runtime image per OS or strip individually?

Hi,

 

I’m curious as what the general consensus is regarding packaging runtime images.

 

Do people just create one “all OS inclusive image”, or do they create separate ones for each target operating system vm?

 

Thanks,

 

Stewart

 

PS For simplicity, I’m currently adopting the “all OS inclusive image” at the moment

For my tools as published on the Sepher website, I make one image for all platforms. Including the Macintosh. The packaging process itself of course demands specific directory layouts, but that is another issue.
The image therefore needs to be able to morph itself to those platforms, for example for the look and feel, or specific extras as on the Windows platform, so the code usually needs to test sometimes on which platform it finds itself. This is also the case for directory layout-specific issues (where is the runtime?) that can be quite different on esp. Windows and Mac.

I found it more sound and safe to deploy individually stripped images
for each platform (MacOS X and Windows) - stripped and packaged on the
target platform itself.

Different platforms require distinct application/executable packaging,
resource handling, byte order(!), custom Look & Feel and native OS APIs,
for example printer dialogs. For a comprehensive desktop app, this can
add up to a serious amount of code.

I'd prefer better native platform integration against binary image
portability. All those "portable" resources in an image (cursors,
bitmaps, colors, whatever) could greatly benefit from being tailored to
the target OS upon packaging already. This would probably also provide
better support for native widgets.

Universal platform transparency is great for development, but absolutely
useless at runtime: No product will ever run on two machines at the same
time ;-)

Andre

The VWInstaller is one image for all plats.  We use CDEveryWhere
(CDEveryWhere.com) to create a hybrid .iso CD image that works on
joliet, rockridge and hfs. The installUnix script chooses the proper
unix vm at startup.

Dave

Stewart MacLean wrote:

Thanks for this, Andre.

Yes, I have some concerns as to how my app will behave under non windows
platforms. I've deliberately ketp the UI very simple, even though the
underlying model is quite complex.

It's the printing that I'm concerned about...

Btw, can you tell me what the image start up directory is when a Mac
user double clicks on the app? Is it MacOS? (where the engine lives)?

Cheers,

Stewart
APIs, absolutely
>useless at runtime: No product will ever run on two machines at the
same
>time ;-)
>
>Andre

Thanks for this, Dave.

Ages ago I did look at the VWInstaller. I recall I found it completely
obtuse, and just couldn't get into it. Also, as I anticipate OS specific
download over the web, I have no need for a generic CD.

Over time, I've developed my own packaging, executable, installer
generation framework, which is OS specific (for the executable and
installer). (sounds like most others have taken this route too...)

Cheers,

Stewart
runtime image"
>> at the moment
>>

Stewart MacLean wrote:
> Btw, can you tell me what the image start up directory is when a Mac
> user double clicks on the app? Is it MacOS? (where the engine lives)
Hi Stewart,

AFAIK, there is no well defined startup default directory on MacOS X,
because launching an app via double-click triggers some hidden magic
behind the scenes that totally confuses this. I always had problems
losing my change.log sources when I started VW by a double-click instead
of a console command.

I solved this problem simply by setting a default directory
programmatically with #beCurrentDirectory very early during the launch
of the software. You can extract the absolute path of the app from
CEnvironment>>commandLine.

HTH
Andre

> Different platforms require distinct application/executable packaging,
> resource handling, byte order(!), custom Look & Feel and native OS APIs,
> for example printer dialogs. For a comprehensive desktop app, this can
> add up to a serious amount of code.

I like the approach of building up an image (instead of stripping it
down). The way I do this is deciding which (Store) packages to keep in
the runtime. With Pollock I hoped that platform specific code would be
factored out in separate packages. This does not seem to be the case,
so I will need to include code for all the supported OSes, even if
Windows is my only target.

Having said that, my guess is that the amount of memory used for
platform specific code & resources is not that huge. At least the
Pollock tests (which probably consume a lot more memory) are in their
own package.

Runar

Runar Jordahl wrote:
If I understood Cincom's roadmap right, Pollock is meant to become the
supporting framework for native widgets. I strongly believe that keeping
OS-specific code in separate packages is the only safe way to maintain a
clean base framework. It is just too tempting to do quick & dirty "cross
platform" hacks if all OSes are always present in an image. This would
render it impossible over the years to keep them apart.

Just my 2ct.
Andre

Samuel, that is great!  :-) First I thought I had an old version where
this separation is not in place. When I looked, the version I have
loaded also has this separation. Sorry about the mistake.

Runar

Stewart,

        my advice would be, strip and package individually for specific platforms only if startup time is extremely important, or if you have open windows saved in the application.  I can't see the saving in footprint (perhaps 10's of k, not more) as valuable; VW doesn't yet run in embedded contexts (AFAIK).

If an application is typically very short running, like some simple unix filter.  Packaging per platform will remove some overead in the VM in swizzling pointers in the image and some more overhead in the image doing things like switching font classes, window classes etc to suit the new platform.  Packaging per platform reduces these activities and so can give faster startup.

If an ap;lication has open windows it requires "a small amount of programming" within the Wraper framework to code an app model to rebuild its application window.  So you'l either see a window displayed in the look of the platform upon which the window was first created ro you'll see an ugly repaint of the application windows as they are rebuilt.  You see this if you startup the base image on a suitably slow non-Windows machine, because the base image is built on Windows and both the Launcher and Workspace redraw themselves.

Sam can say or sure, but I think Pollock is going to eliminate this last cause as Pollock can do dynamic rebuilding and so should be able to adopt the platform look when an application window is first opened on launching the system.

HTH


"Stewart MacLean" <[hidden email]> wrote:
| Hi,
|
| I'm curious as what the general consensus is regarding packaging runtime
| images.
|
| Do people just create one "all OS inclusive image", or do they create
| separate ones for each target operating system vm?
|
| Thanks,
|
| Stewart
|
| PS For simplicity, I'm currently adopting the "all OS inclusive image"
| at the moment

| -----
Eliot Miranda                 ,,,^..^,,,                mailto:[hidden email]
VisualWorks Engineering, Cincom  Smalltalk: scene not herd  Tel +1 408 216 4581
3350 Scott Blvd, Bldg 36 Suite B, Santa Clara, CA 95054 USA Fax +1 408 216 4500

Hi Eliot,

Thanks for this.

As startup time is not "extremely" important and that I open the main
window from scratch upon start up, I've decided to use a generic runtime
image as you suggest.

Having said that, as my system builder framework needs to do platform
specific configuration for building the executable, the directory tree,
and the installer, it would be easily adapted to package per platform
should this be required.

As for Pollock, I've gone the wrapper route. Unless there is a really
compelling reason I won't be porting it.

Cheers,

Stewart
open
>windows saved in the application.  I can't see the saving in footprint
>(perhaps 10's of k, not more) as valuable; VW doesn't yet run in
embedded
>contexts (AFAIK).
>
>If an application is typically very short running, like some simple
unix
>filter.  Packaging per platform will remove some overead in the VM in
>swizzling pointers in the image and some more overhead in the image
doing
>things like switching font classes, window classes etc to suit the new
>platform.  Packaging per platform reduces these activities and so can
give
>faster startup.
>
>If an ap;lication has open windows it requires "a small amount of
>programming" within the Wraper framework to code an app model to
rebuild
>its application window.  So you'l either see a window displayed in the
look
>of the platform upon which the window was first created ro you'll see
an
>ugly repaint of the application windows as they are rebuilt.  You see
this
>if you startup the base image on a suitably slow non-Windows machine,
>because the base image is built on Windows and both the Launcher and
>Workspace redraw themselves.
>
>Sam can say or sure, but I think Pollock is going to eliminate this
last
>cause as Pollock can do dynamic rebuilding and so should be able to
adopt
>the platform look when an application window is first opened on
launching
>the system.
>
>HTH
>
>
>"Stewart MacLean" <[hidden email]> wrote:
>| Hi,
>|
>| I'm curious as what the general consensus is regarding packaging
runtime image"
>| at the moment
>
>| -----
>Eliot Miranda                 ,,,^..^,,,
>mailto:[hidden email]
>VisualWorks Engineering, Cincom  Smalltalk: scene not herd  Tel +1 408
216
>4581
>3350 Scott Blvd, Bldg 36 Suite B, Santa Clara, CA 95054 USA Fax +1 408
216
>4500
>