pragma packing on sparc solaris

[Juraj Hercek]

Hi,

I'm trying to get wine working on solaris running on sparc. I have 
troubles with structure packing, since sparc solaris throws SIGSEGV when 
writting to structure members not aligned to 4-byte boundary (for 
example: loader/ne/resource.c:280, where &pTypeInfo->resloader is not 
aligned to 4-byte boundary).

Since I'm new to wine, I'd like to know about packing policies (pragma 
pack 1,2,...) in wine:
1) When do we use packing and why (optimisation?)?
2) What would happen if pragma packing is ommited or always set to 4?

Next, I'd like to know if there will be also non i386 COM proxy 
implementation (dlls/rpcrt4/cproxy.c and related), since I'm unable to 
compile newest wine on sparc solaris (currently, I'm using version from 
October 1st).

Thanks for reply.

Juraj

[Alexandre Julliard]

Juraj Hercek  writes:
> I'm trying to get wine working on solaris running on sparc. I have
> troubles with structure packing, since sparc solaris throws SIGSEGV
> when writting to structure members not aligned to 4-byte boundary (for
> example: loader/ne/resource.c:280, where &pTypeInfo->resloader is not
> aligned to 4-byte boundary).

The memcpy in there is supposed to fix that, sounds like the compiler
didn't get it right. Maybe a (char *) cast would help?
> Next, I'd like to know if there will be also non i386 COM proxy
> implementation (dlls/rpcrt4/cproxy.c and related), since I'm unable to
> compile newest wine on sparc solaris (currently, I'm using version
> from October 1st).

Should be fixed now (well at least it should compile).

[Greg Turner]

On Thursday 17 October 2002 11:48 am, Alexandre Julliard wrote:
> Juraj Hercek  writes:
> > Next, I'd like to know if there will be also non i386 COM proxy
> > implementation (dlls/rpcrt4/cproxy.c and related), since I'm unable to
> > compile newest wine on sparc solaris (currently, I'm using version
> > from October 1st).
>
> Should be fixed now (well at least it should compile).

Thanks, Alexandre, I thought that was wrong.  As for Juraj's question,
in general, once it works at all (!), I think the new rpcrt4 stuff should work
cross-platform, assuming we marshall properly.  I wish I had the hardware
to experiment with this.  Architecture gurus could fill in per-architecture
replacements for the existing stubless-proxy thunk code, to make it complete,
but I am no such guru.

[Geoff Thorpe]

Hi there,

On Thursday 17 Oct 2002 4:37 am, Juraj Hercek wrote:
> Hi,
> > I'm trying to get wine working on solaris running on sparc. I have
>
> troubles with structure packing, since sparc solaris throws SIGSEGV
> when writting to structure members not aligned to 4-byte boundary
> (for example: loader/ne/resource.c:280, where &pTypeInfo->resloader
> is not aligned to 4-byte boundary).

SIGSEGV? Heh, that makes a pleasant change - I've sent plenty of 
alignment problems when taking ix86-acceptable code to sparc, mips, 
etc, but they usually throw a SIGBUS instead. Anyway ...
> Since I'm new to wine, I'd like to know about packing policies
> (pragma pack 1,2,...) in wine:
> - When do we use packing and why (optimisation?)?

AFAICS, to make structures binary compatible between MSVC/Win32-native 
code and gcc/wine code - MSVC (on x86 anyway) packs structures without  
caring too much about word-alignment.
> - What would happen if pragma packing is ommited or always set to 4?

Well, if you're on sparc then you're probably not caring much about 
binary compatibility between wine code and native windows? In fact, is 
there (or was there ever) such a thing as "native windows" on sparc? 
Assuming there is, and *you* care about binary compatibility with it - 
can you see what MSVC does to structures on sparc? I'm assuming that 
even windoze/MSVC would respect alignments on (supported) platforms if 
failing to do so would SIGBUS all the time. Then again, this is 
Microsoft we're talking about ... as long as you can catch the 
exception and throw up a blue-screen it's OK ...

Cheers,
Geoff

[Francois Gouget]

On Thu, 17 Oct 2002, Geoff Thorpe wrote:
[...]
> In fact, is there (or was there ever) such a thing as "native windows"
> on sparc?

[...]

AFAIK the only non x86 versions of Windows were the Windows NT 3.1 to
3.51 (and maybe not all of them) and they were available on MIPS, Alpha
(32bit mode only) and (I believe) PowerPC. In any case they are all dead
now (have been for a long time, I would say at least 3 years).

[Steven Edwards]

> AFAIK the only non x86 versions of Windows were the Windows NT 3.1 to
> 3.51 (and maybe not all of them) and they were available on MIPS, Alpha
> (32bit mode only) and (I believe) PowerPC. In any case they are all dead
> now (have been for a long time, I would say at least 3 years).

NT 4.0 Also support these platforms to SP3/4 + IE4. after this 
everything but Alpha and X86 was support untill Sp6 and then M$ drop'd 
support for Alpha with Win2k RC1 I think. A interesting note about Win2k 
on alpha was that it was fully 64-bit.

Thanks
Steven