File not found

[Jackson]

I wrote a vocabulary flash-card type program in MS Visual
Basic 6.0 on a 98SE computer. The program ran fine on
95/98/ME/2000. For it to run on XP, I had to move a copy of
the winmm.dll from one directory to another, because MS had
put the file in a different place, but after that it ran
find on XP too.

Now a friend, who runs the same program in another town, has
switched to Vista and when he tries to run the flash-card
program he gets a "File not found" error. It would really
have been nice if MS had told him WHICH file could not be
found. He copied winmm.dll into the same folder as the
program, as needed in XP, but that did not help.

Is there an error log or some such thing that might have the
name of the missing file? I don't have a clue on what to
tell my friend, and I don't have access to Vista to test it
myself.

Any suggestions appreciated.

 

[AlexB]

The error log is easy to get.

Control Panel>>System And Maintenance>>Administrative Tools>>Event Viewer

Copy the events on the top (latest) marked "Error."

Winmm.dll is a sound support dll. it handles SndRec32.exe requests. You may
be in somewhat deeper "trouble" than you realize.

SndRec32.exe for sure and I believe (Not a firm assumption, though)
winmm.dll is kind of a relic of XP in Vista. It may be (again, not a firm
conviction) a sort of an orphan file. Sound recording in Vista is now
veniewed thru .wma not .wav files and I believe it is because .wav files are
considered wasteful.

When I try to run SndRec32.exe in Vista (not that I really need it but as a
legacy from XP) I get in trouble. Vista is asking me if I want to replace
the default sound recorder which I always refuse.

It may or may not have a bearing on what you are up to. This is just FYI,
however, if this dll is not actively used it may not be registered and here
you really got a problem. You have to register it (if it is not). And of
course you do it with regsrv32.exe, right?

I would be kind of reluctant to register that file in a rash. Vista does not
quite like messing up with its environment. I strongly suggest taking a
restore point in case you need to roll it back.

I guess what your friend is experiencing is "normal" albeit sad. Software
gets old. You most likely wrote you VB6 application on .NET 1.1. Now it is a
different world.

Another problem might be that you wrote it on a different platform
altogether. I believe it is Windows Mobil. It is embedded environment. As a
rule you can hardly run this stuff on desktops although I may be wrong on
this one. If your friend got desktop Vista and is not running your file in
emulation mode, your problems may be only beginning to show up.

 

[Jackson]

Thanks, Alex

 

[DanS]

It may or may not have a bearing on what you are up to. This is just
FYI, however, if this dll is not actively used it may not be
registered and here you really got a problem. You have to register it
(if it is not). And of course you do it with regsrv32.exe, right?

ALL DLL's DO NOT need to be registered, only ActiveX/COM DLL's. 'Standard'
Windows DLL's do not. As long as the standard DLL is in the application
directory, or placed somewhere within the PATH, it should be accessible.

ActiveX EXE's that expose a COM interface need to be registered as well if
you want to use whatever COM interfaces it exports.

I would be kind of reluctant to register that file in a rash. Vista
does not quite like messing up with its environment. I strongly
suggest taking a restore point in case you need to roll it back.

Sorry Phalyx, registration of winmm.dll is not possible. If you try, it
will tell you 'This file can't be registered'.

Now, here's another clue, you can have it, as you need to get a lot of
them, the reported error was 'File Not Found'. IF winmm.dll WAS an ActiveX
DLL, which it's not, the error would have been 'ActiveX can not create
object.', not 'File Not Found'.

I guess what your friend is experiencing is "normal" albeit sad.
Software gets old. You most likely wrote you VB6 application on .NET
1.1. Now it is a different world.

(Confusion has set in in your mind again....) VB6 s/w is written in VB6.
VB6 is a COM language and is not related to .Net at all. There is no way to
write a VB application on .Net version anything.anything.

That's like saying....I've got this C++ program I wrote in Delphi.

Does Win9x, in which that app ran fine, even support .Net ?

Some developer you are....it probably took you a week to write the 'Hello
World' program.

Another problem might be that you wrote it on a different platform
altogether. I believe it is Windows Mobil. It is embedded environment.
As a rule you can hardly run this stuff on desktops although I may be
wrong on this one. If your friend got desktop Vista and is not running
your file in emulation mode, your problems may be only beginning to
show up.

You are off the deep end. Why the hell would something that has worked in
9x/Me/2000/XP suddenly be written on a different platform ? What the hell
has been eating away at your brain ?

Incidentally, I don't know about WindowsMobile, but I do know for a fact
that you can use WindowsXP Embedded to create a super-sleek install in
which you can pick and choose each and every device to support, each and
every service to set up, etc., that can be used on a desktop. Sort of like
a super XPlite.

I think the last time I read something that was so convoluted, bizarre, and
senseless that wasn't from you, it was from a long-time glue-sniffer who's
brain was literally eaten away by long-term use of inhalents.

STOP POSTING YOUR WHACKED OUT THEORIES AND HALF-BAKED NONSENSE EXPLANATIONS
OF THINGS YOU HAVE IMAGINED PEOPLE HAVE ASKED ABOUT.

 

[DanS]

Thanks, Alex

LOL...its funny, by your snipping, I can see that you are pointing out the
only useful piece of AlexB's post. Everything else was basically worthless
and nearly unintelligble.

Anywho.......was the error you got before moving the winmm.dll the same ?
'File not found' ? Did the Event Viewer have any useful info it it ?

Do you have a (txt, ini, etc.) file that holds the vocabulary info and the
program reads it ? If so, is there error-handling associated with opening
the file ? Where is the file stored ? In the programs directory ?

It would be kind of tough to troubleshoot this w/o having Vista.....

 

[AlexB]

DanS, your idiocy has been demonstrated so many times that you do not need
to do it again.

You are trying to confirm your position as a village idiot and a clown
relentlessly.

You, skunk, should realize that he did not write a DRIVER!!!!!.

He wrote an application.

Well, it is hopeless. You have a monumental self-esteem. Nothing can hurt
you even when people around you openly laughing. You think they are laughing
at a dog next to you.

You found it unintelligible because you did not understand what WE were
talking about. He IS a DEVELOPER. He did understand me in every word. Also
you are a low life pisher on high voltage power lines with not even an
associate degree thinking that water never conducts electricity.

I did not solve his problem for God's sake. I just gave him a piece of
technical talk to perhaps serve as a springboard.

It is cold outside. Most skunks are in their burrows. What happened to you
my dear? Are you without a home or what?

 

[AlexB]

ALL DLL's DO NOT need to be registered, only ActiveX/COM DLL's. 'Standard'
Windows DLL's do not. As long as the standard DLL is in the application
directory, or placed somewhere within the PATH, it should be accessible.

ActiveX EXE's that expose a COM interface need to be registered as well if
you want to use whatever COM interfaces it exports.

You are correct. I realized it a few minutes after posting. It was somewhat
iresponsible.

registration of winmm.dll is not possible. If you try, it
will tell you 'This file can't be registered'.

This is also correct. I am actually using it in my Vistas without any
registration, precisely the way he did: copying this file in the directory
in question.

Now, here's another clue, you can have it, as you need to get a lot of
them, the reported error was 'File Not Found'. IF winmm.dll WAS an ActiveX
DLL, which it's not, the error would have been 'ActiveX can not create
object.', not 'File Not Found'.

I am not sure about it. I do not play with ActivX and I clearly said that
before. I don't know.

(Confusion has set in in your mind again....) VB6 s/w is written in VB6.
VB6 is a COM language and is not related to .Net at all. There is no way
to
write a VB application on .Net version anything.anything.

Where in the world did you get the few correct crumbs of information to get
so off track on this one.

VB6 is a part of Windows Mobil infrastructure. It does .NET Mobil 1.1 and I
am not sure about the latest upgrades. I do know that winmm.dll is a part of
..NET.

That's like saying....I've got this C++ program I wrote in Delphi.

Does Win9x, in which that app ran fine, even support .Net ?

Yes, that version of Windows Mobil does support .NET.

And this is what I advise you to do:

STOP POSTING YOUR WHACKED OUT THEORIES AND HALF-BAKED NONSENSE EXPLANATIONS
OF THINGS YOU HAVE IMAGINED PEOPLE HAVE ASKED ABOUT.

 

[DanS]

You are correct.

Of course.

I realized it a few minutes after posting. It was
somewhat iresponsible.

Not irresponsible, just wrong.

This is also correct.

Again...of course.

I am actually using it in my Vistas without any
registration, precisely the way he did: copying this file in the
directory in question.


I am not sure about it. I do not play with ActivX and I clearly said
that before. I don't know.


Where in the world did you get the few correct crumbs of information
to get so off track on this one.

Off track on what ? I give no 'crumbs' of information that I know are not
accurate, unlike you.

VB6 is a part of Windows Mobil infrastructure. It does .NET Mobil 1.1
and I am not sure about the latest upgrades. I do know that winmm.dll
is a part of .NET.

What you 'know' is wrong. Winmm.dll is *NOT* part of .Net. It is a base
windows DLL that had been included in Win9x versions as well.....way
before .Not was released.

While I don't know for sure, I'd assume that VB6 is NOT a part of Windows
Mobile. The VB6 *runtime* library, msvbvm60.dll, may be included with
WindowsMobile, but the VB6 programming environment and compiler are
certainly not, which is what this application was built with.

 

[DanS]

You found it unintelligible because you did not understand what WE
were talking about.

Wrong, I cojmpletely understood everything.

He IS a DEVELOPER. He did understand me in every
word.

And I'm sure he understood that what you were saying did not apply to his
situation.

Also you are a low life pisher on high voltage power lines with
not even an associate degree thinking that water never conducts
electricity.

You are right. I don't have an associated degree. But you are wrong about
the electricity. I *know* that water, in and by itself, does not conduct
electricty, and that is all I ever stated. *Never* have I stated that
water NEVER conducts electricity.

I did not solve his problem for God's sake. I just gave him a piece of
technical talk to perhaps serve as a springboard.

.......a springboard to the dark abyss that is your world ?

It is cold outside. Most skunks are in their burrows. What happened to
you my dear? Are you without a home or what?

Again an attempted insult. Think about it......

1. It is cold outside.

Yes it is.

2. Most skunks are in their burrows.
Trying to call me a 'skunk'.
A skunk's 'burrow' is his/her home, where they live.
Ergo, I should be in my home.

Well DUH!!! I am in my home. You attempt at a clever insult has failed,
just like most of your attempts at helping people.

 

[DanS]

DanS, your idiocy has been demonstrated so many times that you do not
need to do it again.

You are trying to confirm your position as a village idiot and a clown
relentlessly.

You, skunk, should realize that he did not write a DRIVER!!!!!.

(Note: If you are going to reply to this, it would be nice if you did so
with inline posting. If you do it that way, when I see your reply, I know
that it is referencing the paragraph/sentence/phrase directly above it.
If you see something you want to comment on, start a new line, enter your
comment, and keep reading for the next reply you want to make. Also, AND
THIS IS VERY IMPORTANT, *BEFORE* you hit send. scroll back to the top and
reread what you are replying to, then read your reply that had been typed
directly below it and see if it makes any sense at all as a reply to what
was left unclipped that you were replying to. If you post like this, you
(may) be able to (better) understand and remember what you and (what you
think) others have said.)


Answer me this....why did you write what is above ?

I never said anything about a driver anywhere. As a matter of fact, in
the entire thread, the only time driver was mentioned is in your text
above.

How can *I* be the idiot when it is you that keeps _imagining_ things,
and then calling me an idiot for being wrong in the little fantasy world
you live in your head.

Looks to me like someone else is the *true* idiot here.

Nearly everyone else in this entire group most likely see's you as the
clown you are. You just do not have good communication skills, nor from
what I've seen, good technical knowledge. Period. I'm sure that most
don't even bother to read you post's, other than for pure shock-value of
what you will try to pass off as your expertise & know-how.

You don't see this because most of (whom I would call) the true
professionals that are here day in and day out, and DO have the technical
knowledge to help out people, are far above wasting their time on
exchangeing with you. Frankly, you are so close-minded that noone will
ever be able to get thru to you and help you see yourself as others see
you, and what I'm doing here is just wasting my time.

Haven't you noticed that the only ones that continue dialog with you are
posters that have just entered this newsgroup for the first time and are
looking for help. These people haven't seen you in action, and at first,
since they are not very technologically inclined, you wow them with what
appears to be super-technical jargon, but in reality, the jargon is all
over the place, confusing, using wrong terms, and may not even apply to
the subject at hand. They continue talking to hoping to start
understanding what you are saying by answering *your* questions (the
questions as THEY understood (or didn't really) understand) and then you
add more layers of confusion in the mix. Then, they just give up on your
advise, and you don't here from them again.

Unfortunately, I'm the kind of person that if *I* think your full of
sh*t, I'll tell you your full of sh*t.

Damn TPS again, you should really have that checked out before we read
about you in the papers.

 

[AlexB]

I haven't done any Windows Mobil stuff. My knowledge is limited. However, I
know a few things.

He did not state this but is is quite possible he wrote his app without
winmm.dll. Winmm.dll is not a part of Windows Mobil.

I worked wit this stuff and I know what I am talking about. All methods that
are packed in winmm.dll were originally developed for Windows Mobil
exclusively. They include API calls to connect to audio devices, open them,
perform recording, format wav files, control parameters thru numerous
structures like WAVEHDR, etc.

That class also include methods to play wav files.

The whole set of methods was COM implemented and only accessible via such
calls.

Anyone interested can take a look at this MS site:

Recording and Playing Sound with the Waveform Audio Interface
http://msdn2.microsoft.com/en-us/library/aa446573.aspx#waveinout_topic_006
The site says that, hold your breath, DanS:

Applies to:
Microsoft® .NET Compact Framework 1.0

This is not the end of the story.
Last summer I decided that I needed my own audio recording API and I copied
the source code from that site. I converted it to .NET by using winmm.dll.
Nobody at MS MSDN sites could tell me where those methods were. I wanted to
write an API to look thru ALL dlls to make a database of all methods to find
out. Nobody even was sure that such methods exist in .NET environment.
People were saying I should look in kernel32.dll and user32.dll. There was
nothing there.

I found the methods very soon be accident.

It became clear to me that although I debugged the code, it kept giving me a
bunch of errors. Looking back I think it was because I did not use a digital
mic. I wanted to take another stab at that project which is still in my
folder but some events made this idea obsolete.

My XP crashed and I could not access Internet any longer. I had to switch to
Vista. A monumental struggle began. I do not play games. My stuff is 2
orders of magnitude more complex and I write it myself. I spend moths
adjusting everything and in the process I realized that Vista forestalled my
plans. I found a simple API in Vista that worked much better than
sndrec32.exe in XP and the name of that API is SoundRecorder.exe. It works
very well but it outputs wma files. I did have an archive of old wav files.
This is why I occasionally use sndrec32.exe but I know that wav's may be on
the way out. For my purposes (I record simple messages my applications
"articulate" to warn me of complicated developments it is a perfect
solution.

winmm.dll is a concession MS developers made to a wider community (.NET
developers). It is a .NET dll.

You have no idea what you are talking about.

When they made the winmm.dll all those methods were debugged and worked for
yours in Windows Mobil (embedded) environment) with .NET Mobil 1.0. they
just packed the code in a different way.

You are sill and IDIOT, DanS despite your desperate efforts to look better.

The OP, a developer did a very competent job, he debugged his app, converted
it to another platform (he perhaps does not recall the true sequence of
events) and now he is facing a new challenge. Challenges will never end.

 

[DanS]

I haven't done any Windows Mobil stuff. My knowledge is limited.
However, I know a few things.

He did not state this but is is quite possible he wrote his app
without winmm.dll. Winmm.dll is not a part of Windows Mobil.

I worked wit this stuff and I know what I am talking about.

No, you don't.

All
methods that are packed in winmm.dll were originally developed for
Windows Mobil exclusively.

No, they are not. winmm.dll has been aruond since Windows95 at least, way
before Windows Mobile was here.

Here's a Google search showing a search on: winmm.dll "windows 95"

http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla:en-
US%3Aofficial&hs=pxG&q=winmm.dll+%22windows95&btnG=Search

They include API calls to connect to audio
devices, open them, perform recording, format wav files, control
parameters thru numerous structures like WAVEHDR, etc.

That class also include methods to play wav files.

The whole set of methods was COM implemented and only accessible via
such calls.

Anyone interested can take a look at this MS site:

Recording and Playing Sound with the Waveform Audio Interface
http://msdn2.microsoft.com/en-us/library/aa446573.aspx#waveinout_topic_
006 The site says that, hold your breath, DanS:

Applies to:
Microsoft® .NET Compact Framework 1.0

Duh. The page is about programming multimedia in .Not v1.0.

You have no clue as to what .Not is do you ?

Here, let me explain it to you (just like everything else needs to be
explained to you).

The .Net framework is nothing more than another runtime library set that
can be used directly from several different programming languages.
Basically what it does it provide a singular API that is available in
whatever language you are using.

It is supposed to make coding things easier, because much of the low-level
stuff is encapsulated in the framework DLL's exported function calls.

The 'framework' is also another layer of processing that the PC needs to
do. When you call an exported function in a .Net application, the framework
in turn calls whatever API's it needs out of the windows system DLL's, some
of which are winmm.dll, user32.dll, shell32.dll, t do whatever the call
does.

Let's see, if using C++ to write a program it could be a very manual thing
to do 'x'.

'x' may require calling 6 API calls to get the job done.

A .Net framework may have a single call in it to do 'x'. Within the
framework, and what you don't see, is that the .Net library takes your
singular call, and then calls all the required API of the win32 API
contained within the system DLLs for you.

If you disassemble the framework DLL's, you will see what calls it exports,
and you will see that it IMPORTS standard windows system DLL calls to use.

So why bother doing .Net if I can use all of the calls

This is not the end of the story.

It never is with you.

Last summer I decided that I needed my own audio recording API and I
copied the source code from that site. I converted it to .NET by using
winmm.dll.

From that page you posted. It already IS .Net.

Nobody at MS MSDN sites could tell me where those methods
were. I wanted to write an API

you mean a program ?

to look thru ALL dlls to make a
database of all methods to find out. Nobody even was sure that such
methods exist in .NET environment. People were saying I should look in
kernel32.dll and user32.dll. There was nothing there.

No, because they are all within winmm.dll which can be used from a number
of languages. Any that can call windows API's, like VBcom, Delphi, VC++,
BC++.

I found the methods very soon be accident.

It became clear to me that although I debugged the code, it kept
giving me a bunch of errors.

Then you didn't debug it then.

Looking back I think it was because I did
not use a digital mic.

I think the mic had nothing to do with it.

I wanted to take another stab at that project
which is still in my folder but some events made this idea obsolete.

My XP crashed and I could not access Internet any longer. I had to
switch to Vista.

You haven't been able to explain this either.

A monumental struggle began.

In your mind ?

I do not play games. My
stuff is 2 orders of magnitude more complex and I write it myself.
I
spend moths adjusting everything and in the process I realized that
Vista forestalled my plans. I found a simple API in Vista that worked
much better than sndrec32.exe in XP and the name of that API is
SoundRecorder.exe.

you mean program dipsh*t.

It works very well but it outputs wma files. I did
have an archive of old wav files. This is why I occasionally use
sndrec32.exe but I know that wav's may be on the way out. For my
purposes (I record simple messages my applications "articulate" to
warn me of complicated developments it is a perfect solution.

winmm.dll is a concession MS developers made to a wider community
(.NET developers). It is a .NET dll.

You have no idea what you are talking about.

It's pretty obvious that it is you that doesn't know what you are talking
about.

You know what I'm going to do, I'm going to re-post this in another
programming newsgroup, one with very intelligent and experienced
programmers in it. Maybe they can shed some light on this subject, or at
the very least, get a giant chuckle out of your rantings.

When they made the winmm.dll all those methods were debugged and
worked for yours in Windows Mobil (embedded) environment) with .NET
Mobil 1.0. they just packed the code in a different way.

You are sill and IDIOT, DanS despite your desperate efforts to look
better.

The OP, a developer did a very competent job, he debugged his app,
converted it to another platform (he perhaps does not recall the true
sequence of events) and now he is facing a new challenge. Challenges
will never end.

No, he didn't convert it to another platform. Windows Mobile was never
mentioned. You claimed winmm.dll was part of Windows Mobile, therefore he
had to at some point converted it to Windows Mobile. Or, more precisely,
YOU converted it to Windows Mobile in your mind.

The challenge you face daily will never end.

 

[AlexB]

I never said anything about a driver anywhere. As a matter of fact, in

the entire thread, the only time driver was mentioned is in your text
above.

Sure you did not. Or you did and did not notice?

Gale Robbins (Adelaid Adams) sings in a movie that you of course never saw:
"He is dumb as an ox." She is referring to her lover, Harry. You are dumb as
an ox, DanS.

Now I am going to tell you why I raised the driver option. Listen:

You mentioned something, completely mindlessly, to show your "knowhow:" the
term .inf. Inf refers to a file that complements the drivers, not ordinary
applications. That was completely idiotic on your part.

I know you are trying but you still have a long way in front of you.

You should not have pissed on the power lines so much when you were young.

 

[AlexB]

You have no clue as to what ***.Not*** is do you ?

You are right I have no clue.

 

[DanS]

You are right I have no clue.

That is the first step to recover.

 

[DanS]

Sure you did not. Or you did and did not notice?

Now I am going to tell you why I raised the driver option. Listen:

You mentioned something, completely mindlessly, to show your
"knowhow:" the term .inf. Inf refers to a file that complements the
drivers, not ordinary applications. That was completely idiotic on
your part.

No, I never said anything about an INF.

Show me !!! Where in this thread did I mention an INF file !!!!!

Wait !

Here's what I said...

'Do you have a (txt, ini, etc.) file that holds the vocabulary info and the
program reads it ?'

That is I N I !!!!!!!

Learn how to read.

 

[tms]

winmm.dll is not the issue here. The missing file is not a dll. If
the dll of a function declaration were missing or misspelled in the
declaration, the generated error would give the file name specified
in the declaration (unless your error trapping is circumventing
this). Since the error message doesn't provide a file name, it's most
likely one of your data files you're opening for input (or one of your
ini files) that the app can't find... if you're opening a file named
"foo" for input and the file doesn't exist (and you're not trapping
the error), VB6 will give you the generic "File not found" error, sans
file name.

Solution: trap the error in your file handling code and handle
accordingly. When dealing with files, most errors are not necessarily
"errors", but "information" that you can use in code (in this case,
it's telling you whatever input file doesn't exist).

 

[Jackson]

winmm.dll is not the issue here. The missing file is not a dll. If
the dll of a function declaration were missing or misspelled in the
declaration, the generated error would give the file name specified
in the declaration (unless your error trapping is circumventing
this). Since the error message doesn't provide a file name, it's most
likely one of your data files you're opening for input (or one of your
ini files) that the app can't find... if you're opening a file named
"foo" for input and the file doesn't exist (and you're not trapping
the error), VB6 will give you the generic "File not found" error, sans
file name.

Solution: trap the error in your file handling code and handle
accordingly. When dealing with files, most errors are not necessarily
"errors", but "information" that you can use in code (in this case,
it's telling you whatever input file doesn't exist).

Thanks, that's good information. I don't see how it can be
the case here tho; the program runs just fine in XP, but in
the Vista machine (according to what I'm told - I don't
actually have a Vista machine myself) the system reports
"file not found".

In the program, the user must choose from a list of data
files after running the exe program. My friend can't get to
that part because the exe dosen't run. I suspect that MS
has moved a dll to where it's no longer on the machine's
path, or does not install core routines needed to run VB 6.0
where Vista can find them.

If you have Vista, and would like to try the program on your
machine, you can download it here:

<<http://www.geocities.com/jackdins/>>

Could the problem be that the program tries to play a WAV
file? Another poster said something about Vista using a
different format for sounds? In XP and earlier, if the WAV
file is missing the program simply ignores it and continues.

Thanks for the reply.

 

[tms]

To me, it looks like the app is attempting to open an input file that
isn't there (where the app expects it to be). UAC is far more strict
on Vista.

I assume you used a setup utility to create a setup package to install
your app. Most setup programs elevate (or at least have the option to
elevate) to admin priveleges for the setup process since "Program
Files" and other directories are not writeable for non-admin users.
If the setup process is installing a datafile to the user APPDATA
CSIDL, the file actually gets installed into the admin's user APPDATA
path (if the setup was elevated) and not to the one for the original
user that launched the setup (if different). If that's the case, then
a standard user cannot access those files since they aren't "there"
for that user. A common practice is to install such datafiles either
to the COMMON_APPDATA CSIDL or to the app's path (remember, "Program
Files" isn't "writeable" for common priveleged users), and then have
the app copy those "default" datafiles over to the user's APPDATA
CSIDL on first run (i.e. when the files don't exist in the user's app
data path) as a standard user.

Of course, I probably don't need to mention that an app shouldn't have
hardcoded paths for the special shell folders, but should be retrieved
via their associated CSIDLs because those paths can have varying names
on different PCs.

 

[Jackson]

To me, it looks like the app is attempting to open an input file that
isn't there (where the app expects it to be). UAC is far more strict
on Vista.

I assume you used a setup utility to create a setup package to install
your app. Most setup programs elevate (or at least have the option to
elevate) to admin priveleges for the setup process since "Program
Files" and other directories are not writeable for non-admin users.
If the setup process is installing a datafile to the user APPDATA
CSIDL, the file actually gets installed into the admin's user APPDATA
path (if the setup was elevated) and not to the one for the original
user that launched the setup (if different). If that's the case, then
a standard user cannot access those files since they aren't "there"
for that user. A common practice is to install such datafiles either
to the COMMON_APPDATA CSIDL or to the app's path (remember, "Program
Files" isn't "writeable" for common priveleged users), and then have
the app copy those "default" datafiles over to the user's APPDATA
CSIDL on first run (i.e. when the files don't exist in the user's app
data path) as a standard user.

/.../
I don't want to impose on you by beating a dead horse, but
the program (Vocabulous) is simple and self-contained within
a directory named by the user. It does not write to the
register nor to any outside file such as INI, etc. If the
user deletes the directory he has put it in, all trace of it
is gone.

This is no big thing, since I give the program away and
don't have any special reason to want it run on Vista, since
I don't have Vista. I was just trying to help my friend
figure out why it won't run (or maybe even load). Anyway,
he has a 98SE machine if he really feels the need to
practice his vocabulary lesson.

Thanks so much for your insight and patience.

Jack