win32api oldefoxx

[oldefoxx]

As I've mentioned elsewhere, I am in the process of moving to PureBasic after HotBasic
bombed out on me. I try to go easy on what I say about HotBasic because it may still
suit some people, and it is not that hard to learn. But I would not say that it is worth
what is being charged for it. I also left PowerBasic behind years ago for other, although
somewhat similar reasons, though PowerBasic does measure up better.

Enough said on that. I wrote a routine in PureBasic that failed to deliver on the right
number of directories and files found per drive. To try and find the cause, I had to first
try and determine what the correct count should be. So I went to the Windows APIs to
find a solution.

Now with the Windows APIs, there are several approaches, but they all boil down to
making use of the function APIs named FindFirstFile(), FindNextFile() FindClose() and
if you want to do it right, GetLastError(). There is lots of sample code out there, but
if you search the web, most of it involves C or C++. You have to visit specific forums
to find it in other languages.

But here is the thing: My PC is configured with Ubuntu as the host Operating System, on
which I run Oracle's VirtualBox, and under VirtualBox I have Windows 2000 installed as a
client. Win2k may be obsolete elsewhere, but I am fine with it. I just can't use Crome or
the latest versions of FireFox with it. But I can run those on the host side.

To make best use of my hard drives, I have them all connected to the Win2k client via
VirtualBox as shared folders. With the extended add-ins that Oracle provides, everything
works as it should. Except in one respect, which I just discovered: Using FindFirstFile()
and FindNextFile() in the APIs, all folders and files on the Linux drives are reported to be
folders. You have no files to look at. But Windows 2000 itself has no problem making the
distinction. In fact, at the Command Line you can use DIR and be able to recognize both
files and folders on those drives.

Well, that's not what I had in mind. Turns out I am going to have to use the following
command string to get the job done, folder by folder. Unfortunately, I can't show you the
string in PureBasic, because I don't know the equivalence to a SHELL command in PureBAsic.

SHELL "cmd /c dir "+path+" /l /-c > tmpfile.tmp"

Now when you use the above command (or the PureBasic equivalent), you don't get all the
folders and files. No, the associated attribut bits don't permit this. You have to shell multiple
times to get everything, and you will end up with duplicates that have to be weeded out
later, probably after an array sort is used to bunch all the identical ones together. Afte the
above statement, you really need to follow with these:

SHELL "cmd /c dir "+path+" /ad /l /-c >> tmpfile.tmp"
SHELL "cmd /c dir "+path+" /as /l /-c >> tmpfile.tmp"
SHELL "cmd /c dir "+path+" /ah /l /-c >> tmpfile.tmp"
SHELL "cmd /c dir "+path+" /ar /l /-c >> tmpfile.tmp"

That gets the directories, the system files, the hidden files, and the read only files as well.

If you include the " /s " switch as well, you will automatically tell the DIR instruction to range
through all the subdirecrories (subfolders) as well, but that ends up with a monster file that
you then have to wade through. With the added four DIR searches, that is a lot of sorting
to get through before you begin processing the results, so I recommend only doing one
directory (or folder) at a time. You can pick out the directory entries because they will say
"<DIR>" and the files leave that space blank.

Okay, so having paid my dues with some tips of my own, what is the PureBasic equivalent to
other Basics' SHELL statement?

[MachineCode]

what is the PureBasic equivalent to other Basics' SHELL statement?

RunProgram()

[vmars316]

As I've mentioned elsewhere, I am in the process of moving to PureBasic after HotBasic

Greetings,
Could you provide a sample of same program
written in both PB and HotBasic?
Thanks...Vernon

[vmars316]

I,
If you do not know : Just a link ...
http://programmingforfun.net/pw5e/pw5e.htm
Bye

That's a bogus link for me.
Is there another address?
Thanks...vm

[oldefoxx]

As I've mentioned elsewhere, I am in the process of moving to PureBasic after HotBasic

Greetings,
Could you provide a sample of same program
written in both PB and HotBasic?
Thanks...Vernon

Actually I haven't done it in HotBasic yet. I did it in PowerBasic, which is somewhat easier than doing it in HotBasic. I
first used a recursive routine that I downloaded from the http://www.powerbasic.com forums (they list several) and tried it,
then I adapted the code and moved from recursive to using a dirs and a files string to hold results. This was an effort
to verify that FindFirstFile() and FindNextFile() were themselves the cause of not identifying folders and files on the
Linux drives properly, I'm going write a process based on the Command Line DIR instruction which is producing the
right results. That will be in PowerBasic since I am already halfway there. Then in PureBasic, now that I know to use
the RunProgram() function in place of SHELL. After that back to PureBasic and do it there. As to HotBasic, I may do
that as well, but I am not real sure. Reason? HotBasic has several flaws that can trip you up unexpectedly if you try
doing something that wasn't really planned for in the way the compiler was set up. If this happens, one of three things
can result:
(1) It compiles successfully, but you get a GPF when you try to run the program. Anybody's guess where the problem is.

(2) It won't compile, but the error reported is bogus. Finding the real problem involves looking at code somewhere
above the point where the problem is reported. It will be a real problem, just nothing like what the error says.

(3) It won't compile. but the error is really bogus this time. It messes up on some multi-statement lines, and you
may have to forego those and rewrite your code so that you only have one statement per line to get around this

(4) It has a few inherant flaws that I won't go into. About seven or 8 in all, that I am aware of now. You can get
around them, but I don't feel you should have to, not for the price. Some involve the built-in inline assembler and
that would not bother many. One sticky one involves operator precedence, so your math can get screwed up. It
has an odd way of handling passed parameters to subs and functions that has a few good sides as well as some
bad ones, plus a way to deal with variables inside subs and functions once you exit, but what good this is has
proven hard to judge. All constants, variables, sub and function names are case sensitive, and the language has
grabbed some letter combinations, such as S, DC, CC, and Port for itself. Every language has keywords that you
can only use in certain ways, but I felt this was stretching it. Dang, I did end up talking about it. Well, I just
don't like to make a claim and not back it up with some facts.

In my previous post, I had SHELL "cmd /c dir "+path+" /ad /l /-c >> tmpfile.tmp" as one of the statements. This
one may not be required, but I included it just to be sure. Here is something to be aware of: You can take such
statements and drop the SHELL and the "cmd /c " part, plus drop the double quotes and replace the +path+ with
whatever drive (C:\) or folder (c:\Program Files\) that you want the search to start from and see now it works.
the results go into tmpfile.tmp in the current directory. But, just because it does it at the command line does
not mean you get exactly those results in tmpfile.tmp when you run the program. How you word a command line
statement when you call it from another program can be extremely critical. If you get something to work at the
command line, you may have to dinker with it in the program in order to get the same results.

Something I thought to add. DIR is one of the built-in Command features that goes with DOS and Windows. You
figure out how to use DIR to do what you want to do, you could write a standalone program that takes over for
the built-in DIR statement, but it can't have the same name, unless you call it using dir.exe. Better yet, pick an
alternate name for your program, maybe something like what Linux and Unix use, which is cat, short for catalog.

[vmars316]

As I've mentioned elsewhere, I am in the process of moving to PureBasic after HotBasic

Thanks for the run down.
Personally, I love Hotbasic, because it is not verbose.
Very quick to code. Easy to debug.
I tend to debug as I code. Baby steps, kind of.
And I code for my own needs.
Then as I see, this could be useful for others.
I give away source and programs here:
http://www.vmars316.com/

For ShellExec, I use
ShellExecuteA 0,0,@ShellExec$,0,0,1
and stuff whatever the command I want into ShellExec$ .

I have never used Linux.
But I would like to use someBASIC on MAC.
That's why I am poking around with other Basics.
IWBasic is looking awfully good too.

Happy Trails!...Vernon

[oldefoxx]

Vernon, I know you from the HotBasic Groups (which I got thrown out of, by the way).
Yes, HotBasic is very alluring because it simplifies coding. I'd have stuck with it if Jim
was not so adament that it is sheer perfection, and paid attention to running down
the problems that haunt it. Some of those problems were known years ago, but he
either ignores them, is blind to them, or feels they just reflect his design choices.

When add always takes precedence over subtract, and multiply always takes precedence
over divide, you are ignoring what Standard Notation has to say on the subject. To then
turn it around and offer equal precedence, where multiply, divide, add, and subtract
all have the same precedence with each other, only confounds the problem. Then to
confound the problem, you can switch between these two states throughout your code,
so you can end up with no consistency at all.

Oh, what does Standard Notation say on the matter of multiply verses divide and add
verses subtract? that multiply and divide have equal precedence with each other, so you
perform these two operations on a left to right basis. Add and subtract have a lower
precedence that they share, so when it is a choice between these two, it is again a left
to right order process. The way you change precedence is by including parens at key
points. With standard notation, the expressions i-j+4 equals i+4-j. With Jim's approach,
He effectively includes parens so that you find that i-(j+4) does not equal (i+4)-j. Note
that the parens, which are not really there, merely are included to reflect that he will
always do the add before the subtract, which is not the way it is suppose to work.

Ron S. describes HotBasic as a blend of classing BASIC with a GUI and some OOP capability
added in. I think that is fairly apt. And with two compilers, priced separately, you can end
up doing Windows and Linux. There is more to relearn with PureBasic, and it's hard being
able to relate to a BASIC keyword and not find the same one used or cross-referenced when
you need it, but persistence and the forums here mean you should strike on an answer
sooner or later. See? I've gotten two to my question of what to use with PureBasic in place
of SHELL. One answer is RunProgram() and your answer was ShellExecuteA 0,0,@ShellExec$,0,0,1

I don't know exactly what you mean about HotBasic being easy to debug. True, there is a free
and capable debugger for it, but it is a standalone approach, not as good as one that works from
the IDE. If you mean the source code is easy enough to follow, that is true, provided that the
person writing the code keeps it that way. PureBasic's IDE works to enhance the code by putting
keywords in a suitable case, colorizing them, and following rules of indentation. HotBasic also
colorizes, but too much color just makes things harder to read, at least for me.

[idle]

Try to stay on topic please Learning more about the Win32® API.

[Josh]

Try to stay on topic please Learning more about the Win32® API.

Not only here. Sorry for the comment, but Oldefoxx is spamming all the board with his bizarre postings. In the meantime, his favorite topics (PowerBasic, ASM, Console) are widespreaded in the most the forums.

Are you genuinely seeking help and advice from our friendly community style forum oldefoxx, or are you really a forum troll?

In the meantime i'm confident, it's only a troll.

[oldefoxx]

Okay. Let's take it that you recognize that some people may have need
to read the directory structure of drives that are not set up for either
DOS or Windows. Can this be done with APIs? Not using FindFirstFile()
and using FindNextFile() according to my experience. How about in
just writing a 32-bit program and running it on a 64-bit system? Here
is what I ran across on that subject:

If you are writing a 32-bit application to list all the files in a directory
and the application may be run on a 64-bit computer, you should call the
Wow64DisableWow64FsRedirectionfunction before calling FindFirstFile and
call Wow64RevertWow64FsRedirection after the last call to FindNextFile.
For more information, see File System Redirector.

If the path points to a symbolic link, the WIN32_FIND_DATA buffer contains
information about the symbolic link, not the target.

One of the threads about moving to 64-bit was that if you don't call the, well,
let's just call them the "Wow64" redirectors, is that when you think you are
checking the contents of \WinNT\System32\ subfolder, you will actually be
checking the wrong folder. Here is what I've found on that:

WoW64 (Windows 32-bit on Windows 64-bit) is a subsystem of the
Windows operating system that is capable of running 32-bit applications and
is included on all 64-bit versions of Windows—including Windows XP
Professional x64 Edition, IA-64 and x64 versions of Windows Server 2003,
as well as 64-bit versions of Windows Vista, Windows Server 2008, and
Windows 7. In Windows Server 2008 R2 Server Core, it is an optional
component. WoW64 is designed to take care of many of the differences
between 32-bit Windows and 64-bit Windows, particularly involving structural
changes to Windows itself.

And this is from another thread:

Probably more than you are looking for, but:

Everything You Need To Know To Start Programming 64-Bit Windows Systems
http://msdn.microsoft.com/en-us/magazine/cc300794.aspx

Basically you have two (2) system folders, one for legacy 32bit
dlls/coding [sysWoW64 - "W"indows "o"n "W"indows"64"], the other for
64bit [system32 - old carry-over].

If all this helps suggest that there is a widening departure between older forms of
Windows and what is coming now or will follow later, I would say that the impression
is exactly right. At some point you may even have to decide if you are going to stay
part of the 32-bit windows scene, or if you are going to go 64-bit instead. Note that
as 64-bit PCs can run 32-bit Windows, you might plan to move on in hardware and
stay a ways back in software.

I mentioned this before, but Windows APIs are covered in detail in the Windows SDKs,
which are free to download. But there are multiple sets of APIs and supporting SDKs,
which goes further to show that Windows is diverging over time. Many of the APIs
can be found in every set, but others are either being dropped, or new APIs are being
added. For a developer, this means you may have to write any API-based programs to
a specific audience or group. Does this mean you should not use APIs? That would be
even more foolish. If an API does what you need, and your system provides it for your
use, then the smart thing would be to make use of it. Here is some information on the
Windows SDKs.

Microsoft Windows SDK, Platform SDK, and .NET Framework SDK are software
development kits from Microsoft that contain header files, libraries, samples,
documentation and tools required to develop applications for Microsoft Windows and
.NET Framework.[1]

The difference between these three SDKs lies in their area of specialization: Platform SDK
specializes in developing applications for Windows 2000, XP and Windows Server 2003.
.NET Framework SDK is dedicated to developing applications for .NET Framework 1.1 and
.NET Framework 2.0. Windows SDK is the successor of the two and supports developing
applications for Windows XP, Windows Vista, Windows 7, Windows Server 2008, .NET
Framework 3.0, .NET Framework 3.5, and .NET Framework 4.0.[2] It contains extensive
documentation and around 800 samples.

I want to forewarn you that the SDKs documentation and examples are centered around the
use of C++, not some form of BASIC. Because of this, some programmers just switch to C++
as a way of having an easier time of it, and others try to master the skill of taking the
examples written in C++ code and mapping it into a different language of their choosing.

The APIs have been so mapped by others over time, and are available from various sources,
generally for free, but you have to search them out. Also note that what are called APIs are
actually libraries or collections of external functions that are part of the set of Windows'
DLLs. There are other DLLs that may also provide functions that would be of use to you, but
getting those DLLs and learning about their contents goes way beyond what can be covered here.

Here is a way to help yourself. Yes, you want information on the Win32API, but you want it in a
specific form: An INClude file that might be easier to work with than a C++ version. How to find
that? Well, most BASICs use .INC as an extension for include files, so you could specify this
instead: "win32api.inc". That will turn up some leads. I also tried "win32api.pbi" to see if
anyone had made a version specific to PureBasic, but this turned up nothing. You can try again,
and who knows, one may pop up any day now.

[oldefoxx]

I see posts concerning my "bazaar" and "troll"-like conduct. So let me try to answer
your questions. No, according to my wife, I am not a troll, whatever that means. I
may be many things, but a troll is not one of them.

My career, which lasted most of 34 years, was mostly as an independent technical
support engineer. Being independent also meant working and thinking on your own.
Consequently, my thoughts don't run down the same channels as other people's do.

I'm here to learn, but I am also here to share what I can. I've been told to start a
blog or something. People write blogs, but nobody reads them. If you are going to
share, you have to have a thread that brings people to you.

I'm off the topics of other languages. Just something that kept pushing to come out,
so I had to vent it. When sharing, you sometimes have to talk about what does not
work as well as what works.

So far, PureBasic is looking good. Just wish there were an easier way to map from
what I learned over the years to what it entails to pick it up. Lots to it, so it takes
awhile to try and get through it when trying to go step by step.

Speaking of recursion (and this is from earlier postings), a recursive process is any
sub or function that calls itself. Think of a dog chasing its own tail in a circle. There
has to be some limit to how many times you go around that circle. This has to be
built into the process. When a sub or function becomes recursive in design, it has
the potential to perform much faster than similar code that just stretches out. The
down side could be that you eat up available stack space, because the stack is where
the steps back have to be stored. Keep going in the circle, and you run out of steps.

There was a discussion once years ago that maybe recursion ran the greater risk of
running out of stack space if you used it to range through the directories on a drive,
going further and further in by layers. Turns out that this is not much of a problem
or risk when mapping the folders and files on hard drives, because the deepest folder
layers are often only four or five layers deep. There is a finite limit on how many
characters can be squeezed into a path\filename.ext, which also serves to limit the
levels involved. The recursive method was about twice as fast as other methods,
so it is the approach you see most commonly advocated in example code.

In case you didn't know, if using Long File Names (LFNs), spaces and a few other
characters can be incorporated in the LFN if the path]finename.exe is bracketed by
double quotes, like "c:\Program Files\Common Files\Microsoft Shared\". Now each
of these folder levels also has a shortened version of the name that is equally
unique, and sometimes, when handling files, you find that only by using the shortened
version can you manage the file within the character length limit. If you have the
LFN, then you can use one of the APIs to get the shortened version back. Or if you
have the shortened version, you can use a different API call to get the LFN back.
Actually, both the long and short names are embedded in the WIN32_FIND_DATA
structure. In fact this structure is very important in managing files because it has
all sorts of information about the current FindFirstFile() or FindNextFile() in it.
Let's take a look at it:

Code: Select all

TYPE WIN32_FIND_DATA
  dwFileAttributes AS DWORD
  ftCreationTime AS FILETIME
  ftLastAccessTime AS FILETIME
  ftLastWriteTime AS FILETIME
  nFileSizeHigh AS DWORD
  nFileSizeLow AS DWORD
  dwReserved0 AS DWORD
  dwReserved1 AS DWORD
  cFileName AS ASCIIZ * %MAX_PATH
  cAlternateFileName AS ASCIIZ * 14
END TYPE

It starts of with the file's attributes, such as whether it is read only, a system
file, an hidden file, or it is flagged as having been archived. Then you have
three FILETIMEs for it, when it was created, when it was last accessed, and
when i was last written to. Usually, the most important FILETIME is when
it was last written to. Then you have two DWORDS to hold a full QUAD of the
size of the file. They are not stored in the right sequence to read them up as
a quad, so you have to maneuver a bit to get the right results by reading up
each DWORD separately. The cFileName is the Long File Name with the full
path attached to it. The cAlternateFileName is the short name version
without the path being attached. In other words, this type structure pretty
much has it all together for you. Now this information came right out of the
Win32API.INC that PowerBasic put together for their users, and it should give
you a feel for what getting into the APIs can be like.

[Danilo]

@oldefoxx: What is your question?

You explain basic things most programmers already know. Nobody was asking for it, so why do you tell stories
about things everybody knows? Talking to yourself, so you remember things you just learned?
Why not use your time to learn PureBasic?
Just ask your questions in 'Coding Questions'. Short, right to the point, with code that shows the problem, if possible.

Starting a blog isn't a bad idea, even if nobody is reading it. If it can help yourself to remember things, it would be good for you, not?

[MachineCode]

Vernon, I know you from the HotBasic Groups (which I got thrown out of, by the way).

I can see why! No offense, but what is all this off-topic babble you've hijacked into this thread? Stop it, please.

[vmars316]

When I was pursuing Win32 API info for a project,
I ran across visual FoxPro,
which I think is now not being developed anymore.
But there are still lots of foxPro diehards,
and lots of Win32-API foxPro API examples out there.

I just googled for "visual foxpro win32 Api examples"
"About 236,000 results (0.28 seconds)"

...Vernon

[oldefoxx]

I like the note about FoxPro Win32API. I would never have considered it. As to what
"Everybody knows", that's just you speaking. I don't know everything you know, just
like you don't know everything I know. I sure the heck can't be sure that everybody
knows what either of us know. But I'm inclined to share. That's what I've always
done, and guess I will keep on doing.

Take recursion, a topic I spoke on yesterday. Not everybody understands that, and I
don't think my example of a dog chasing its own tail was the best example. Think of it
more like a ladder or a staircase. You can go up or down it, and then when you are
ready, you can come back the other way. That's recursive. Not like a single esculator
that either goes up or down, but not both, or the brass pole in a firehouse where you
can only slide down. A recursive sub or function is one that calls itself when need be,
and can exit all back the way down to the point where it was first called when it is
completely done with the job in hand.