Re: svn commit: r1745517 - /httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c

[Gregg Smith]

On 5/25/2016 11:14 AM, William A Rowe Jr wrote:

Your comment doesn't match the code, and I think you have the condition
inverted, _setargv() worked for decades, and only was broken in the more
recent MSVC's.


Typo, should be 1800 in log, I'll change it. I may revert it now that I 
dug & found $(VCINSTALLDIR) . If that's in VC6 then it's usable all the 
way up the line and the setargv.obj can just be added to the dsp/mak files.



My thought is to unilaterally change this to the unicode implementation,
because 1. ANSI-only are dead Windows OS's, and 2. Getting the utf-8
thing right in this app is becoming a big headache.

Thoughts?


If it deals with this then why not!
Apachemonitor itself could use another way of figuring out what it's 
running on also as GetVersionExA is gone and the code in VC > 11 making 
it work won't last forever I'd suspect. I've been looking into that and 
MS gives an nice example at 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms725491%28v=vs.85%29.aspx




On Wed, May 25, 2016 at 11:29 AM,  wrote:


Author: gsmith
Date: Wed May 25 16:29:59 2016
New Revision: 1745517

URL: http://svn.apache.org/viewvc?rev=1745517=rev
Log:
backport r1745516
_setargv will not compile on _MSC_VER<  1700
MS documentation's example simply does not work.
Disabe for now, Apachemonitor still works.

Modified:
 httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c

Modified: httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c?rev=1745517=1745516=1745517=diff

==
--- httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c (original)
+++ httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c Wed May 25
16:29:59 2016
@@ -1586,8 +1586,10 @@ int WINAPI WinMain(HINSTANCE hInstance,
  #ifdef UNICODE
  __wargv = CommandLineToArgvW(GetCommandLineW(),&__argc);
  #else
+#if defined(_MSC_VER)&&  _MSC_VER<  1800
  _setargv();
  #endif
+#endif

  if ((__argc == 2)&&  (_tcscmp(__targv[1], _T("--kill")) == 0))
  {

Re: svn commit: r1745517 - /httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c

[William A Rowe Jr]

On Wed, May 25, 2016 at 1:14 PM, William A Rowe Jr 
wrote:

> Your comment doesn't match the code, and I think you have the condition
> inverted, _setargv() worked for decades, and only was broken in the more
> recent MSVC's.
>

Correction, the code looks right (sort of, I believe you might have broken
the
command line invocation to halt ApacheMonitor.exe to allow for it to be
upgraded
or replaced, and perhaps to re-invoke itself as Admin.)  The commit log
message
seems inverted.

Re: svn commit: r1745517 - /httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c

[William A Rowe Jr]

Your comment doesn't match the code, and I think you have the condition
inverted, _setargv() worked for decades, and only was broken in the more
recent MSVC's.

My thought is to unilaterally change this to the unicode implementation,
because 1. ANSI-only are dead Windows OS's, and 2. Getting the utf-8
thing right in this app is becoming a big headache.

Thoughts?



On Wed, May 25, 2016 at 11:29 AM,  wrote:

> Author: gsmith
> Date: Wed May 25 16:29:59 2016
> New Revision: 1745517
>
> URL: http://svn.apache.org/viewvc?rev=1745517=rev
> Log:
> backport r1745516
> _setargv will not compile on _MSC_VER < 1700
> MS documentation's example simply does not work.
> Disabe for now, Apachemonitor still works.
>
> Modified:
> httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c
>
> Modified: httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c?rev=1745517=1745516=1745517=diff
>
> ==
> --- httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c (original)
> +++ httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c Wed May 25
> 16:29:59 2016
> @@ -1586,8 +1586,10 @@ int WINAPI WinMain(HINSTANCE hInstance,
>  #ifdef UNICODE
>  __wargv = CommandLineToArgvW(GetCommandLineW(), &__argc);
>  #else
> +#if defined(_MSC_VER) && _MSC_VER < 1800
>  _setargv();
>  #endif
> +#endif
>
>  if ((__argc == 2) && (_tcscmp(__targv[1], _T("--kill")) == 0))
>  {
>
>
>

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[Ruediger Pluem]

On 05/25/2016 05:11 PM, William A Rowe Jr wrote:
> On Mon, May 16, 2016 at 5:07 PM, William A Rowe Jr  > wrote:
> 
> On Mon, May 16, 2016 at 1:26 PM, Gregg Smith  > wrote:
> 
> On 5/16/2016 11:03 AM, Eric Covener wrote:
> 
> One shortcoming of a 12 month countdown is that some folks will 
> not be
> able to plan/pitch/budget/execute a migration in 12 calendar 
> months
> because of bad timing.
> 
> As long as we're not committing to releases in this window, I'd
> personally be okay with pushing out to 18 months re: the later
> feedback in this thread. I don't feel too strongly about>  12 
> months
> notice, but I will still have a 2.2-derivative in support beyond 
> that
> window anyway.
> 
> 
> We should just pick a date right now (say 31/12/2017) and begin 
> announcing (website/download page/mail lists) it
> now. Include that one last release will come out before the end of 
> the year and it will be patches only after
> final release and until EOL date. That is 18 and a half months to EOL 
> with a final release within 6 and a half.
> 
> 
> To square this circle... I had expect that the 'final release' for httpd 
> 2.2 would
> be based on the need for a security fix release, and expected that this 
> may
> happen as many times over that year long period as were necessary.
> 
> 
> So let's try this... would 2.2.x maintainers and PMC folks please answer this
> poll -if- you have an intention to help throughout the wind-down of 2.2.x, 
> since
> this is all predicated on having committed-committers to participate.  This 
> isn't
> to say folks refuse to participate after the time period you offer, but for 
> how long 
> you are personally prepared to participate.  [If you aren't a 2.2.x legacy 
> branch 
> participant, testing RCs or applying backports, then no response is needed.]
> 
  *) I intend to help maintain/test 2.2.x releases over the next [_12___] mos
 *) I intend to backport/review 2.2.x security patches over the next [_12___] 
mos


Regards

Rüdiger

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[William A Rowe Jr]

 *) I intend to help maintain/test 2.2.x releases over the next 12 mos

 *) I intend to backport/review 2.2.x security patches over the next 12 mos

[POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[William A Rowe Jr]

On Mon, May 16, 2016 at 5:07 PM, William A Rowe Jr 
wrote:

> On Mon, May 16, 2016 at 1:26 PM, Gregg Smith  wrote:
>
>> On 5/16/2016 11:03 AM, Eric Covener wrote:
>>
>>> One shortcoming of a 12 month countdown is that some folks will not be
>>> able to plan/pitch/budget/execute a migration in 12 calendar months
>>> because of bad timing.
>>>
>>> As long as we're not committing to releases in this window, I'd
>>> personally be okay with pushing out to 18 months re: the later
>>> feedback in this thread. I don't feel too strongly about>  12 months
>>> notice, but I will still have a 2.2-derivative in support beyond that
>>> window anyway.
>>>
>>
>> We should just pick a date right now (say 31/12/2017) and begin
>> announcing (website/download page/mail lists) it now. Include that one last
>> release will come out before the end of the year and it will be patches
>> only after final release and until EOL date. That is 18 and a half months
>> to EOL with a final release within 6 and a half.
>>
>
> To square this circle... I had expect that the 'final release' for httpd
> 2.2 would
> be based on the need for a security fix release, and expected that this may
> happen as many times over that year long period as were necessary.
>

So let's try this... would 2.2.x maintainers and PMC folks please answer
this
poll -if- you have an intention to help throughout the wind-down of 2.2.x,
since
this is all predicated on having committed-committers to participate.  This
isn't
to say folks refuse to participate after the time period you offer, but for
how long
you are personally prepared to participate.  [If you aren't a 2.2.x legacy
branch
participant, testing RCs or applying backports, then no response is needed.]

 *) I intend to help maintain/test 2.2.x releases over the next [] mos

 *) I intend to backport/review 2.2.x security patches over the next []
mos