One of the things I'm going to try and do maybe this week or next is move all the complicated classpath/native library code into Java to simplify the launchers and make it easier to use repos for this stuff.

Ideally I'd like to map key Java system properties into a single "platform-key" which can be used as the directory name of platform specific jars and native libraries. I might even make a nice class, since we already have some platform hooks in fwt::Desktop.

If you know of an existing mechanism/naming convention please let me know.

Also for those of you running Linux, OS X, or more exotic platforms could you please provide:

• uname
• java.vm.* system properties
• os.* system properties
• sun.arch.* system properties
• sun.cpu.* system properties
• any other system properties or environment vars you think relevant
• if you have successfully run FWT, which SWT version did you use?

If you see a duplicate already posted, no need to reply.

Thanks!

For OS X:

• uname -a ==> Darwin mandarb.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386
• uname ==> Darwin
• java.vm.info: mixed mode
• java.vm.name: Java HotSpot(TM) 64-Bit Server VM
• java.vm.specification.name: Java Virtual Machine Specification
• java.vm.specification.vendor: Sun Microsystems Inc.
• java.vm.specification.version: 1.0
• java.vm.vendor: Apple Inc.
• java.vm.version: 14.1-b02-90
• os.arch: x86_64
• os.name: Mac OS X
• os.version: 10.6.1
• sun.arch.data.model: 64
• sun.cpu.endian: little
• sun.cpu.isalist:

Ubuntu 64 bits (x86):

class EnvDump
{
	static Void main()
	{
		List heads := ["java.vm.","os.","sun.arch.","sun.cpu."]
		Process(["uname","-a"]).run
		Sys.env.each |Str val, Str key| 
		{
			heads.each |Str head|
			{
				if(key.startsWith(head))
					echo("$key -> \t $val")
			}
		} 
	}
}

./bin/fan /home/thibautc/env.fan 
Linux frenchie 2.6.24-24-generic #1 SMP Tue Jul 7 19:10:36 UTC 2009 x86_64 GNU/Linux
java.vm.version -> 	 14.2-b01
java.vm.vendor -> 	 Sun Microsystems Inc.
os.arch -> 	 amd64
sun.cpu.endian -> 	 little
os.name -> 	 Linux
sun.arch.data.model -> 	 64
os.version -> 	 2.6.24-24-generic
java.vm.info -> 	 mixed mode
sun.cpu.isalist -> 	 
java.vm.specification.vendor -> 	 Sun Microsystems Inc.
java.vm.name -> 	 Java HotSpot(TM) 64-Bit Server VM
java.vm.specification.version -> 	 1.0
java.vm.specification.name -> 	 Java Virtual Machine Specification

Ubuntu 9.04 32-bit

Linux matthew 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux
java.vm.version -> 	 14.2-b01
java.vm.vendor -> 	 Sun Microsystems Inc.
os.arch -> 	 i386
sun.cpu.endian -> 	 little
os.name -> 	 Linux
sun.arch.data.model -> 	 32
os.version -> 	 2.6.28-15-generic
java.vm.info -> 	 mixed mode
sun.cpu.isalist -> 	 
java.vm.specification.vendor -> 	 Sun Microsystems Inc.
java.vm.name -> 	 Java HotSpot(TM) Server VM
java.vm.specification.version -> 	 1.0
java.vm.specification.name -> 	 Java Virtual Machine Specification

Hi folks,

eclipse use (OS, Windowing System, Arch) triple to identify target platform like (linux.gtk.x86), which is proven by millions of end-users, so I'd like to propose to use exactly the same approach. Also "windowing system" seems to be obsolete now (since SWT Motif is not supported on Linux and Solaris anymore, so windowing system could be derived from OS)...

Eclipse relies on os.arch and os.name properties, which are used almost as JVM provide with several mapping to reduce set of final combinations (like amd64 is mapped to x86_64). Set of oses and architectures is following:

public static final String OS_WIN32 = "win32";//$NON-NLS-1$
public static final String OS_LINUX = "linux";//$NON-NLS-1$
public static final String OS_AIX = "aix";//$NON-NLS-1$
public static final String OS_SOLARIS = "solaris";//$NON-NLS-1$	
public static final String OS_HPUX = "hpux";//$NON-NLS-1$
public static final String OS_QNX = "qnx";//$NON-NLS-1$
public static final String OS_MACOSX = "macosx";//$NON-NLS-1$
public static final String OS_OS400 = "os/400"; //$NON-NLS-1$
public static final String OS_OS390 = "os/390"; //$NON-NLS-1$
public static final String OS_ZOS = "z/os"; //$NON-NLS-1$

Architectures:

public static final String ARCH_X86 = "x86";//$NON-NLS-1$
public static final String ARCH_PA_RISC = "PA_RISC";//$NON-NLS-1$
public static final String ARCH_PPC = "ppc";//$NON-NLS-1$
public static final String ARCH_SPARC = "sparc";//$NON-NLS-1$
public static final String ARCH_X86_64 = "x86_64";//$NON-NLS-1$
public static final String ARCH_IA64 = "ia64"; //$NON-NLS-1$
public static final String ARCH_IA64_32 = "ia64_32";//$NON-NLS-1$

I believe this set of oses and architectures is enough ot cover 99.99% of JVMs in use.

Kind Regards, Andrey

Looking more into this: JVM do this job pretty well with os.name and os.arch, so eclipse do very small number of "fixes":

Arch fixes: i386 -> x86, amd64 -> x86_64

OS fixes: Mac OS* -> OS_MACOSX, SunOS -> OS_SOLARIS, Win* -> OS_WIN32

case is ignored for all comparison operations

Also "windowing system" seems to be obsolete now (since SWT Motif is not supported on Linux and Solaris anymore, so windowing system could be derived from OS)...

Linux has both GTK and QT. Windows has both win32 and WPF. Mac has both Cocoa and Carbon. So I don't think we can count out the windowing system part.

Yup, you're right

Thanks for the responses.

@andrey said: eclipse use (OS, Windowing System, Arch) triple to identify target platform like (linux.gtk.x86)

@qualidafial: Linux has both GTK and QT. Windows has both win32 and WPF. Mac has both Cocoa and Carbon. So I don't think we can count out the windowing system part.

Andrey's proposal was the triple:

<os>-<win>-<arch>
linux-gtk-x86
macosx-cocoa-x86
win32-win32-x86   // is this correct?

It seems to me that windowing system might be applicable, but can probably be ignored most of the time. So I would suggest the triple:

<os>-<arch>[-<win>]  // windowing system or other qualifier is optional
linux-x86
win-x86
win-x86_64

Deriving OS and Architecture from os.name and os.arch system properties makes sense.

I am not sure how I would derive the windowing system name reflectively.

Is anybody running 64-bit Windows?

I don't see a constant in Eclipse for win64. Does it report as win32-x86_64?

The way I am prototyping this is by adding the following methods to Sys:

static Str os()
static Str arch()
static Str platform()

The platform method basically returns "$os-$arch", such as "macosx-x86_64".

I took Andrey's proposal which tweaks the os.name and os.arch to arrive at the standard string constants.

However I don't think win32 is correct - I think it should just be "win" since the arch will be x86 or x86_64. But if everyone feels strongly about sticking with Eclipse convention we can use win32.

I am also stripping out funny characters like / in constants such as "os/400" since they don't map to file system structure well.

The new extension mechanism will use the platform value to implicitly add JARs to the FanClassLoader. They will not be added to the system classloader anymore at bootstrap. For example now the Window's swt.jar will live in {home}/lib/java/ext/win-x86.

Hi Brian,

Is anybody running 64-bit Windows? I don't see a constant in Eclipse for win64. Does it report as win32-x86_64?

You are right, 64-bit Windows is identified as "win32" and "x86_64"

Regards, Alex

edit: deleted

You are right, 64-bit Windows is identified as "win32" and "x86_64"

That seems kind of confusing to me.

So my suggestion is that Windows is represented as "win", not "win32". Then the full platform would be "win-x86" or "win-x86_64".

I'll assume everybody is ok with that naming convention, unless I hear some disagreements.

Wikipedia, quotes here http://en.wikipedia.org/wiki/Windows_API :

Win32 for 64-bit Windows, previously known as Win64, is the variant of the API implemented on 64-bit platforms of the Windows architecture (currently AMD64 and IA64.)

There are no new user-mode functions specific to the 64-bit platform, so both 32-bit and 64-bit versions of an application can be still compiled from a single codebase, although some older APIs have been deprecated. All memory pointers are 64-bit by default (the LLP64 model), so the source code has to be checked for compatibility with 64-bit pointer arithmetic and rewritten as necessary.

It looks like Microsoft is fixing names for APIs themselves, but not for architectures, so I guess Win32 is correct to refer current Windows API's for any architecture. That's like we do not differentiate APIs on 32 and 64 bit JVMs :)

ok - let's just stick 100% with Eclipse naming convention and I will use "win32"