I need some advice from SOMEONE who has gotten Hughton Mifflin's eReference program to work it Vista. They are not yet supporting the program in a Vista environment but they report that it works for some users.
It installed OK for me and word look up works. The audio pronunciation of a word fails with error "eRef 41 Run-time error 7 Out of Memory". I did try increasing the virtual memory, that did not help. If you have had success with this program in Vista please advise me
Thanks
Frank CHave you tried running it in Compatibility Mode?

Are you using 32-bit or 64-bit Vista?Thank you for the reply.
Yes, I did try compatibility mode. I used Win XP sp2 It did not work.
I previously had the subject program operating on a Win XP sp2 machine.
I no longer have that computer.
My Vista is Ultimate 64 bit.64Bit is probably the barrier...Sorry for the late reply...

64-bit is most likely the issue...

If there are any 16-bit components in the program, then it'll choke.

If there are any 32-bit DRIVERS in the program, it'll choke.

I'm going to take a guess and say that the program's audio feature uses some type of 32-bit device driver.

Although 64-bit Vista can run 32-bit apps, it can't run 32-bit drivers.

The other guess I would have is that the program may not like file paths with parentheses ( ) in them. By default, 32-bit programs install in C:\Program Files (x86).

Try this:

1) Uninstall the program.
2) When asked to choose where you want the program to install, change the part "Program Files (x86)" to "PROGRA~2" (that's the DOS 8.3 version of Program Files (x86)).
Thanks for the reply,
I don't see the folder PROGRA~2 on my system. I did a "C" disk search. Do I need to create it?
Thanks
Frank CI think you misunderstood me.

There is no such THING as a "Progra~2" folder.

Once upon a time, before Microsoft Windows, there was an operating system called MS-DOS.

All you could do was type commands. There was no mouse, no color, no pretty pictures, no nothing.

MS-DOS also had the limitation that every file and folder could only have up to 8 characters and the file extension could only be up to 3 characters. No spaces or special characters were allowed either.

In other words:

winword.exe would be valid in DOS.

some really big torrent file name.torrent would NOT be (too many letters, spaces, and the file extension is more than 8 characters).

...then came Windows 95, which began allowing longer file names.

Since DOS couldn't understand the longer file names in Windows 95, abbreviations were created.

So something like Huge Effing File Name.txt in Windows would be Hugeef~1.txt. There is no actual Hugeef~1.txt file. It's just that DOS is stupid and can't understand file names longer than that.

Same with "Program Files" and "Program Files (x86)." DOS sees those as "Progra~1" and "Progra~2" respectively.

The reason I mentioned this is because the program you're working with sounds pretty old, has no clue what to do with a file or folder name that has parentheses, and the DOS 8.3 (8.3 meaning 8 characters.3 letters) format might be a way to work around the program's stupidity.

So no, you will not see a Progra~2 directory. You'll have to type that in yourself.Sounds to me, like this program was written in a earlier version of Visual Basic (VB1,2,3, or 4 16-bit). I gather this from the Run-time error code #7. It boggles me why they wouldn't simply recompile with a 32-bit version; unless they are using a number of VBX controls...

In either case, allow me to add to killerb255's post regarding long filenames.

As he said, DOS only supported 8.3 filenames, -well, technically, the filenames could be any length, but had to have a "\" at LEAST every 8 characters (or more if an extension is used on a directory - but that is merely a optimistic way of perceiving the limitation.

With the introduction of windows95, MS slightly modified the FAT implementation; at the basic level- the filesystem still only supports 8.3 filenames. Windows 95 (and 98, and all later implementations while using a FAT filesystem) cleverly circumvents this by actually creating more directory entries that HOLD the files name.

So you ask, "why don't they show up in a DOS DIR?" well, when windows95 creates these directory entries, it sets some FUNKY set of flags, (I think it's Volume and system and hidden, which makes no sense). SO DOS just ignores them.

The original Files Entry is, Of course, the shortfilename itself, IE PROGRA~1 or ~2 or whatnot. Examining the disk structure reveals that there are probably 2 or three actual entries to store the entire "Program Files" string itself- Spaces are allowed in a fat filename, (the confusion about this detail results from the command prompt's, and DOS programs basic parsing of command-lines).

NTFS preserves the short file-names for these files as well; for the most part this is a backwards compatibility feature mainly intended for those scenarios where a NT server has a shared NTFS drive accessible from a DOS client. Short-name generation can be disabled, but this can cause issues with older applications.

with FAT32 MS extended filenames to be 255 characters in length. (if memory serves). It still needed to generate short-filenames for the same reasons as NTFS, with the addition that windows 95OSRB and 98 are far more likely to be used for running older applications that don't natively understand the new file name formats.


Even newer applications had issues with long filenames- programs merely RECOMPILED for the 32-bit environment were still using the same filename validation code as their 16-bit counterparts, resulting in a slew of programs that, although 32-bit applications, were no more "LFN aware" then their 16-bit brothers.


Quote

Same with "Program Files" and "Program Files (x86)." DOS sees those as "Progra~1" and "Progra~2" respectively.

I forgot to mention that I'm running Vista Home Premium 32-bit