Re: [LINUX5250] Porting scs2* to windows

["Jeremy Stent" <stentj@xxxxxxx>]

For the random filename, I believe that in windows there is an OS
call that will return a unique filename.  I haven't used it in a
while, but I seem to remember that you could specify some properties
of it (starting letters / extension?) and have it return the rest.  I
know that this would be OS-Specific, but the appropriate code could
always be wrapped in an #ifdef.

I haven't tried the latest windows patch, but the one from last week
seems quite nice.  I was just wondering if it could somehow be made
to respond to the Ctrl key.  My company currently provides Client
Access, which works well enough, (except after the last upgrade when
it wanted to call some program that we had lost permissions on) and I
like the Right Ctrl to be the Newline.

On 19 Mar 2002 at 19:13, linux5250-request@midrange.co wrote:
> Date: Tue, 19 Mar 2002 14:58:36 -0700 (MST)
> From: James Rich <james@eaerich.com>
> To: tn5250 <linux5250@midrange.com>
> Subject: Re: [LINUX5250] Porting scs2* to windows
> Reply-To: linux5250@midrange.com
>
> On Tue, 19 Mar 2002, Scott Klement wrote:
>
> > On Tue, 19 Mar 2002, James Rich wrote:
> > >
> > > Would porting to windows be easier if the following could be done:
> > >
> > > 1.  lp5250d always writes the SCS stream received from the iSeries to a
> > > temporary file, say c:\tn5250\tmp\lp5250d123.scs
> >
> > Yes, but it would need to do something to make sure that if two copies of
> > lp5250d are running, they don't both try to use the same temp file.
>
> Maybe using some mechanism similar to:
>
> FILENAME=cat /dev/urandom
>
> Obviously windows doesn't have /dev/urandom, but I think the same could be
> done.  lp5250d creates a filename that has some random characters in it.
>
> > > 2.  After writing to the temp file is complete, lp5250d calls the
> > > appropriate conversion program with the temp file name as an argument and
> > > the destination file name as another argument, something like:
> > >
> > > scs2ascii --infile=c:\tn5250\tmp\lp5250d123.scs
> > > --outfile=c:\tn5250\tmp\lp5250d123.txt
> >
> > That would work, but:
> >
> >      1) I'd use the same style command-line arguments that you use
> >             in tn5250 and lp5250d, for consistency.
>
> Yes, I was just making those up since I have no idea what constitutes a
> command line argument in windows.  Isn't something like DOS switches?
>
> >      2) This would make the configuration a lot more complicated
> >             because you'd have to specify all of the arguments in
> >             your outputcommand= config keyword for lp5250d.   It
> >             would make sense to those of us who know how it works,
> >             but seem unnecessarily convoluted to everyone else.
>
> The input file would not be specified since lp5250d would be creating a
> file with a random name anyway.  when lp5250d starts scs2* it would modify
> the command line to include the input filename.
>
> > In any case, it seems unnecessary.  You'd still need a way to get
> > the data to the printer.  Sure, I could write my own "lpr" command for
> > Windows, but that wouldn't be intuitive to your average Windows user.
> >
> > I'd rather make the lp5250d command under Windows able to attach to
> > the scs2pdf routines, or the scs2ps or scs2ascii as needed, and then
> > receive the data back and write it wherever I want.
>
> By attach do you mean "put the functions in scs2pdf.c into lp5250-win.c"?
>
> > Then I could bring up the standard Windows dialog box to prompt
> > the user for a file, or printer, etc. if I wanted to.
>
> Again, I don't know how things really get printed in windows, so I was
> mostly just seeing what might work.  AFAICT every windows application has
> to know how to control the printer;  there isn't a way to say "print this
> file" without starting some app to do the printing for you.
>
> > > 3.  scs2* work basically unchanged from what they are now, except that
> > > they can read from a file in addition to stdin and output to a file in
> > > addition to stdout.
> >
> > We could do that with redirection, couldn't we?
>
> I didn't know redirection worked on windows.
>
> James Rich
> james@eaerich.com