[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Disk usage optimizations
From:       Manuel Amador <rudd-o () amautacorp ! com>
Date:       2005-02-25 21:58:31
Message-ID: 1109369011.16418.38.camel () master ! amauta
[Download RAW message or body]

El vie, 25-02-2005 a las 19:09 +0000, Esben Mose Hansen escribió:
> On Friday 2005-02-25 15:17, Manuel Amador wrote:
> > > B) Suddenly I'm more afraid of this port to windows because of things
> > > like we can't assume forks/open/stat are fast
> >
> > Not only we cannot assume that, we can count on the fact that forks,
> > opens and stats are EXTREMELY slow.  Do you ever wonder why Windows
> > tends to ship icon libraries instead of single icons, and include
> > commonly used resources in executables?
> 
> Personally, I'm hoping that the windows port will be a fork rather than a 
> supported platform. I have done crossplatform between Z/OS, Linux, AIX and 
> Windows and my god, windows suck. I mean, Z/OS is bad, but not even in the 
> same league. 
> 
> Being able to fork all the time is so nice, so efficient and so much /cleaner/ 
> than execv or threads. All IMHO, of course.

the word "fork" in that context has a different meaning.  We used "fork"
as the name for the libc call fork(2).  You meant fork as in "we're
forking this project to do our own stuff".

Or I misunderstood.  But fork(2) rules!

What is clear is that by porting to Windows you will be able to develop
apps without having to deal with the Win32 API.  And by porting to
Windows, a great deal of bugs may be squashed just because of the fact
that the porters will pore over large amounts of code.

So, the windows port could actually be beneficial for KDE, at least in
that sense.

> 
-- 
Manuel Amador <rudd-o@amautacorp.com>
Amauta
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]