Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] SWT on 64-bit platforms

>>>>> "Steve" == Steve Northover <Steve_Northover@xxxxxxx> writes:

Steve> Tom, there is no plan in place to port SWT to 64-bits.  There
Steve> are other places in the code where we are not 64-bit clean.

Do you mean other places in SWT, or other places in Eclipse in general?
If you mean just SWT, that's ok; any 64-bit audit will likely find them.
I don't know when exactly we may need this (or whether we will -- it
all seems a bit speculative).  Right now I'm just trying to estimate
the magnitude for our planning.

If you mean code other than SWT, do you know if there is a list of
problem areas?  That might help.

Steve> We have thought about possible solutions:
Steve>       - 2 streams, one using "long" and one using "int"

Yikes.

Steve>       - abandon "int" and use an object that contains either an "int" or
Steve> "long" (like TCHAR on Windows that hides UNICODE vs. DBCS)

Another similar choice would be to have a hash table on the native
side that does the int/pointer mapping.  It could be conditional on a
the platform having 64-bit pointers.  This seems like it would have
less overhead than wrapping every native pointer in a new Java object.
On the other hand it would seem to violate the general SWT approach
(or what I understand it to be anyway).

Steve>       - use "long" everywhere and be careful to do the correct
Steve> casting/pointer math on 32-bit systems

IMO this is probably the simplest to implement and understand.  Most
likely I'll base my estimate on this.

If you know for certain that one approach is unacceptable, that would
help me.

Tom


Back to the top