In article <311417C8.4016@suphys.physics.su.oz.au> John Max Skaller
<maxtal@suphys.physics.su.oz.au> writes:

> James Kanze US/ESC 60/3/141 #40763 wrote:
> > I believe that the simple answer is that Windows programs operate in a
> > unhosted environment.
>
>  This is a clear condemnation of the Standard,
> Windows is obviously a hosting operating system.

Not necessarily in terms of the standard.  The standard defines what a
hosted environment must provide.  If Windows doesn't provide it, then it
is not a hosted environment.

> > |> But if a compiler does not accept
> >
> > |>      int main() { return 0; }
> >
> > |> as a complete program, then that compiler is not a conforming C or C++
> > |> implementation.

> This is the crux of the problem. More important, when I
> try to use "cout" the program won't link.

An unhosted environment does not have to provide cout.  I suspect that
most won't.

If there is not a way to get the above program to compile, link and
execute, however, then I will have to take back my defense of Microsoft
in previous postings.  I find this hard to believe, however.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

kanze@gabi.gabi-soft.fr (J. Kanze) wrote:

<snip>
>> > |> But if a compiler does not accept
>> >
>> > |>      int main() { return 0; }
>> >
>> > |> as a complete program, then that compiler is not a conforming C or C++
>> > |> implementation.
<snip>
>If there is not a way to get the above program to compile, link and
>execute, however, then I will have to take back my defense of Microsoft
>in previous postings.  I find this hard to believe, however.

The program does compile, link, and run, with the command

   cl test.cpp

The result was a Win32 version 4 console application.

I've written console apps under Windows 95 for file-format hacking and
so forth, and I've used Win32 console apps (and OS/2 character-mode
apps for that matter) as the basis of porting ray tracers and so
forth. More than once, I've had to page past Unix-bigotted rants about
how such and such wouldn't work on intel-based machines, as I scanned
through the readme's of portable programs.

The standards for C and C++ are working. There doesn't happen to be a
standard GUI library, which is why you have funky main functions under
some of the GUI's.


--------------
Mike Enright
75032.2070@compuserve.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

kanze@gabi.gabi-soft.fr (J. Kanze) talks to Fergus Hendersson
>> >FH> You are correct to infer that this means that all Windows programs
>> >FH> which do not define main() are ill-formed.
>
>> JK>Whether requiring a different start-up procedure than calling main is
>> JK>a good idea for this extension can be discussed under quality of
>> JK>implementation; it is not a standards question, however.
>>
>FH> Actually, I think it is, albeit not a direct one. Remember that the
>FH> purpose of the C++ standard is amoung other things to promote
>FH> portability of C++ programs.  Extensions should be done in a way that
>FH> makes it easy for customers to make selective use of them with
>FH> conditional compilation, so that they can easily write portable
>FH> programs that are nevertheless customized to take advantage of the
>FH> features of particular platforms.  Requiring a different start-up
>FH> procedure makes doing this more difficult than it need be.
>
JK>The different start-up procedure is only required if you are using
JK>Windows (I think).  To use Windows, they also require you use a lot of
JK>other special functions, that you won't find on any other machine.
>
>FH> I did not claim that any or all Windows compilers were not conforming.
>FH> I simply pointed out what they were required to do in order to conform.
>FH> I did say that
>FH> | I think the problem is due to Microsoft overlooking the C and C++
>FH> | standards, not vice versa.

By no means did I want to say that Microsoft is good. I was only surprised
that - with such a stress on portability - we were outlawing the entire
world's largest software market.
Also, it got me wondering whether the standard should say anything about
startup function name (let alone signature and calling convention) at all?
They are very different among the systems. Windows is the most distinct
example but slighter differences are plenty. E.g. some OSes (or is it OSs?)
pass parsed command line, some do not. DOS even prepares File Control
Blocks for first two parameters (treated as file names) [at least the docs
say so - never checked]. When object-oriented OSes arrive, they would
probably pass a rather elaborate data structures to programs. [Correct me
if I am wrong but isn't something like this already happening in OLE?]

               Cheers                        Genie
--
-----------------------------------------------------------------------
Eugene V. Radchenko              Research associate, Computer Chemistry
E-mail: eugene@qsar.chem.msu.su                   Fax: +7-(095)939-0290
Ordinary mail:     Chair of Organic Chemistry, Department of Chemistry,
                         Moscow State University, 119899 Moscow, Russia
## The careful application of terror is also a form of communication ##
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

>> It requires every program to have the main() function (which
>> implementation is not allowed to supply) with parameters (void) or (int
>> argc, int*argv[]). However, Windows programs have another convention:
>> prrogram must contain the function  int WinMain

I remember reading that you can write a Windows program with a main()
function and the usual command line arguments, and then the Microsoft
compiler will then generate WinMain somehow....but that the "operating
system" does link to WinMain.

                 David
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

Could window's main be simply like this:

int main(int argc, char *argv[]) {
     // do some stuff
     return WinMain(// stuff here);
}



[Moderator's note: There have been a number of similar articles about
the role of main() in a Windows program; this thread is beginning to get
a bit repetitive.  Please make sure, if you post something in this thread,
that it says something new about whether Windows implementations are
standard conforming and/or whether the standard needs to be modified to
accommodate Windows. mha]

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>|> "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
>
>|> The implementation is allowed to make the program work even if main() is
>|> not defined, so long as it issues a diagnostic.
>
>By a curious coincidence, this point has just been discussed in
>comp.std.c.  The concensus of the experts there was that the absense
>of main (or a non-conformant main) is simply undefined behavior: no
>diagnostic required.

If the comp.std.c experts are right, then I think that is a difference
between C++ and C, because the September 95 draft C++ standard makes it
pretty clear that a diagnostic is required.

| 3.6.1[basic.start.main]/1:
| A program shall contain a global function called main, which is the
| designated start of the program.

Here "shall" expresses a semantic requirement, and as 1.7 makes clear,
a diagnostic is required:

|   1.7  Processor compliance                           [intro.compliance]
|
| 1 Every conforming C++ processor  shall,  within  its  resource  limits,
|   accept and correctly execute well-formed C++ programs, and shall issue
|   at least one diagnostic message when  presented  with  any  ill-formed
|   program  that contains a violation of any diagnosable semantic rule or
|   of any syntax rule, except as noted herein.
[...]
| 3 The set of "diagnosable semantic rules" consists of all semantic rules
|   in  this  International  Standard except for those rules containing an
|   explicit notation that "no diagnostic is required."

James Kanze continues:

>I believe that the simple answer is that Windows programs operate in a
>unhosted environment.

That's a possible answer with regard to C conformance, but C++ is different:
C++ programs must contain main() even in an unhosted environment, according
to the September 95 draft C++ standard.  (The reason for this is because
the definition of the order of execution of constructors for global variables
is defined with reference to when main() gets invoked.)

I'm not sure whether Windows C/C++ compilers claim conformance to the
relevant C/C++ standards.  One would need to consult the documentation
for the compiler in question to see whether they claimed conformance,
and if so, whether they claimed conformance as a hosted or unhosted
environment.  Even if they do claim conformance, they will usually have
some conforming and some non-conforming modes of operation; you need to
be sure that the compiler is being invoked in the correct mode.

>Another interesting point that was made in the discussion on
>comp.std.c was that g++ normally operates in an unhosted environment,
>at least according FSF.

That depends on what you mean by "normally".  If you have installed g++
together with the GNU C and C++ libraries, then I believe that the FSF
would claim conformance (modulo the odd bug here and there) as a hosted
environment, not just as an unhosted environment.  This is normally the
case on Linux, for example, although I agree that it is probably not
normally the case on most other systems.

>|> You are correct to infer that this means that all Windows programs
>|> which do not define main() are ill-formed.
>
>No, he's not.  They are simply programs for non-hosted environments.

No, I beg to differ -- as explained above, C++ requires main() even
for non-hosted environemnts.

>Whether requiring a different start-up procedure than calling main is
>a good idea for this extension can be discussed under quality of
>implementation; it is not a standards question, however.

Actually, I think it is, albeit not a direct one. Remember that the
purpose of the C++ standard is amoung other things to promote
portability of C++ programs.  Extensions should be done in a way that
makes it easy for customers to make selective use of them with
conditional compilation, so that they can easily write portable
programs that are nevertheless customized to take advantage of the
features of particular platforms.  Requiring a different start-up
procedure makes doing this more difficult than it need be.

>I personally think that the Microsoft environment stinks, but I still
>get the feeling that there is a double standard at work here. If
>someone complains that g++ doesn't issue a diagnostic when I define a
>nested function, dozens of people (including you, Fergus?) will
>quickly point out that all I have to do is add the flags -ansi
>-pedantic, and it will; without these flags, the compiler is operating
>in a non-conformant mode, and this fact is in the compiler
>documentation.  Unless things have changed in the last 4 years, you
>need to give a special flag to the compiler to get Windows support.
>The default mode was the conformant mode.

I don't think I am applying a double standard.

I did not claim that any or all Windows compilers were not conforming.
I simply pointed out what they were required to do in order to conform.

I did say that

| I think the problem is due to Microsoft overlooking the C and C++
| standards, not vice versa.

but the problem I was referring to was not that Microsoft's compilers
don't conform to the standard (most likely they do) but rather that
Microsoft encourages people to write non-portable, non-standard-conforming
code which is then subject to the usual problems of vendor lock-in.

Now GNU's compilers also have their own extensions, and the problem of
vendor lock-in can also arise for programs that use GNU extensions, but
I do think GNU aims to minimize the difficulty of writing portable
programs that selectively take advantage of those additional features.
For example, the syntax of GNU's __attribute__ feature is designed to
make it easy to use a conditionally defined macro to enable/disable the
use of that feature.

>|> Windows compilers which wish to conform to the C and C++ standards
>|> should include code [...for WinMain()...]
>|> in their libraries, so that they can accept programs which define main()
>|> but not WinMain().
>
>And what will they do with all of the other Windows requests in the
>code?

They can do whatever they like.  I was reiterating the need
for Windows compilers to accept strictly conforming programs, and
showing how that could easily be implemented, in a way which made the
selective use of Windows features possible without the programmer
having to define WinMain(), even if the OS required a program to define
WinMain() rather than main().

--
Fergus Henderson              WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au               PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

James Kanze US/ESC 60/3/141 #40763 wrote:
> I believe that the simple answer is that Windows programs operate in a
> unhosted environment.

 This is a clear condemnation of the Standard,
Windows is obviously a hosting operating system.

> |> But if a compiler does not accept
>
> |>      int main() { return 0; }
>
> |> as a complete program, then that compiler is not a conforming C or C++
> |> implementation.


This is the crux of the problem. More important, when I
try to use "cout" the program won't link. This is
important to me -- I've scrapped Win3.11 in favour
of NT mainly because of this deficiency (in Win3.1 wrt
the Standard).

In my opinion, program startup and environment
shouldn't be part of the language standard at all.

Instead, requirements should be created for creating
a BINDING to a particular environment, and then
bindings created.

For example, a POSIX binding would be popular;
but MS would still be free to create a Windows
binding.

In effect, there are _industry_ standards which
supercedes the ISO one, which is clearly
inadequate for modern needs. Unfortunately,
none of the "standards" are portable, _including_
the ISO one.

The distinction between "hosted" and "unhosted"
systems is better than nothing -- but it was more
useful 20 years ago than it is now, when it is
simply far too weak. (I.e two levels is just
not a good enough design any more)


--
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 web: http://www.maxtal.com.au/~skaller/
AUSTRALIA                      email: skaller@maxtal.com.au
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) wrote:

>I did not claim that any or all Windows compilers were not conforming.
>I simply pointed out what they were required to do in order to conform.

>I did say that

>| I think the problem is due to Microsoft overlooking the C and C++
>| standards, not vice versa.

>but the problem I was referring to was not that Microsoft's compilers
>don't conform to the standard (most likely they do) but rather that
>Microsoft encourages people to write non-portable, non-standard-conforming
>code which is then subject to the usual problems of vendor lock-in.

YES, YES, YES.  This is IT.

*IF* Microsoft decides that it's profitable, they may in the future
allow a standard-conforming C++ program to be compiled and executed.
My guess is that they won't bother.  It'll be easy enough to feign
"true compatability" while taking as much liberty as GNU does,
blithely compiling and executing programs that the standard says
should fail with diagnostics.

I know full well that my Windows programs follow Microsoft's
standards, and not anyone elses; Microsoft C, not ANSI or ISO; ODBC,
not SQL-92 nor SAG CLI, etc.

My only hope of "portability" is on a smaller component level.  I can
write fully ANSI-compliant functions and objects, but once compiled
and linked into a Windows program the whole becomes Microsoft-defined.

For what it's worth, I think the answer to the subject line is "yes".
All Windows programs are ill-formed according to the C++ standard.

--
Richard Krehbiel, Kastle Systems, Arlington VA USA
rich@kastle.com (work) or richk@mnsinc.com (personal)
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

David Byrden <100101.2547@compuserve.com> (02 Feb 96):

> >> It requires every program to have the main() function (which
> >> implementation is not allowed to supply) with parameters (void) or (int
> >> argc, int*argv[]). However, Windows programs have another convention:
> >> prrogram must contain the function  int WinMain
>
> I remember reading that you can write a Windows program with a main()
> function and the usual command line arguments, and then the Microsoft
> compiler will then generate WinMain somehow....but that the "operating
> system" does link to WinMain.

No, the operating system doesn't care whether there is a
WinMain(), a main() or anything else. It just reads a
pointer  from the exe file and calls it. This is usually the
C/C++ statup code, which then calls WinMain() or main().
If there is a main present, the linker makes the startup
code call it, if not the linker either sets in an own
main(), which calls WinMain(), or another startup code,
which calls main().

Claus

------------------------------------------------------------------------
Claus Andre Faerber - claus@faerber.muc.de - http://www.muc.de/~cfaerber
------------------------------------------------------------------------

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

rich@kastle.com writes:
>*IF* Microsoft decides that it's profitable, they may in the future
>allow a standard-conforming C++ program to be compiled and executed.
>My guess is that they won't bother.  It'll be easy enough to feign
>"true compatability" while taking as much liberty as GNU does,
>blithely compiling and executing programs that the standard says
>should fail with diagnostics.

There is a distinction between failing to compile correct programs and
permitting extensions.  Compilers that do permit extensions (such as GNU)
should provide a mechanism for turning extensions off (with GNU C++ you do
this with -ansi -pedantic).  Compilers aren't perfect; to improve them,
users should file bug reports.  But before filing a "this program should
have been rejected" report, you should make sure you've followed the
directions for turning off extensions.

--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)

Work for something because it is good,
not just because it stands a chance to succeed.    -- Vaclav Havel
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

Claus A. Faerber <claus@faerber.muc.de> (07 Feb 96):

> David Byrden <100101.2547@compuserve.com> (02 Feb 96):
>
> > >> It requires every program to have the main() function (which
> > >> implementation is not allowed to supply) with parameters (void) or (int
> > >> argc, int*argv[]). However, Windows programs have another convention:
> > >> prrogram must contain the function  int WinMain
> >
> > I remember reading that you can write a Windows program with a main()
> > function and the usual command line arguments, and then the Microsoft
> > compiler will then generate WinMain somehow....but that the "operating
> > system" does link to WinMain.
>
> No, the operating system doesn't care whether there is a
> WinMain(), a main() or anything else. It just reads a
> pointer  from the exe file and calls it. This is usually the
> C/C++ statup code, which then calls WinMain() or main().
> If there is a main present, the linker makes the startup
> code call it, if not the linker either sets in an own
> main(), which calls WinMain(), or another startup code,
> which calls main().
              ^^^ should be: WinMain()

But at all, there's no problem with Windows programs:

* If you're writing Win32 console apps or using special
libraries like EasyWin or QuickWin (which allow normal text
in/out operations in the Windows GUI), you will have a
standard main()

* If you're programming native Win16/32 GUI apps, you're
using an extended/modified C/C++-standard (unhosted env.),
as you don't have stdin/out/error and hundreds(thousands?)
of functions invading your namespace and: no main(), but Win/
LibMain.

Claus

------------------------------------------------------------------------
Claus Andre Faerber - claus@faerber.muc.de - http://www.muc.de/~cfaerber
------------------------------------------------------------------------
---
[ To submit articles: Try just posting with your newsreader.  If that fails,
                      use mailto:std-c++@ncar.ucar.edu
  FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std.c++-request@ncar.ucar.edu
]

The requirement for a 'main' can NOT be built into the compiler because
a program can be split into seperatly compilable source modules.  When
compiling any given module there is no way of determining if it is the
one and only module in the program that contains 'main'.  At best the
requirement for a 'main' is a requirement on the linker.

Actually requiring a program to have a 'main' may be a problem.  What
should probably be required is a capability to have a 'main' but allow
other mechanisms that produce a comparable effect.  (No, I have no idea
how to phrase that.)

There are other extensions to be considered.  A number of UNIX based
systems allow an 'envp' as a third argument.  This seems to imply that
'main' is quite different from other C++ functions that overload on the
number and type of its arguments.  In fact, it is much closer to a 'C'
style function in its ability to handle a variable number of arguments.

        Max
---
[ To submit articles: Try just posting with your newsreader.  If that fails,
                      use mailto:std-c++@ncar.ucar.edu
  FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std.c++-request@ncar.ucar.edu
]

Hi!
I have just realized that something is grossly overlooked in C++ standard.
It requires every program to have the main() function (which implementation
is not allowed to supply) with parameters (void) or (int argc, int*argv[]).
However, Windows programs have another convention: prrogram must contain
the function
  int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline, int cmdShow)
Some of this is of course quirks or even outright ignored in Win32
(prevInst), but the full non-parsed command line could be useful sometimes,
and not all implementations provide the function retrieving it. And anyway
this is definitely not a main() from the specs. Maybe the requirements on
the main() should be relaxed somehow?

                Best regards                     Genie

--
--------------------------------------------------------------------
Eugene V. Radchenko           Research associate, Computer Chemistry
E-mail: eugene@qsar.chem.msu.su                Fax: +7-(095)939-0290
Ordinary mail:  Chair of Organic Chemistry, Department of Chemistry,
                      Moscow State University, 119899 Moscow, Russia
*****************  Disappearances are deceptive  *******************
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Eugene Radchenko <eugene@qsar.chem.msu.su> wrote about
Are all Windows programs ill-formed?
in article <AE5J83na99@qsar.chem.msu.su> of 29 Jan 96:
> Hi!
> I have just realized that something is grossly overlooked in C++ standard.
> It requires every program to have the main() function (which implementation
> is not allowed to supply) with parameters (void) or (int argc, int*argv[]).
> However, Windows programs have another convention: prrogram must contain
> the function
>   int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline, int
> cmdShow) Some of this is of course quirks or even outright ignored in Win32
> (prevInst), but the full non-parsed command line could be useful sometimes,
> and not all implementations provide the function retrieving it. And anyway
> this is definitely not a main() from the specs. Maybe the requirements on
> the main() should be relaxed somehow?

The actual main() procedure is part of the C++ Windows run-
time library and it's this function which calls Win/LibMain.

Claus

------------------------------------------------------------------------
Claus Andre Faerber - claus@faerber.muc.de - http://www.muc.de/~cfaerber
------------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

"Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:

>I have just realized that something is grossly overlooked in C++ standard.

I think the problem is due to Microsoft overlooking the C and C++
standards, not vice versa.

>It requires every program to have the main() function (which implementation
>is not allowed to supply) with parameters (void) or (int argc, int*argv[]).

The implementation is allowed to make the program work even if main() is
not defined, so long as it issues a diagnostic.

>However, Windows programs have another convention: prrogram must contain
>the function
>  int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline, int cmdShow)

A compiler is allowed to accept the program

 int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline,
  int cmdShow)
 {
  return 0;
 }

so long as it issues at least one diagnostic, e.g.
"warning: standard C++ requires a definition of main()".

But if a compiler does not accept

 int main() { return 0; }

as a complete program, then that compiler is not a conforming C or C++
implementation.

>Some of this is of course quirks or even outright ignored in Win32
>(prevInst), but the full non-parsed command line could be useful sometimes,
>and not all implementations provide the function retrieving it.

In many operating systems, the command-line parsing is done by the
shell, not the OS.  Such operating systems cannot provide the non-parsed
command line.

>And anyway this is definitely not a main() from the specs.
>Maybe the requirements on the main() should be relaxed somehow?

Are you suggesting relaxing the requirements on implementations,
or the requirements on programs?

I presume you are referring to 3.6.1[basic.start.main]/1:

| A program shall contain a global function called main, which is the
| designated start of the program.

You are correct to infer that this means that all Windows programs
which do not define main() are ill-formed.

However, that means only that a compiler is required to issue
a diagnostic; it does not mean that the compiler must reject the
program.

Obviously a program that does not define main() is not going to be
portable, so I don't think that requirement on programs should be
relaxed.

Windows compilers which wish to conform to the C and C++ standards
should include code similar to

 HINSTANCE __curInst;
 HINSTANCE __prevInst;
 LPSTR __cmdline;
 int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline,
  int cmdShow)
 {
  int argc;
  char **argv;

  __curInst = curInst;
  __prevInst = prevInst;
  __cmdLind = cmdLine;
  __parse_command_line(cmdline, &argc, &argv);
  return main(argc, argv);
 }

in their libraries, so that they can accept programs which define main()
but not WinMain().

--
Fergus Henderson              WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au               PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]