On Fri, 29 Aug 2003, Dustin Navea wrote:
: Shouldnt something like this added to the loader work for a runtime check?
: (note im not using proper function names or anything, just an example)
:
: if (running_on_netbsd version = first_version_that_supports_MAP_TRYFIXED)
: #define
as i said it was an example, but thanks for the flame
--- Todd Vierling [EMAIL PROTECTED] wrote:
On Fri, 29 Aug 2003, Dustin Navea wrote:
: if (running_on_netbsd version =
first_version_that_supports_MAP_TRYFIXED)
: #define can_use_MAP_TRYFIXED
This damned well does not belong in
On Fri, 29 Aug 2003, Dustin Navea wrote:
: as i said it was an example, but thanks for the flame
Well, at this point, you're welcome, considering the copy you forwarded
back to the list was a private response. Have you read the proverbial
netiquette handbook yet? However, I am sorry for going
On August 29, 2003 09:08 pm, Todd Vierling wrote:
If you want to provide multiple levels of compatibility, provide multiple
builds and indicate what their build environments were. Builds for older
OS releases simply get less features. This doesn't even require multiple
machines; one compiler
--- Todd Vierling [EMAIL PROTECTED] wrote:
On Thu, 28 Aug 2003, Alexandre Julliard wrote:
: I have a feeling we're just on different mental wavelengths here.
: MAP_TRYFIXED is not an optional feature. If the #define exists, the
feature
: exists -- for the OS version used to compile, and
On Wed, 27 Aug 2003, Alexandre Julliard wrote:
: It's not really a question of shuffling back and forth, it's that
: different users have different kernels; so if you want to ship a
: binary that works for everybody, with your method you have to stick to
: the lowest common denominator. With
On Wed, Aug 27, 2003 at 07:30:32PM -0400, Todd Vierling wrote:
On Wed, 27 Aug 2003, Alexandre Julliard wrote:
: It's not really a question of shuffling back and forth, it's that
: different users have different kernels; so if you want to ship a
: binary that works for everybody, with your
Huw D M Davies wrote:
It's available on the machine that the binary is compiled on sure, but
what about the machine of a friend/customer who you've shipped the
binary to? Just because you have the new kernel feature on your build
machine doesn't mean that everybody else does. If you test at
On Thu, 28 Aug 2003, Huw D M Davies wrote:
: It's available on the machine that the binary is compiled on sure, but
: what about the machine of a friend/customer who you've shipped the
: binary to? Just because you have the new kernel feature on your build
: machine doesn't mean that everybody
Todd Vierling [EMAIL PROTECTED] writes:
I have a feeling we're just on different mental wavelengths here.
MAP_TRYFIXED is not an optional feature. If the #define exists, the feature
exists -- for the OS version used to compile, and all later versions.
You are still thinking only about source
Alexandre Julliard wrote:
With a run-time check you don't have to sacrifice anything, the binary
is still portable everywhere, but can also use MAP_TRYFIXED for better
performance if it exists in the running kernel.
Except that if you build it on a machine which knows about MAP_TRYFIXED
at all,
On Thu, 28 Aug 2003, Jon Bright wrote:
Except that if you build it on a machine which knows about MAP_TRYFIXED
at all, the resulting binary's not likely to run on older machines...
No, if the check is done at runtime, there's no problem. Where do you see any?
--
Dimi.
Dimitrie O. Paun wrote:
On Thu, 28 Aug 2003, Jon Bright wrote:
Except that if you build it on a machine which knows about MAP_TRYFIXED
at all, the resulting binary's not likely to run on older machines...
No, if the check is done at runtime, there's no problem. Where do you see any?
Having
Jon Bright [EMAIL PROTECTED] writes:
Except that if you build it on a machine which knows about
MAP_TRYFIXED at all, the resulting binary's not likely to run on older
machines...
You don't need the machine to know about it, that's the whole
point. Of course that means you need to define the
Todd Vierling [EMAIL PROTECTED] writes:
You have to bend over backwards to do the runtime check, and you sacrifice
*maintainability* with the extra normally-dead code added to Wine. I don't
see a need to jump through extra hoops in this case.
I think that run-time checks are more
On Thu, 28 Aug 2003, Alexandre Julliard wrote:
: I have a feeling we're just on different mental wavelengths here.
: MAP_TRYFIXED is not an optional feature. If the #define exists, the feature
: exists -- for the OS version used to compile, and all later versions.
:
: You are still thinking
On Thu, Aug 28, 2003 at 07:07:25PM +0200, Jon Bright wrote:
Alexandre Julliard wrote:
With a run-time check you don't have to sacrifice anything, the binary
is still portable everywhere, but can also use MAP_TRYFIXED for better
performance if it exists in the running kernel.
Except
Todd Vierling [EMAIL PROTECTED] writes:
I definitely don't want to reproduce apt-to-change parts of the OS in an
application just because it *might* be built on an earlier version of that
OS. If an app is built on the earlier OS version, the user should expect to
be missing features. Unix
On Thu, 28 Aug 2003, Alexandre Julliard wrote:
: Anyway it doesn't really matter for that specific issue, if you don't
: feel the performance gain is worth the trouble that's your call.
It's not. NetBSD's userbase [capable of running Wine] is moving rapidly
enough, and enough are compiling Wine
Todd Vierling [EMAIL PROTECTED] writes:
In general, this holds true with other applications on NetBSD. If a feature
appears in the C headers, it is assumed to exist. The patch is in line with
NetBSD's compatibility principles.
Of course this implies that everybody builds all their apps from
Todd Vierling [EMAIL PROTECTED] writes:
No, it implies that a built binary requires a kernel at least as new as the
.h files used when building. This is NetBSD (and SysV and ...) standard
practice, and is the foundation of how autoconf tests work.
The common practice of Linux users
21 matches
Mail list logo
