Anyone writing console apps using win32api ? 
Author Message
 Anyone writing console apps using win32api ?

Anyone out there got some examples of console usage using only the
win32api ? Ive found both Fujitsu and Merants compilers pretty lacking
in this respect. Please don't respond with just the CBL_ routines.

TIA
Alister



Fri, 26 Sep 2003 01:13:08 GMT  
 Anyone writing console apps using win32api ?
Just FYI so you don't go wasting a bunch of time, Fujitsu simply can't
in and of itself do this.   They have good support for the API with
ths singular exception that you can't register your entrypoint (No
Procedure Pointer yet).  I know that others have written C Stubs to
handle this, and call Fujitsu COBOL from this stub.  

In addition, very little documentation exists on interfacing with the
Windows API from COBOL.  Hopefully with .NET this might change, but
presently MS puts no emphasis on it.  

On Sun, 8 Apr 2001 18:13:08 +0100, "Alister Munro"

Quote:

>Anyone out there got some examples of console usage using only the
>win32api ? Ive found both Fujitsu and Merants compilers pretty lacking
>in this respect. Please don't respond with just the CBL_ routines.

>TIA
>Alister



Tue, 07 Oct 2003 20:05:24 GMT  
 Anyone writing console apps using win32api ?
Thane,

I use the Win32 API with Fujitsu COBOL regularly, although I have not tried
using the console with it, so was interested to read your post.

There is one line which I take issue with...

"They have good support for the API with this singular exception ..."

They have NO support for any of the Registry API calls because they do not
provide Import Libraries for the advapi32.dll. In fact, the ONLY API .dlls
which are supported are the Kernel and User.

As access to the Registry is a pretty fundamental requirement for serious
Windows apps, I consider this to be a regrettable omission which I hope will
be corrected in future versions of the compiler.

The official response is that if the API is invoked dynamically there is no
need for an Import Library.

However, some of these calls are so complex in their parameter passing that
I for one, have been unable to get them to work (notwithstanding they
compiled OK).  I am no slouch at this game, but despite spending many hours
with various Registry Opens, Searches,  and Updates, there are still some
Calls I have NEVER been able to get to work correctly when invoked
dynamically.

I believe that, compared to the API  support offered with Delphi
(f'instance) and VB, COBOL is VERY badly served (not just by Fujitsu, but
most COBOL vendors).

Pete.

Quote:

>Just FYI so you don't go wasting a bunch of time, Fujitsu simply can't
>in and of itself do this.   They have good support for the API with
>ths singular exception that you can't register your entrypoint (No
>Procedure Pointer yet).  I know that others have written C Stubs to
>handle this, and call Fujitsu COBOL from this stub.

>In addition, very little documentation exists on interfacing with the
>Windows API from COBOL.  Hopefully with .NET this might change, but
>presently MS puts no emphasis on it.

>On Sun, 8 Apr 2001 18:13:08 +0100, "Alister Munro"

>>Anyone out there got some examples of console usage using only the
>>win32api ? Ive found both Fujitsu and Merants compilers pretty lacking
>>in this respect. Please don't respond with just the CBL_ routines.

>>TIA
>>Alister

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----


Tue, 07 Oct 2003 20:59:45 GMT  
 Anyone writing console apps using win32api ?


Quote:

> They have NO support for any of the Registry API calls because they
do not
> provide Import Libraries for the advapi32.dll. In fact, the ONLY API
.dlls
> which are supported are the Kernel and User.

Which I found out after (too) much experimentation.

I wanted to get the version and release numbers of a program (to
display in an "About" box) which is - in other environments -a simple
API call. Ended up using a free Active-X control, and using the
control actually turned out better because the control provides more
information.



Tue, 07 Oct 2003 22:29:21 GMT  
 Anyone writing console apps using win32api ?
Components Rule, Jerry!

Pete.


Quote:


>> They have NO support for any of the Registry API calls because they
>do not
>> provide Import Libraries for the advapi32.dll. In fact, the ONLY API
>.dlls
>> which are supported are the Kernel and User.

>Which I found out after (too) much experimentation.

>I wanted to get the version and release numbers of a program (to
>display in an "About" box) which is - in other environments -a simple
>API call. Ended up using a free Active-X control, and using the
>control actually turned out better because the control provides more
>information.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----


Tue, 07 Oct 2003 22:50:10 GMT  
 Anyone writing console apps using win32api ?

Quote:


> > They have NO support for any of the Registry API calls because they
> do not
> > provide Import Libraries for the advapi32.dll. In fact, the ONLY API
> .dlls
> > which are supported are the Kernel and User.

> Which I found out after (too) much experimentation.

> I wanted to get the version and release numbers of a program (to
> display in an "About" box) which is - in other environments -a simple
> API call. Ended up using a free Active-X control, and using the
> control actually turned out better because the control provides more
> information.

Hmm, might it be possible to do this?

1. Get the actual EXPORTed name of the desired API call from the DLL using
something like the NT Quickview or a shareware product like PEBrowse (best
20 bucks you can spend if you need those "mangled" EXPORT names).

2. Use the LoadLibrary and GetProcAddress APIs to make the function
available to your process. Return GetProcAddress into a COBOL
PROCEDURE-POINTER datatype. Yes, you can use USER32.DLL, or GDI or KERNEL or
any other system DLL with LoadLibrary.

3.Call using whatever mechanism the particular compiler uses to CALL by
procedure-pointer (address). You may need to reverse the order of the passed
parameters for that C-language crap; I am not sure about that.

I don't know enough about the various Windows/COBOL compilers to know this
will always work, but this is a method I use for my Windows/BASIC language
programs and is probably worth a look for someone.

--
Michael C. Mattias
Tal Systems
Racine WI



Tue, 07 Oct 2003 23:33:22 GMT  
 Anyone writing console apps using win32api ?
I opted for:

     MOVE 'MYPROG.DLL' TO 'FileName' OF MYCONTROL.

     MOVE 'ProductVersion' OF MYCONTROL TO DISPLAY-PVERSION.
     MOVE 'FileVersion' OF MYCONTROL TO DISPLAY-FVERSION.
     MOVE 'LastAccessDate' OF MYCONTROL TO DISPLAY-LADATE

     etc.

(Snap fingers here)


Quote:



> > > They have NO support for any of the Registry API calls because
they
> > do not
> > > provide Import Libraries for the advapi32.dll. In fact, the ONLY
API
> > .dlls
> > > which are supported are the Kernel and User.

> > Which I found out after (too) much experimentation.

> > I wanted to get the version and release numbers of a program (to
> > display in an "About" box) which is - in other environments -a
simple
> > API call. Ended up using a free Active-X control, and using the
> > control actually turned out better because the control provides
more
> > information.

> Hmm, might it be possible to do this?

> 1. Get the actual EXPORTed name of the desired API call from the DLL
using
> something like the NT Quickview or a shareware product like PEBrowse
(best
> 20 bucks you can spend if you need those "mangled" EXPORT names).

> 2. Use the LoadLibrary and GetProcAddress APIs to make the function
> available to your process. Return GetProcAddress into a COBOL
> PROCEDURE-POINTER datatype. Yes, you can use USER32.DLL, or GDI or
KERNEL or
> any other system DLL with LoadLibrary.

> 3.Call using whatever mechanism the particular compiler uses to CALL
by
> procedure-pointer (address). You may need to reverse the order of
the passed
> parameters for that C-language crap; I am not sure about that.

> I don't know enough about the various Windows/COBOL compilers to
know this
> will always work, but this is a method I use for my Windows/BASIC
language
> programs and is probably worth a look for someone.

> --
> Michael C. Mattias
> Tal Systems
> Racine WI




Wed, 08 Oct 2003 06:03:23 GMT  
 Anyone writing console apps using win32api ?
Thanks Michael.

This certainly looks feasible.

I guess what irritates is that, having spent money on the COBOL compiler, it
is then necessary to buy another product (Windows SDK or the software you
mention) in order to really use the API. This compares very unfavourably
with environments like VB and Delphi where full support for API calls is
included.

Pete.


Quote:



>> > They have NO support for any of the Registry API calls because they
>> do not
>> > provide Import Libraries for the advapi32.dll. In fact, the ONLY API
>> .dlls
>> > which are supported are the Kernel and User.

>> Which I found out after (too) much experimentation.

>> I wanted to get the version and release numbers of a program (to
>> display in an "About" box) which is - in other environments -a simple
>> API call. Ended up using a free Active-X control, and using the
>> control actually turned out better because the control provides more
>> information.

>Hmm, might it be possible to do this?

>1. Get the actual EXPORTed name of the desired API call from the DLL using
>something like the NT Quickview or a shareware product like PEBrowse (best
>20 bucks you can spend if you need those "mangled" EXPORT names).

>2. Use the LoadLibrary and GetProcAddress APIs to make the function
>available to your process. Return GetProcAddress into a COBOL
>PROCEDURE-POINTER datatype. Yes, you can use USER32.DLL, or GDI or KERNEL
or
>any other system DLL with LoadLibrary.

>3.Call using whatever mechanism the particular compiler uses to CALL by
>procedure-pointer (address). You may need to reverse the order of the
passed
>parameters for that C-language crap; I am not sure about that.

>I don't know enough about the various Windows/COBOL compilers to know this
>will always work, but this is a method I use for my Windows/BASIC language
>programs and is probably worth a look for someone.

>--
>Michael C. Mattias
>Tal Systems
>Racine WI


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----


Wed, 08 Oct 2003 08:50:05 GMT  
 Anyone writing console apps using win32api ?
On Fri, 20 Apr 2001 15:33:22 GMT, "Michael Mattias"

Quote:

>Hmm, might it be possible to do this?
>2. Use the LoadLibrary and GetProcAddress APIs to make the function
>available to your process. Return GetProcAddress into a COBOL
>PROCEDURE-POINTER datatype. Yes, you can use USER32.DLL, or GDI or KERNEL or
>any other system DLL with LoadLibrary.

You said the magic word.  Procedure pointers are not yet supported in
Fujitsu COBOL - and that was the point of my original reply.


Wed, 08 Oct 2003 09:28:52 GMT  
 Anyone writing console apps using win32api ?
Real Men access the Registry with LoadLibrary/GetProcAddress.

MCM


Quote:
> I opted for:

>      MOVE 'MYPROG.DLL' TO 'FileName' OF MYCONTROL.

>      MOVE 'ProductVersion' OF MYCONTROL TO DISPLAY-PVERSION.
>      MOVE 'FileVersion' OF MYCONTROL TO DISPLAY-FVERSION.
>      MOVE 'LastAccessDate' OF MYCONTROL TO DISPLAY-LADATE

>      etc.

> (Snap fingers here)






> > > > They have NO support for any of the Registry API calls because
> they
> > > do not
> > > > provide Import Libraries for the advapi32.dll. In fact, the ONLY
> API
> > > .dlls
> > > > which are supported are the Kernel and User.

> > > Which I found out after (too) much experimentation.

> > > I wanted to get the version and release numbers of a program (to
> > > display in an "About" box) which is - in other environments -a
> simple
> > > API call. Ended up using a free Active-X control, and using the
> > > control actually turned out better because the control provides
> more
> > > information.

> > Hmm, might it be possible to do this?

> > 1. Get the actual EXPORTed name of the desired API call from the DLL
> using
> > something like the NT Quickview or a shareware product like PEBrowse
> (best
> > 20 bucks you can spend if you need those "mangled" EXPORT names).

> > 2. Use the LoadLibrary and GetProcAddress APIs to make the function
> > available to your process. Return GetProcAddress into a COBOL
> > PROCEDURE-POINTER datatype. Yes, you can use USER32.DLL, or GDI or
> KERNEL or
> > any other system DLL with LoadLibrary.

> > 3.Call using whatever mechanism the particular compiler uses to CALL
> by
> > procedure-pointer (address). You may need to reverse the order of
> the passed
> > parameters for that C-language crap; I am not sure about that.

> > I don't know enough about the various Windows/COBOL compilers to
> know this
> > will always work, but this is a method I use for my Windows/BASIC
> language
> > programs and is probably worth a look for someone.

> > --
> > Michael C. Mattias
> > Tal Systems
> > Racine WI




Wed, 08 Oct 2003 20:42:40 GMT  
 Anyone writing console apps using win32api ?


Quote:
> Thanks Michael.

> This certainly looks feasible.

> I guess what irritates is that, having spent money on the COBOL compiler,
it
> is then necessary to buy another product (Windows SDK or the software you
> mention) in order to really use the API. This compares very unfavourably
> with environments like VB and Delphi where full support for API calls is
> included.

> Pete.

But you get what you pay for: When you use VB or Delphi or many of the
"easy-to-use" language products, a lot of "routine" programming becomes very
straightforward (read, "easy").  The cost is that doing something "other
than OUR WAY" becomes difficult. It appears Fujitsu has not supplied a real
good platform for extensive API calls, since a lot of the API calls require
a procedure-pointer.

For API reference, I have a "library" subscription to MSDN which cost me
$207 the first year and $114 for this current year. You get all the API
reference on CD. MS also make this available on-line for free, but with a
single phone line and a dialup connection, just browsing the list of
available calls is a pain.

MSDN offers two additional levels of subcription, but those include copies
of new operating systems, driver develpment kits and a whole bunch of stuff
I don't need, so I just went with the 'entry-level' subscription.

I am one of the most vocal people I know re praising the way MS has
implemented the Windows API. There are functions and functions to do damn
near anything, quickly and without bugs and the reference documentation is
well done. The MSDN includes a lot of code samples, but those are not of
much use to me, as they are all written in Microsoft C++, Microsoft Visual
BASIC, Microsoft FoxPro and  Microsoft whatever. (And all the Internet
examples assume you use Microsoft Internet Explorer as your browser).

MCM

MCM



Wed, 08 Oct 2003 21:39:35 GMT  
 Anyone writing console apps using win32api ?

Quote:
> On Fri, 20 Apr 2001 15:33:22 GMT, "Michael Mattias"

> >Hmm, might it be possible to do this?

> >2. Use the LoadLibrary and GetProcAddress APIs to make the function
> >available to your process. Return GetProcAddress into a COBOL
> >PROCEDURE-POINTER datatype. Yes, you can use USER32.DLL, or GDI or KERNEL
or
> >any other system DLL with LoadLibrary.

> You said the magic word.  Procedure pointers are not yet supported in
> Fujitsu COBOL - and that was the point of my original reply.

Well, phooey. Oh, well,maybe someone got an idea from it anyway.

Can Fujitsu call a DLL which might be called like this?

01  Target-Address PIC 9(9) USAGE BINARY.
01  LibName          PIC X(20)
01  ProcName        PIC X(30)

CALL "CallByAddress"  USING   TargetAddress, parm-1, parm-2, parm-3....

or maybe something like

CALL "CallWin32API" using  LibName, ProcName, parm1, parm2..parm3.....

If FJ can do this, it might be fun for me to write a DLL which serves as a
"service layer" and my DLL would actually do the API call and return the
results.

I'd need to think a little bit more about the parameter list and how to
handle this, but I KNOW my compiler (powerbasic PB/DLL) can handle the
call-by-address and variable number of parameters part of it, and I know I
can handle the coding to pass and return the values. (Of course, I tend to
believe I can code anything).

If anyone is interested in this, post here for now. If there's enough
interest, I can take the discussion off-line.

--
Michael C. Mattias
Tal Systems
Racine WI

If Fujitsu can call a standard Windows DLL, I could write a DLL to handle to
registry access.  It could be



Wed, 08 Oct 2003 21:39:36 GMT  
 Anyone writing console apps using win32api ?

Couple of comments Michael.

I appreciate your problem with just one phone. Same with me, sign up for about
$9.95 a month, but when you start downloading updates - suddenly you find your
plastic has a charge for $68  for the additional time ! It's you choice of
course, and subject to availability. I went direct cable connection - $40 per
month FIXED and I can spend 40 hours a day whistling around the Net if I so
choose. I don't do that, confining myself to topics 'COBOL'. It's another
approach.

Surprised where you listed Visual Basic as an 'alien' along with the others. Is
it really foreign to what you are used to do doing with basic BASIC ?

For Pete - SDK came as a freebie with Net Express, (can't remember, may have
been a freebie with VISOC). The other side of the coin, as you have mentioned,
you got CRYSTAL as a freebie with Fujitsu. My actual use of the SDK ? Looked to
find how to handle ENTER key instead of TAB key for dialogs. Three examples, all
in C, and as Michael says, you've then got to unravel the problem back into
COBOL syntax.

He's not messaging at the moment - but Ken Mullins in Atlanta, is certainly
using Win API calls from Net Express - although, as I recall, he avoids Win
printer calls, opting instead for PC_PRINT.

Jimmy

Quote:

> I am one of the most vocal people I know re praising the way MS has
> implemented the Windows API. There are functions and functions to do damn
> near anything, quickly and without bugs and the reference documentation is
> well done. The MSDN includes a lot of code samples, but those are not of
> much use to me, as they are all written in Microsoft C++, Microsoft Visual
> BASIC, Microsoft FoxPro and  Microsoft whatever. (And all the Internet
> examples assume you use Microsoft Internet Explorer as your browser).

> MCM



Thu, 09 Oct 2003 01:55:26 GMT  
 Anyone writing console apps using win32api ?
Micheal, if we are going to develop something like that, why not develope a
Cobol "system" object" that is capable of interfacing to multiple OS's.
There is nothing to stop a DeFacto public domain Cobol standard interface.
I'd be happy to work on it.


Quote:


> > On Fri, 20 Apr 2001 15:33:22 GMT, "Michael Mattias"

> > >Hmm, might it be possible to do this?

> > >2. Use the LoadLibrary and GetProcAddress APIs to make the function
> > >available to your process. Return GetProcAddress into a COBOL
> > >PROCEDURE-POINTER datatype. Yes, you can use USER32.DLL, or GDI or
KERNEL
> or
> > >any other system DLL with LoadLibrary.

> > You said the magic word.  Procedure pointers are not yet supported in
> > Fujitsu COBOL - and that was the point of my original reply.

> Well, phooey. Oh, well,maybe someone got an idea from it anyway.

> Can Fujitsu call a DLL which might be called like this?

> 01  Target-Address PIC 9(9) USAGE BINARY.
> 01  LibName          PIC X(20)
> 01  ProcName        PIC X(30)

> CALL "CallByAddress"  USING   TargetAddress, parm-1, parm-2, parm-3....

> or maybe something like

> CALL "CallWin32API" using  LibName, ProcName, parm1, parm2..parm3.....

> If FJ can do this, it might be fun for me to write a DLL which serves as a
> "service layer" and my DLL would actually do the API call and return the
> results.

> I'd need to think a little bit more about the parameter list and how to
> handle this, but I KNOW my compiler (PowerBASIC PB/DLL) can handle the
> call-by-address and variable number of parameters part of it, and I know I
> can handle the coding to pass and return the values. (Of course, I tend to
> believe I can code anything).

> If anyone is interested in this, post here for now. If there's enough
> interest, I can take the discussion off-line.

> --
> Michael C. Mattias
> Tal Systems
> Racine WI

> If Fujitsu can call a standard Windows DLL, I could write a DLL to handle
to
> registry access.  It could be



Thu, 09 Oct 2003 01:58:04 GMT  
 Anyone writing console apps using win32api ?

Quote:

>  and I can spend 40 hours a day whistling

What's your secret ?  I could use more hours in each day too.


Thu, 09 Oct 2003 15:36:55 GMT  
 
 [ 42 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Creating Console Apps using Win32Forth

2. Testing DOS Console app using TCL/Expect

3. Win32 Console app -> Win32 app: help wanted

4. DVF - hot to switch from a console app to a dll app

5. Anyone Using First Impr, and Distributing App?

6. Can a Clipper app read/write using an MSSQL erver 6.5

7. Writing Microsoft Windows apps using Modula-2

8. GetComputerName using Win32API

9. Displaying gif or jpg files using Win32API?

10. Get Version of DLL with Win32API using NetExpress

11. Shutting down windows using win32api

12. Reboot Windows XP using Python's win32api

 

 
Powered by phpBB® Forum Software