Discussion:
Problem with NetFileDir in XP
(too old to reply)
Paul E. Schoen
2010-04-02 19:26:44 UTC
Permalink
In my posts on 3/12/2010 I found a fix for the problem in Vista where the
NetFileDir PDOXUSRS.NET was not allowed to be written in the root C:\, so I
set the Session.NetFileDir to the default Application Data folder, and all
seemed fine. But two customers had problems when they installed on their XP
machines, and the error message was:

Network initialization failed
Path not found
File: C:\Documents and Settings\All U\pdoxusrs.net

Directory C:\Documents and Settings\All U

I added a debug line which showed the NetFileDir and it was:

C:\Documents And Settings\All Users\Application Data\Ortmaster

Just for grins and giggles I created the directory that was not found, and
it fixed the problem. The PDOXUSRS.NET file appeared in that folder. It
worked OK in Vista, where the path was:

C:\ProgramData\Ortmaster

The path name seems to be truncated somewhere. If I use the BDE
Administrator in the Control Panel, the
Configuration\Drivers\Native\Paradox\Net Dir is still C:\. I copied the full
path into the Net Dir and applied it. Then I renamed the "All U" folder to
"All". The problem remained with the same error message.

I am setting the Net Dir upon the FormCreate event of the form which has the
database components. I am not explicitly creating a Session, but I am using
the default Session which is created automatically. So I suspect that the
NetDir is needed prior to the form creation. Yet the error message does not
appear until I open the form with the database components, and by that time
the form has been created so the Net Dir should be set. I can fix this with
ugly workarounds, such as creating the rogue directory in the install
script, but I want to do it right.

Would it be possible to trap the error in a try..except construct on form
show? But then what could I do other than set the Net Dir to what is already
was set to on FormCreate?

BTW, this is D4 Pro, and I'm not sure I installed the latest updates for it
on this computer (which has Vista Business OS). My main XP machine died a
few weeks ago and I've been doing my development on my new machine. I'm sure
I had the same basic program running when I was using XP, although I think
that was before I needed to change the default NetDir. Perhaps I can detect
XP vs Vista and only change it for Vista? Is there an easy way to detect the
OS and make the change only for Vista (and probably also Win7). Any ideas
will be appreciated.

Thanks!

Paul
Jamie
2010-04-02 22:28:00 UTC
Permalink
Post by Paul E. Schoen
In my posts on 3/12/2010 I found a fix for the problem in Vista where
the NetFileDir PDOXUSRS.NET was not allowed to be written in the root
C:\, so I set the Session.NetFileDir to the default Application Data
folder, and all seemed fine. But two customers had problems when they
Network initialization failed
Path not found
File: C:\Documents and Settings\All U\pdoxusrs.net
Directory C:\Documents and Settings\All U
C:\Documents And Settings\All Users\Application Data\Ortmaster
Just for grins and giggles I created the directory that was not found,
and it fixed the problem. The PDOXUSRS.NET file appeared in that folder.
C:\ProgramData\Ortmaster
The path name seems to be truncated somewhere. If I use the BDE
Administrator in the Control Panel, the
Configuration\Drivers\Native\Paradox\Net Dir is still C:\. I copied the
full path into the Net Dir and applied it. Then I renamed the "All U"
folder to "All". The problem remained with the same error message.
I am setting the Net Dir upon the FormCreate event of the form which has
the database components. I am not explicitly creating a Session, but I
am using the default Session which is created automatically. So I
suspect that the NetDir is needed prior to the form creation. Yet the
error message does not appear until I open the form with the database
components, and by that time the form has been created so the Net Dir
should be set. I can fix this with ugly workarounds, such as creating
the rogue directory in the install script, but I want to do it right.
Would it be possible to trap the error in a try..except construct on
form show? But then what could I do other than set the Net Dir to what
is already was set to on FormCreate?
BTW, this is D4 Pro, and I'm not sure I installed the latest updates for
it on this computer (which has Vista Business OS). My main XP machine
died a few weeks ago and I've been doing my development on my new
machine. I'm sure I had the same basic program running when I was using
XP, although I think that was before I needed to change the default
NetDir. Perhaps I can detect XP vs Vista and only change it for Vista?
Is there an easy way to detect the OS and make the change only for Vista
(and probably also Win7). Any ideas will be appreciated.
GetVersionEx ?

Also, you may want to use "ShGetSpecialFolderLocation" instead of
hard coding the users document folder path.

Jamie..
Paul E. Schoen
2010-04-02 22:51:27 UTC
Permalink
Post by Jamie
Post by Paul E. Schoen
In my posts on 3/12/2010 I found a fix for the problem in Vista where the
NetFileDir PDOXUSRS.NET was not allowed to be written in the root C:\, so
I set the Session.NetFileDir to the default Application Data folder, and
all seemed fine. But two customers had problems when they installed on
Network initialization failed
Path not found
File: C:\Documents and Settings\All U\pdoxusrs.net
Directory C:\Documents and Settings\All U
C:\Documents And Settings\All Users\Application Data\Ortmaster
Just for grins and giggles I created the directory that was not found,
and it fixed the problem. The PDOXUSRS.NET file appeared in that folder.
C:\ProgramData\Ortmaster
The path name seems to be truncated somewhere. If I use the BDE
Administrator in the Control Panel, the
Configuration\Drivers\Native\Paradox\Net Dir is still C:\. I copied the
full path into the Net Dir and applied it. Then I renamed the "All U"
folder to "All". The problem remained with the same error message.
I am setting the Net Dir upon the FormCreate event of the form which has
the database components. I am not explicitly creating a Session, but I am
using the default Session which is created automatically. So I suspect
that the NetDir is needed prior to the form creation. Yet the error
message does not appear until I open the form with the database
components, and by that time the form has been created so the Net Dir
should be set. I can fix this with ugly workarounds, such as creating the
rogue directory in the install script, but I want to do it right.
Would it be possible to trap the error in a try..except construct on form
show? But then what could I do other than set the Net Dir to what is
already was set to on FormCreate?
BTW, this is D4 Pro, and I'm not sure I installed the latest updates for
it on this computer (which has Vista Business OS). My main XP machine
died a few weeks ago and I've been doing my development on my new
machine. I'm sure I had the same basic program running when I was using
XP, although I think that was before I needed to change the default
NetDir. Perhaps I can detect XP vs Vista and only change it for Vista?
Is there an easy way to detect the OS and make the change only for Vista
(and probably also Win7). Any ideas will be appreciated.
GetVersionEx ?
Also, you may want to use "ShGetSpecialFolderLocation" instead of hard
coding the users document folder path.
OK, here's what I did:

procedure TfmReclData.FormCreate(Sender: TObject);
const WIN2000 = 5.0;
WINXP = 5.1;
WINVISTA = 6.0;
WIN7 = 6.1;
var VersionInfo: OSVERSIONINFO;
Version: Real;
begin
VersionInfo.dwOSVersionInfoSize := sizeof (OSVERSIONINFO);
getVersionEx( VersionInfo );
Version := VersionInfo.dwMajorVersion + VersionInfo.dwMinorVersion/10;
if (Version >= WINVISTA) and (Session <> nil) then
Session.NetFileDir := ProgramDataFolder;
if Session <> nil then begin
fmDebug.AddDebugItem( 'FormCreate: OS Version: ' + Format( '%3.1f',
[Version] );
fmDebug.AddDebugItem( 'FormCreate: NetFileDir: ' +
Session.NetFileDir ); end;

It seems to work OK on XP and Vista. I'm also doing the following upon
creating the main form:

ProgramFolder := GetSystemFolder(CSIDL_PROGRAM_FILES);
If not SetCurrentDir(ProgramFolder + '\Ortmaster') then begin
CreateDir(ProgramFolder + '\Ortmaster');
SetCurrentDir(ProgramFolder + '\Ortmaster');
end;
ProgramFolder := GetCurrentDir;
fmDebug.AddDebugItem('ProgFolder: '+ProgramFolder);

ProgramDataFolder := GetSystemFolder(CSIDL_COMMON_APPDATA);
If not SetCurrentDir(ProgramDataFolder + '\Ortmaster') then begin
CreateDir(ProgramDataFolder + '\Ortmaster');
SetCurrentDir(ProgramDataFolder + '\Ortmaster');
end;
ProgramDataFolder := GetCurrentDir;
fmDebug.AddDebugItem('DataFolder: '+ ProgramDataFolder);

At least now I feel confident it will work on at least most XP and Vista
systems. I'll worry about Win7 another day. Thanks,

Paul
a***@aol.com
2010-04-03 07:01:57 UTC
Permalink
On 2 Apr, 20:26, "Paul E. Schoen" <***@pstech-inc.com> wrote:
<snip>
Post by Paul E. Schoen
Is there an easy way to detect the
OS and make the change only for Vista (and probably also Win7). Any ideas
will be appreciated.
I detect OS with a separate function as follows - you would need
extend it to add Win 7. Makes for clearer code.

TOperatingSystem = (osUnknown, osWin95, osWin98, osWin98SE, osWinME,
osWinNT, osWin2K, osWinXP, osWinVista);

function WinOpSys : TOperatingSystem;
var
// all these for code clarity
{Win98SE,} // if desired
Win95, Win98, WinME, WinNT, Win2K, WinXP, WinVista : boolean;
begin
Win95 := (Win32MajorVersion = 4) and (Win32MinorVersion = 0)
and (Win32Platform = VER_PLATFORM_WIN32_WINDOWS);
Win98 := (Win32MajorVersion = 4) and (Win32MinorVersion = 10)
and (Win32Platform = VER_PLATFORM_WIN32_WINDOWS);
WinME := (Win32MajorVersion = 4) and (Win32MinorVersion = 90)
and (Win32Platform = VER_PLATFORM_WIN32_WINDOWS);
WinNT := (Win32MajorVersion = 4) and (Win32MinorVersion = 0)
and (Win32Platform = VER_PLATFORM_WIN32_NT);
WinXP := (Win32MajorVersion = 5) and (Win32MinorVersion = 1)
and (Win32Platform = VER_PLATFORM_WIN32_NT);
Win2K := (Win32MajorVersion = 5) and (Win32MinorVersion = 0)
and (Win32Platform = VER_PLATFORM_WIN32_NT);
WinVista := (Win32MajorVersion = 6)
and (Win32Platform = VER_PLATFORM_WIN32_NT);
Result := osUnknown; // default
if Win95 then
Result := osWin95
else
if Win98 then
{if Win32CSDVersion[1] := 'A' then // use if desired
Result := osWin98SE
else }
Result := osWin98
else
if WinME then
Result := osWinME
else
if WinNT then
Result := osWinNT
else
if WinXP then
Result := osWinXP
else
if Win2k then
Result := osWin2K
else
if WinVista then
Result := osWinVista;
{end; if Win2k else}
{end; if WinXP else}
{end; if WinNT else}
{end; if WinME else}
{end; if Win98 else}
{end; if Win95 else}
end;

Alan Lloyd
Paul E. Schoen
2010-04-03 18:07:26 UTC
Permalink
Post by a***@aol.com
<snip>
Post by Paul E. Schoen
Is there an easy way to detect the
OS and make the change only for Vista (and probably also Win7). Any ideas
will be appreciated.
I detect OS with a separate function as follows - you would need
extend it to add Win 7. Makes for clearer code.
TOperatingSystem = (osUnknown, osWin95, osWin98, osWin98SE, osWinME,
osWinNT, osWin2K, osWinXP, osWinVista);
function WinOpSys : TOperatingSystem;
var
// all these for code clarity
{Win98SE,} // if desired
Win95, Win98, WinME, WinNT, Win2K, WinXP, WinVista : boolean;
begin
Win95 := (Win32MajorVersion = 4) and (Win32MinorVersion = 0)
and (Win32Platform = VER_PLATFORM_WIN32_WINDOWS);
Win98 := (Win32MajorVersion = 4) and (Win32MinorVersion = 10)
and (Win32Platform = VER_PLATFORM_WIN32_WINDOWS);
WinME := (Win32MajorVersion = 4) and (Win32MinorVersion = 90)
and (Win32Platform = VER_PLATFORM_WIN32_WINDOWS);
WinNT := (Win32MajorVersion = 4) and (Win32MinorVersion = 0)
and (Win32Platform = VER_PLATFORM_WIN32_NT);
WinXP := (Win32MajorVersion = 5) and (Win32MinorVersion = 1)
and (Win32Platform = VER_PLATFORM_WIN32_NT);
Win2K := (Win32MajorVersion = 5) and (Win32MinorVersion = 0)
and (Win32Platform = VER_PLATFORM_WIN32_NT);
WinVista := (Win32MajorVersion = 6)
and (Win32Platform = VER_PLATFORM_WIN32_NT);
Result := osUnknown; // default
if Win95 then
Result := osWin95
else
if Win98 then
{if Win32CSDVersion[1] := 'A' then // use if desired
Result := osWin98SE
else }
Result := osWin98
else
if WinME then
Result := osWinME
else
if WinNT then
Result := osWinNT
else
if WinXP then
Result := osWinXP
else
if Win2k then
Result := osWin2K
else
if WinVista then
Result := osWinVista;
{end; if Win2k else}
{end; if WinXP else}
{end; if WinNT else}
{end; if WinME else}
{end; if Win98 else}
{end; if Win95 else}
end;
That seems to be rather cumbersome, although the use of the system variables
Win32MajorVersion and Win32MinorVersion is simpler than using the
getVersionEx() function. I used the following:

var Version: Real;

Version := Win32MajorVersion + Win32MinorVersion/10;

and it worked OK. But if the MinorVersion can be 10 or 90 as you show for
Win98 or WinME, my conversion will fail. Those versions were not shown in
the reference I found in a MSDN reference, which was for only the currently
supported versions:
http://msdn.microsoft.com/en-us/library/ms724834(VS.85).aspx

But on further search I found this comprehensive listing:
http://www.msigeek.com/442/windows-os-version-numbers

Windows 1.0 1.04
Windows 2.0 2.11
Windows 3.0 3
Windows NT 3.1 3.10.528
Windows for Workgroups 3.11 3.11
Windows NT Workstation 3.5 3.5.807
Windows NT Workstation 3.51 3.51.1057
Windows 95 4.0.950
Windows NT Workstation 4.0 4.0.1381
Windows 98 4.1.1998
Windows 98 Second Edition 4.1.2222
Windows Me 4.90.3000
Windows 2000 Professional 5.0.2195
Windows XP 5.1.2600
Windows Vista 6.0.6000
Windows 7 6.1.7600

Here is another approach for Delphi, but it does not include Vista or Win7:
http://www.delphidabbler.com/articles?article=23&part=2

And here are more from http://www.codeproject.com/KB/system/osversion.aspx:

+------------+------------+-------+-------+---------+
| Version | PlatformId | Major | Minor | Release |
+------------+------------+-------+-------+---------+
| Win32s | 0 | ? | ? | |
| Win95 | 1 | 4 | 0 | 1995 08 |
| Win98 | 1 | 4 | 10 | 1998 06 |
| WinME | 1 | 4 | 90 | 2000 09 |
| WinNT351 | 2 | 3 | 51 | 1995 04 |
| WinNT4 | 2 | 4 | 0 | 1996 07 |
| Win2000 | 2 | 5 | 0 | 2000 02 |
| WinXP | 2 | 5 | 1 | 2001 10 |
| Win2003 | 2 | 5 | 2 | 2003 04 |
| WinXPx64 | 2 | 5 | 2 | 2003 03 |
| WinCE | 3 | ? | ? | |
| Vista | 2 | 6 | 0 | 2007 01 |
| Win2008 | 2 | 6 | 0 | 2008 02 |
| Win2008R2 | 2 | 6 | 1 | 2009 10 |
| Win7 | 2 | 6 | 1 | 2009 10 |
+------------+------------+-------+-------+---------+

It appears that the safest and simplest way may be to use the following
code:

var sMajor,sMinor,sVersion: String;
fVersion: Real;
sMajor := IntToStr(Win32MajorVersion);
sMinor := IntToStr(Win32MinorVersion);
sVersion := sMajor + '.' + sMinor;
fVersion := StrToFloat(sVersion);

The advantage of a floating point version is that it makes comparisons
simpler, and it (or the string equivalent) provides a good way to display
the OS version to the user, although most people would not recognize 5.1 as
XP or 6.0 as Vista. And BTW, why in heck is Win7 6.1 and not 7.0?

But beyond recognizing the OS, I am still wondering why the NetDir does not
seem to work properly in XP.

Paul
a***@aol.com
2010-04-04 07:59:04 UTC
Permalink
<snip>
Post by Paul E. Schoen
That seems to be rather cumbersome, although the use of the system variables
Win32MajorVersion and Win32MinorVersion is simpler than using the
getVersionEx() function.
<snip>

I'm a believer in putting utility functions somewhere, then my app
code appears simpler & clearer. I think I'd go to either Win32???
Versions _or_ a full evaluation as my function.

I'm always wary of comparing float values for equality, or am I being
super careful. String & integer comparisons you know where you are,
but floats are slippery customers <g>.

But the above are (perhaps) idiosyncrasies of coding style.

Thanks for the full versions list, though.

Alan Lloyd

Loading...