Porting from Win32 services to Linux daemons

Porting from Win32 services to Linux daemons

Post by tj bandrows » Wed, 22 Jan 2003 13:38:40



I have a rather largish server app that I've been working on for Win32
and I want to port it to Linux.  I've done some Solaris / Win32
portable development before (text only), but I turned to the dark side
for a bit and now I'm coming to see the light again.

A couple of quick questions:

a) What's a good (or better - as in faster) analogue for HeapAlloc,
HeapFree under Linux?

b) Is it fairly straightfoward to use mmap like one would use
MapViewOfFile, etc?  What are some big gotchas. Can I mmap a small
section of a file >2GB?

c) Is the C++ compiler of choice still G++/GCC?  Does it support
member function templates?

d) Do 64 bit linuxes give me 64 bit longs, and, is there an analogue
to __int64 under Linux?

e) Does GCC offer support for inline x86 assembly? (obviously this
must go to satisfy question d, except on ppc because I haven't played
with more than 3 registers since college and I'm looking to get onto a
real cpu).

 
 
 

Porting from Win32 services to Linux daemons

Post by Jem Berke » Wed, 22 Jan 2003 14:50:38


Quote:> A couple of quick questions:

I'll answer the ones I think I know the answer to :)

Quote:> a) What's a good (or better - as in faster) analogue for HeapAlloc,
> HeapFree under Linux?

I'm thinking malloc, calloc, free from the C library. Won't everything
else just use these, after all?

Quote:> d) Do 64 bit linuxes give me 64 bit longs, and, is there an analogue
> to __int64 under Linux?

I've never compiled for 64 bit processors, but I'm pretty sure that "long
long" will give you a 64 bit int. I just tried this now, and sizeof()
returns 8 byte length (=64 bits) for something declared long long.

Quote:> e) Does GCC offer support for inline x86 assembly? (obviously this
> must go to satisfy question d, except on ppc because I haven't played
> with more than 3 registers since college and I'm looking to get onto a
> real cpu).

Yes. You can use a statement like: asm ("xor %eax, %eax");
Although most people seem to prefer writing their assembly with nasm.

--
Jem Berkes
http://www.pc-tools.net/
Windows, Linux & UNIX software

 
 
 

Porting from Win32 services to Linux daemons

Post by Kasper Dupon » Wed, 22 Jan 2003 14:53:57



> I have a rather largish server app that I've been working on for Win32
> and I want to port it to Linux.  I've done some Solaris / Win32
> portable development before (text only), but I turned to the dark side
> for a bit and now I'm coming to see the light again.

> A couple of quick questions:

> a) What's a good (or better - as in faster) analogue for HeapAlloc,
> HeapFree under Linux?

What do they do? Why not just use malloc and free?

Quote:

> b) Is it fairly straightfoward to use mmap like one would use
> MapViewOfFile, etc?  What are some big gotchas. Can I mmap a small
> section of a file >2GB?

If the glibc mmap function uses sys_mmap2 it should be able to
mmap from a file up to 16TB in size.

If you find limits in glibc, you can always bypass it and make
system calls directly, but only do so if you absolutely have to,
because your program will be less portable.

Quote:

> c) Is the C++ compiler of choice still G++/GCC?

Yes.

Quote:> Does it support member function templates?

I don't know.

Quote:

> d) Do 64 bit linuxes give me 64 bit longs, and, is there an analogue
> to __int64 under Linux?

int64_t or uint64_t I'd guess. IIRC you need to include <stdint.h>
for those. There is also long long which is 64 bit but that might
change on future platforms.

Quote:

> e) Does GCC offer support for inline x86 assembly?

Yes.

Quote:> (obviously this
> must go to satisfy question d, except on ppc because I haven't played
> with more than 3 registers since college and I'm looking to get onto a
> real cpu).

--
Kasper Dupont -- der bruger for meget tid p? usenet.

for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);
 
 
 

Porting from Win32 services to Linux daemons

Post by Erik de Castro Lop » Wed, 22 Jan 2003 15:05:17


 > > d) Do 64 bit linuxes give me 64 bit longs, and, is there an analogue

Quote:> > to __int64 under Linux?

> I've never compiled for 64 bit processors, but I'm pretty sure that "long
> long" will give you a 64 bit int. I just tried this now, and sizeof()
> returns 8 byte length (=64 bits) for something declared long long.

Most systems with glibc >= 2.1 and have a 64 bit long long type even
on 32 bit processors.

Erik
--
+-----------------------------------------------------------+

+-----------------------------------------------------------+
When a user mailbombs me with 100,000 messages, we
call it denial of service and the guy can be thrown
in jail.  When 100,000 SPAMMERS send me one mail each,
we call it marketing.

 
 
 

Porting from Win32 services to Linux daemons

Post by André P?nit » Wed, 22 Jan 2003 17:18:10



> c) Is the C++ compiler of choice still G++/GCC?

Yes.

Quote:> Does it support member function templates?

Sure.

Quote:> d) Do 64 bit linuxes give me 64 bit longs, and, is there an analogue
> to __int64 under Linux?

long long is 64 bit on IA32.

Quote:> e) Does GCC offer support for inline x86 assembly?

Yes.

Andre'

--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

 
 
 

Porting from Win32 services to Linux daemons

Post by Arnold Hendrik » Wed, 22 Jan 2003 17:33:03



>> a) What's a good (or better - as in faster) analogue for HeapAlloc,
>> HeapFree under Linux?
> What do they do? Why not just use malloc and free?

They have some extra flags, such as HEAP_ZERO_MEMORY (which calloc can do
as well), HEAP_GENERATE_EXCEPTIONS (Linux doesn't have structured
exceptions, but there are plenty of other ways to do exception-like stuff
yourself in C and C++) and HEAP_NO_SERIALIZE (request non-MT safe allocation)

Quote:>> b) Is it fairly straightfoward to use mmap like one would use
>> MapViewOfFile, etc?  What are some big gotchas. Can I mmap a small
>> section of a file >2GB?

You're more likely to find gotchas the other way around - for example,
on Win32 you can't resize a mmapped file (or at least, you can't mmap the
appended data without releasing all other mappings first)

[gcc]

Quote:>> Does it support member function templates?
> I don't know.

At least g++ 3 and higher do. g++ 2.95 probably does as well, but isn't
very standards-compliant, which can be a problem when writing portable
software.

--

B-Lex Information Technologies, http://www.b-lex.com/

 
 
 

Porting from Win32 services to Linux daemons

Post by Kevin Easto » Wed, 22 Jan 2003 19:37:31




[snip]
>> d) Do 64 bit linuxes give me 64 bit longs, and, is there an analogue
>> to __int64 under Linux?

> long long is 64 bit on IA32.

Not responding specifically to your comment more than any other, but I
thought I'd add that the C99 "long long" type as included by GCC has to
have at least 64 value bits.  In 99.9% of cases, this is what you want
(a *minimum* range, rather than a specific number of bits).

        - Kevin.

 
 
 

Porting from Win32 services to Linux daemons

Post by André P?nit » Wed, 22 Jan 2003 20:41:30



>> long long is 64 bit on IA32.

> Not responding specifically to your comment more than any other, but I
> thought I'd add that the C99 "long long" type as included by GCC has to
> have at least 64 value bits.

Sure, the Standard requirements are minimal requirements.
However, current gcc implements these as exact 64 bits on IA32.

Quote:>In 99.9% of cases, this is what you want
> (a *minimum* range, rather than a specific number of bits).

Indeed.

Andre'

--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

 
 
 

Porting from Win32 services to Linux daemons

Post by Grant Edwar » Thu, 23 Jan 2003 01:22:54



>> d) Do 64 bit linuxes give me 64 bit longs, and, is there an analogue
>> to __int64 under Linux?

> I've never compiled for 64 bit processors, but I'm pretty sure that "long
> long" will give you a 64 bit int. I just tried this now, and sizeof()
> returns 8 byte length (=64 bits) for something declared long long.

If you want to be sure of how many bits you get, you can use
the new data types from the C99 standard.

Quote:>> e) Does GCC offer support for inline x86 assembly? (obviously this
>> must go to satisfy question d, except on ppc because I haven't played
>> with more than 3 registers since college and I'm looking to get onto a
>> real cpu).

> Yes. You can use a statement like: asm ("xor %eax, %eax");
> Although most people seem to prefer writing their assembly with nasm.

Inline assmebly with gcc can be quite sophisticated (you can
embed C expressions in your assembly language).  For anything
longer than a few lines, I prefer just writing them seperately
and assembling them with as.

--
Grant Edwards                   grante             Yow!  Yow! I'm imagining
                                  at               a surfer van filled with
                               visi.com            soy sauce!

 
 
 

Porting from Win32 services to Linux daemons

Post by tj bandrows » Thu, 23 Jan 2003 02:58:54


Quote:> What do they do? Why not just use malloc and free?

I'm using lots of skip lists, sets of which share private heaps.  Some
of them are thread local.  This is a multithreaded server and so I
went out of my way to avoid contention whereever possible.

Quote:> If the glibc mmap function uses sys_mmap2 it should be able to
> mmap from a file up to 16TB in size.

NICE

Quote:

> If you find limits in glibc, you can always bypass it and make
> system calls directly, but only do so if you absolutely have to,
> because your program will be less portable.

Cool.

Quote:

> int64_t or uint64_t I'd guess. IIRC you need to include <stdint.h>
> for those. There is also long long which is 64 bit but that might
> change on future platforms.

Thank you so much!  Yeah, I have to use explicit 64 bit stuff because
the memmapped file uses 64 bit offsets within it.  It's designed to
hold A LOT of data.  Problem for me is that to test this sort of
monster in all its glories requires either me fork over mega shillings
for Windows server, or, just download Linux.  I know this is going to
be a problem when I have a version for PPC (someday I'll have that PPC
970 workstation), but I figure I'll store the data natively for
whatever its native type and be nice and use stuff for interchange.

Oh, how is GCC for wchar_t and unicode?

Quote:> > e) Does GCC offer support for inline x86 assembly?

> Yes.

Cool.
 
 
 

Porting from Win32 services to Linux daemons

Post by tj bandrows » Thu, 23 Jan 2003 03:01:54


Quote:> You're more likely to find gotchas the other way around - for example,
> on Win32 you can't resize a mmapped file (or at least, you can't mmap the
> appended data without releasing all other mappings first)

WOW.  You mean Linux does that!  That ROCKS.  I had that exact
problem, plus there's a bevy of bizarrely documented requirements for
Windows XP MapViewOfFile, etc. I think to resize the file I had to
unmap everything and do bunches of * stuff.  It's quite ugly.
 
 
 

Porting from Win32 services to Linux daemons

Post by Mikko Rauha » Thu, 23 Jan 2003 07:33:47




> Oh, how is GCC for wchar_t and unicode?

Good. Coming from Windows, you might want to be aware that gcc's
wchar_t is 32-bit (UTF-32) whereas Windows uses a 16-bit wchar_t.

--

Transhumanist   - WTA member     - <URL:http://www.transhumanism.org/>
Singularitarian - SIAI supporter - <URL:http://www.singinst.org/>

 
 
 

Porting from Win32 services to Linux daemons

Post by Roger Leig » Thu, 23 Jan 2003 08:05:30



> > int64_t or uint64_t I'd guess. IIRC you need to include <stdint.h>
> > for those. There is also long long which is 64 bit but that might
> > change on future platforms.

> Thank you so much!  Yeah, I have to use explicit 64 bit stuff because
> the memmapped file uses 64 bit offsets within it.  It's designed to
> hold A LOT of data.  Problem for me is that to test this sort of
> monster in all its glories requires either me fork over mega shillings
> for Windows server, or, just download Linux.  I know this is going to
> be a problem when I have a version for PPC (someday I'll have that PPC
> 970 workstation), but I figure I'll store the data natively for
> whatever its native type and be nice and use stuff for interchange.

For 64 bit offsets in *files*, you want off_t (off64_t) with
-D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64

Quote:> Oh, how is GCC for wchar_t and unicode?

wchar_t is fully supported.  It's 32 bits (UCS-4) unlike on Windows
(16 bit UCS-2).  That shouldn't present any issues.

--
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers

 
 
 

Porting from Win32 services to Linux daemons

Post by Roger Leig » Thu, 23 Jan 2003 08:05:31





> > Oh, how is GCC for wchar_t and unicode?

> Good. Coming from Windows, you might want to be aware that gcc's
> wchar_t is 32-bit (UTF-32) whereas Windows uses a 16-bit wchar_t.

UTF == UCS transformation format

UCS == Universal Character Set

UTF-* are *encodings* of the UCS, i.e. you use wchar_t to store the
character numbers themselves, as opposed to an encoding of them
(though wchar_t isn't limited to UCS--you could store any charset in
it).

--
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers

 
 
 

Porting from Win32 services to Linux daemons

Post by tj bandrows » Thu, 23 Jan 2003 13:41:42






> > > Oh, how is GCC for wchar_t and unicode?

> > Good. Coming from Windows, you might want to be aware that gcc's
> > wchar_t is 32-bit (UTF-32) whereas Windows uses a 16-bit wchar_t.

Oooh, that's big. Any way I could make that wchar_t 16?  Or, why would
32 be good?  Have I missed something big in Unicode world... yikes?
 
 
 

1. TCP wrapper to log port/service number instead of name of daemon?

I need to have tcpd log the port or service number instead of the name
of the daemon it is spawning.

I have a common wrapper (sslwrap) around each daemon much like tcpd.
tcpd logs "sslwrap" which is wrapped around many different services.
Thus, the logs only show the "sslwrap" without differentiating imaps
from ipop3s.  This is not useful output although the access/deny
functions work correctly.

I need tcpd to name the real daemon (via a command line argument?) or it
should use the service or port number it is monitoring.  I'm surprised
no one else has had this problem before.

E-mail to the author of TCP wrapper just gets an automated response, but
no real reply.  I'm sure I could modify the source code; however, it
seems like a useful feature to have in the release code for everyone.

sslwrap is an SSL transparent proxy for TCP servers.  Wrap it around
pop3 and you get pop3s, essentially SSL'd pop3.  I then run tcpd around
sslwrap.

rp98

PS: Pardon the antispam From field.

2. SQUID proxy

3. SNMP daemon not active on port 161 (or anywhere); daemon loaded.

4. 3com NIC Card

5. port win32 COM Server to linux CORBA server

6. localnet with SyncPPP migrating to cable

7. Linux newbie trying to port Win32 code

8. How screaming "Death to America!" helps Linux

9. Porting Tool: GNU-WIN32 Version 18.1 B from Linux to Windows 95/NT

10. Porting from Win32 to Linux

11. porting WIN32 to UNIX (Linux)

12. Porting from Win32 to Linux

13. Porting Win32 app to Linux