Re: winetest: run with -mwindows

[Jakob Eriksson]

Hmm... what is the problem with GUI and command line interface.
I don't think there should be any particalur problems, what happens?

Ferenc Wagner wrote:
> Okay, it wasn't true, actually.  So, this patch solves the
> immediate problem, but is not the full solution.  How do you
> write a program which has both GUI and CUI?  Is there any
> way to use standard IO in a program compiled with -mwindows
> but run from a console?
>
> ChangeLog: 
>  Don't expect stdout be usable after exchanging file
>  descriptors under it.
> Index: main.c
>
> RCS file: /home/wine/wine/programs/winetest/main.c,v
> retrieving revision 1.7
> diff -u -r1.7 main.c
> --- main.c	20 Mar 2004 19:21:39 -0000	1.7
> +++ main.c	24 Mar 2004 13:30:26 -0000
> @@ -337,8 +337,6 @@
>     SetErrorMode (SEM_FAILCRITICALERRORS);
> if (!(wineloader = getenv("WINELOADER"))) wineloader = "wine";
> -
>
> if (setvbuf (stdout, NULL, _IONBF, 0))
> -
>    report (R_FATAL, "Can't unbuffer output.");
>
> tempdir = tempnam (0, "wct");
>   if (!tempdir)
> Index: util.c
>
> RCS file: /home/wine/wine/programs/winetest/util.c,v
> retrieving revision 1.4
> diff -u -r1.4 util.c
> --- util.c	19 Mar 2004 19:15:23 -0000	1.4
> +++ util.c	24 Mar 2004 13:30:26 -0000
> @@ -19,6 +19,7 @@
> -
>
> */
> #include <windows.h>
> +#include <unistd.h>
> #include <errno.h>
>
> #include "winetest.h"
> @@ -39,26 +40,14 @@
>     return p;
> }
>
> -void xprintf (const char *fmt, ...)
> -{
> - va_list ap;
> -
> - va_start (ap, fmt);
> - if (vprintf (fmt, ap) < 0)
> -
>    report (R_FATAL, "Can't write logs: %d", errno);
> - va_end (ap);
>
> -}
> -
>
> -char *vstrmake (size_t *lenp, va_list ap)
> +char *vstrfmtmake (size_t *lenp, const char *fmt, va_list ap)
> {
> -
>
> char *fmt;
> size_t size = 1000;
> char *p, *q;
> int n;
>
> p = malloc (size);
> if (!p) return NULL;
> -
>
> fmt = va_arg (ap, char*);
> while (1) {
>    n = vsnprintf (p, size, fmt, ap);
>    if (n < 0) size *= 2;   /* Windows */
>
> @@ -75,6 +64,14 @@
>     return p;
> }
>
> +char *vstrmake (size_t *lenp, va_list ap)
> +{
> - const char *fmt;
> -
> - fmt = va_arg (ap, const char*);
> - return vstrfmtmake (lenp, fmt, ap);
>
> +}
> -
>
> char *strmake (size_t *lenp, ...)
> {
>     va_list ap;
> @@ -85,6 +82,26 @@
>     if (!p) report (R_FATAL, "Out of memory.");
>     va_end (ap);
>     return p;
> +}
> -
>
> +void xprintf (const char *fmt, ...)
> +{
> - va_list ap;
> - size_t size;
> - ssize_t written;
> - char *buffer, *head;
> -
> - va_start (ap, fmt);
> - buffer = vstrfmtmake (&size, fmt, ap);
> - head = buffer;
> - va_end (ap);
> - while ((written = write (1, head, size)) != size) {
> -
>    if (written == -1)
> -
>        report (R_FATAL, "Can't write logs: %d", errno);
> -
>    head += written;
> -
>    size -= written;
> - }
> - free (buffer);
>
> }
>
> char *

winetest: run with -mwindows

[Ferenc Wagner]

Jakob Eriksson  writes:
> Ferenc Wagner wrote:
> > this patch solves the immediate problem, but is not the
> > full solution.  How do you write a program which has both
> > GUI and CUI?  Is there any way to use standard IO in a
> > program compiled with -mwindows but run from a console?
>
> Hmm... what is the problem with GUI and command line
> interface.  I don't think there should be any particalur
> problems, what happens?

For redirecting standard output to a file, I used

dup2 (fh, 1);
printf ("Thing to write");

which didn't work in the cross-compiled program if it was
linked with -mwindows.  This issue is solved by using
write() directly thus bypassing the stream level.  Linking
without -mwindows pops up a console, which is ugly and
unnecessary, unless you use the -c command line option to
select console mode.  But once you link with -mwindows, you
can't use stdio etc. on any level, not even if the program
is run from a console.  Which means that you can't have a
program which both has a GUI and CLI, selected by some
mechanism.  The only way out is actively using the console
API, at least to my present knowledge.  I would be more than
happy to stand corrected.  It can't be such an exotic
situation!

winetest: run with -mwindows

[Jakob Eriksson]

Ferenc Wagner wrote:
> For redirecting standard output to a file, I used
>
> dup2 (fh, 1);
> printf ("Thing to write");
>
> which didn't work in the cross-compiled program if it was
> linked with -mwindows.  This issue is solved by using
> write() directly thus bypassing the stream level.  Linking
> without -mwindows pops up a console, which is ugly and
> unnecessary, unless you use the -c command line option to
> select console mode.  But once you link with -mwindows, you
> can't use stdio etc. on any level, not even if the program
> is run from a console.  Which means that you can't have a
> program which both has a GUI and CLI, selected by some
> mechanism.  The only way out is actively using the console
> API, at least to my present knowledge.  I would be more than
> happy to stand corrected.  It can't be such an exotic
> situation!

I couldn't find anything really clear on the subject.  If you go the 
console API way,
maybe this can help:
http://c.conclase.net/conio/index.php
(At the bottom there is a download thing.)

Jakobi

winetest: run with -mwindows

[Ferenc Wagner]

Jakob Eriksson  writes:
> I couldn't find anything really clear on the subject.  If
> you go the console API way, maybe this can help:
> http://c.conclase.net/conio/index.php
> (At the bottom there is a download thing.)

Thanks, I think I will just leave it for now.  The console
mode is mostly useful for debugging, and relinking without
-mwindows should make it work.

winetest: run with -mwindows

[Dimitrie O. Paun]

On Thu, 25 Mar 2004, Ferenc Wagner wrote:
> Thanks, I think I will just leave it for now.  The console
> mode is mostly useful for debugging, and relinking without
> -mwindows should make it work.

I haven't looked into the problem, but why not give up on stdout
altogether, and just fopen() a file, a fprintf() to it? This
should always work, no?

winetest: run with -mwindows

[Ferenc Wagner]

"Dimitrie O. Paun"  writes:
> On Thu, 25 Mar 2004, Ferenc Wagner wrote:
> > Thanks, I think I will just leave it for now.  The console
> > mode is mostly useful for debugging, and relinking without
> > -mwindows should make it work.
>
> I haven't looked into the problem, but why not give up on stdout
> altogether, and just fopen() a file, a fprintf() to it? This
> should always work, no?

Sure, but wouldn't make much sense: one could as well read
the report file instead.  It's aim is to provide some easily
accessible feedback for the user about the process.