You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Doug MacEachern <do...@telebusiness.co.nz> on 1998/03/15 06:57:43 UTC
win32 and
This came up ages ago, but we never did anything about it. As you know
mod_perl lets you write configuration files in Perl, but it uses some
configuration routines that are not "public". For sometime, the <Perl>
config section code has been #ifdef'd out under win32. Getting back to
it today, resulted in the attached patch. vc++ still can't resolve
top_module and core_module, any clues to why? If folks feel it's no
good for Apache to API_EXPORT these functions, is there a way for
mod_perl to import them somehow?
-Doug
Re: win32 and
Posted by Ben Laurie <be...@algroup.co.uk>.
Doug MacEachern wrote:
>
> Ben Laurie wrote:
>
> > Doug MacEachern wrote:
> > >
> > > This came up ages ago, but we never did anything about it. As you know
> > > mod_perl lets you write configuration files in Perl, but it uses some
> > > configuration routines that are not "public". For sometime, the <Perl>
> > > config section code has been #ifdef'd out under win32. Getting back to
> > > it today, resulted in the attached patch. vc++ stFrom new-httpd-owner-new-httpd-archive=hyperreal.org@apache.org Mon Mar 16 03:35:21 1998
Return-Path: <ne...@apache.org>
Delivered-To: new-httpd-archive@hyperreal.org
Received: (qmail 13775 invoked by uid 6000); 16 Mar 1998 03:35:20 -0000
Received: (qmail 13756 invoked from network); 16 Mar 1998 03:35:17 -0000
Received: from valis.worldgate.com (marcs@198.161.84.2)
by taz.hyperreal.org with SMTP; 16 Mar 1998 03:35:17 -0000
Received: from localhost (marcs@localhost)
by valis.worldgate.com (8.8.7/8.8.7) with SMTP id UAA00303
for <ne...@apache.org>; Sun, 15 Mar 1998 20:35:15 -0700 (MST)
Date: Sun, 15 Mar 1998 20:35:14 -0700 (MST)
From: Marc Slemko <ma...@worldgate.com>
To: Apache - BYOC <ne...@apache.org>
Subject: windows installer
Message-ID: <Pi...@valis.worldgate.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org
It has been suggested to me that looking at a product called Wise
(http://www.glbs.com/) may be worthwhile. I know nothing about it, and we
would have to convince them to give a free license, but I figure perhaps
their programmers have advanced beyond the "busy-wait 'cause its cool"
stage that installshield is at.
I support whatever works, and if IS2 is that then I sure won't complain.
But I'm leery of all IS products based on what I have seen of IS5...
Anyone have any background in actually using this? I realize that we have
the stuff required for an IS2 installer that works ok, but I am concerned
about the future.
Re: win32 and
Posted by Doug MacEachern <do...@telebusiness.co.nz>.
Ben Laurie wrote:
> Doug MacEachern wrote:
> >
> > This came up ages ago, but we never did anything about it. As you know
> > mod_perl lets you write configuration files in Perl, but it uses some
> > configuration routines that are not "public". For sometime, the <Perl>
> > config section code has been #ifdef'd out under win32. Getting back to
> > it today, resulted in the attached patch. vc++ still can't resolve
> > top_module and core_module, any clues to why?
>
> Yes - coz you must use API_VAR_EXPORT, not MODULE_VAR_EXPORT. The latter
> is for modules that want to export variables. The former is for core
> exports.
cool, that worked! I also had to #define IS_MODULE in perl_config.c before
pulling in the apache .h files, so that defined turns into a dllimport.
-Doug
Re: win32 and
Posted by Ben Laurie <be...@algroup.co.uk>.
Doug MacEachern wrote:
>
> This came up ages ago, but we never did anything about it. As you know
> mod_perl lets you write configuration files in Perl, but it uses some
> configuration routines that are not "public". For sometime, the <Perl>
> config section code has been #ifdef'd out under win32. Getting back to
> it today, resulted in the attached patch. vc++ still can't resolve
> top_module and core_module, any clues to why?
Yes - coz you must use API_VAR_EXPORT, not MODULE_VAR_EXPORT. The latter
is for modules that want to export variables. The former is for core
exports.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: win32 and
Posted by Ben Laurie <be...@algroup.co.uk>.
Doug MacEachern wrote:
>
> I have a feeling I'm not going to get any +1's on this patch. I know it
> wouldn't be a warm, fuzzy +1 for anyone (including myself), but it doesn't
> break anything, just makes a few functions visible to the module dlls. <Perl>
> configuration under win32 would make lots of folks happy, and it's a big
> feature that none of the other win32 HTTP servers have to offer :-) Any
> strong objections to me committing this patch?
So long as you comment CORE_EXPORT to mean "exported functions that may
go away, change meanings, or other bad things" then +1.
Of course, we ought to aim to find APIish ways to do them...
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: win32 and
Posted by Doug MacEachern <do...@telebusiness.co.nz>.
Dean Gaudet wrote:
> Go ahead, and then someone can put static on every other function that
> you're not using to stop you from using any more you're not supposed to be
> :)
d'oh, guess I should have exported them all ;-)
-Doug
Re: win32 and
Posted by Dean Gaudet <dg...@arctic.org>.
Go ahead, and then someone can put static on every other function that
you're not using to stop you from using any more you're not supposed to be
:)
Dean
On Tue, 17 Mar 1998, Doug MacEachern wrote:
> I have a feeling I'm not going to get any +1's on this patch. I know it
> wouldn't be a warm, fuzzy +1 for anyone (including myself), but it doesn't
> break anything, just makes a few functions visible to the module dlls. <Perl>
> configuration under win32 would make lots of folks happy, and it's a big
> feature that none of the other win32 HTTP servers have to offer :-) Any
> strong objections to me committing this patch?
>
> -Doug
>
> Doug MacEachern wrote:
>
> > Dean Gaudet wrote:
> >
> > > srm_command_loop I'm definately FOR adding to the api, that's an
> > > oversight...
> > >
> > > But I'm confused, I thought that once we put in the pcfg stuff you
> > > wouldn't need things like limit_section() and init_virtual_host() and
> > > whatnot. Can't you just pcfg_open_custom/srm_command_loop for those?
> >
> > We have started using pcfg_open_custom for feeding strings to the config
> > gears, which works quite nice. But, the direct Perl variable -> config
> > mapping doesn't use pcfg_open_custom yet, and would require a considerable
> > amount of work to do so, including maintaining backwards compatibility w/
> > 1.2.x. In other words, the <Perl> stuff is currently stable, heaps of
> > people rely on it. Only a few API_EXPORTs and magic, the feature is
> > available to win32 users and presumably just as stable as it is under unix.
> > <Perl> sections under win32 could hook into the windows registry and other
> > funky stuff. Since some of these functions are clearly not part of the
> > "API", how about a
> >
> > #define CORE_EXPORT API_EXPORT
> >
> > or something like that, which does the same as API_EXPORT, but doesn't
> > advertise itself as "public" to readers of the source code?
> >
> > -Doug
>
>
>
>
Re: win32 and
Posted by Doug MacEachern <do...@telebusiness.co.nz>.
I have a feeling I'm not going to get any +1's on this patch. I know it
wouldn't be a warm, fuzzy +1 for anyone (including myself), but it doesn't
break anything, just makes a few functions visible to the module dlls. <Perl>
configuration under win32 would make lots of folks happy, and it's a big
feature that none of the other win32 HTTP servers have to offer :-) Any
strong objections to me committing this patch?
-Doug
Doug MacEachern wrote:
> Dean Gaudet wrote:
>
> > srm_command_loop I'm definately FOR adding to the api, that's an
> > oversight...
> >
> > But I'm confused, I thought that once we put in the pcfg stuff you
> > wouldn't need things like limit_section() and init_virtual_host() and
> > whatnot. Can't you just pcfg_open_custom/srm_command_loop for those?
>
> We have started using pcfg_open_custom for feeding strings to the config
> gears, which works quite nice. But, the direct Perl variable -> config
> mapping doesn't use pcfg_open_custom yet, and would require a considerable
> amount of work to do so, including maintaining backwards compatibility w/
> 1.2.x. In other words, the <Perl> stuff is currently stable, heaps of
> people rely on it. Only a few API_EXPORTs and magic, the feature is
> available to win32 users and presumably just as stable as it is under unix.
> <Perl> sections under win32 could hook into the windows registry and other
> funky stuff. Since some of these functions are clearly not part of the
> "API", how about a
>
> #define CORE_EXPORT API_EXPORT
>
> or something like that, which does the same as API_EXPORT, but doesn't
> advertise itself as "public" to readers of the source code?
>
> -Doug
Re: win32 and
Posted by Doug MacEachern <do...@telebusiness.co.nz>.
Dean Gaudet wrote:
> srm_command_loop I'm definately FOR adding to the api, that's an
> oversight...
>
> But I'm confused, I thought that once we put in the pcfg stuff you
> wouldn't need things like limit_section() and init_virtual_host() and
> whatnot. Can't you just pcfg_open_custom/srm_command_loop for those?
We have started using pcfg_open_custom for feeding strings to the config
gears, which works quite nice. But, the direct Perl variable -> config
mapping doesn't use pcfg_open_custom yet, and would require a considerable
amount of work to do so, including maintaining backwards compatibility w/
1.2.x. In other words, the <Perl> stuff is currently stable, heaps of
people rely on it. Only a few API_EXPORTs and magic, the feature is
available to win32 users and presumably just as stable as it is under unix.
<Perl> sections under win32 could hook into the windows registry and other
funky stuff. Since some of these functions are clearly not part of the
"API", how about a
#define CORE_EXPORT API_EXPORT
or something like that, which does the same as API_EXPORT, but doesn't
advertise itself as "public" to readers of the source code?
-Doug
Re: win32 and
Posted by Dean Gaudet <dg...@arctic.org>.
srm_command_loop I'm definately FOR adding to the api, that's an
oversight...
But I'm confused, I thought that once we put in the pcfg stuff you
wouldn't need things like limit_section() and init_virtual_host() and
whatnot. Can't you just pcfg_open_custom/srm_command_loop for those?
Dean
On Sun, 15 Mar 1998, Doug MacEachern wrote:
> This came up ages ago, but we never did anything about it. As you know
> mod_perl lets you write configuration files in Perl, but it uses some
> configuration routines that are not "public". For sometime, the <Perl>
> config section code has been #ifdef'd out under win32. Getting back to
> it today, resulted in the attached patch. vc++ still can't resolve
> top_module and core_module, any clues to why? If folks feel it's no
> good for Apache to API_EXPORT these functions, is there a way for
> mod_perl to import them somehow?
>
> -Doug
>
>
>