When calling the function SocketFD_SET on some Win98 machines (not on
all!), the application fails with the error message 'internal data
structures corrupted'. The functions are called before (SocketNew,
SocketSetBlockingMode and SocketFDSetNew) return without any error.

     nSocket := SocketNew(, , , @nError)
     SocketSetBlockingMode(nSocket, .F.)

     nFDSet := SocketFDSetNew(@nError)
     SocketFD_SET(nSocket, nFDSet)   -> break with error 'internal
                                        data structures corrupted'

Any ideas?

Regards,
Siegmar

Siegmar,

> Any ideas?

Maybe different Windows 98 (SE) versions
with different (newer) socket implementations?

Regards,

Alex Blankendaal

Hallo Alex,

Is EBpos een Xbase++ applicatie? Het ziet er in ieder geval gelikt uit!

M.vr.gr,
Jack Duijf


"Alex Blankendaal" <alex@eb.nl> schreef in bericht
news:3f7c346b$1@asgcom.alaska-software.com...
> Siegmar,
>
> > Any ideas?
>
> Maybe different Windows 98 (SE) versions
> with different (newer) socket implementations?
>
> Regards,
>
> Alex Blankendaal
>
>
>

Alex,

> Maybe different Windows 98 (SE) versions
> with different (newer) socket implementations?

I have made more investigations in the meantime concerning this matter
with the following results:

1.) All Win95/98 machines show this error except my own dev-pc (Win98)
2.) All Win98 machines have the same version like mine
3.) On all Win2k/NT pc's the application is running without any error

I was playing around with the insubordinate Win98 machines and found out
that when I set the environment paths (INCLUDE, XPPRESOURCE, LIB, PATH)
in the same way like on my pc - though they are not at all exist there -
the error appears no more.

Isn't that strange?


Regards,
Siegmar

Siegmar,

> I was playing around with the insubordinate Win98 machines and found out
> that when I set the environment paths (INCLUDE, XPPRESOURCE, LIB, PATH)
> in the same way like on my pc - though they are not at all exist there -
> the error appears no more.
> 
> Isn't that strange?

No!  Obviously there is something required (probably a dll) which cannot be
found until you add these settings.

Get rid of INCLUDE etc. and just keep the PATH settings, and you'll
probably find that the problem is still resolved (provong that it was
something on the PATH).

After that, you can amend the PATH, slowly removing each directory to test
it, and keep any directory which causes an error.  This should help you
narrow down where the problem is.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Circular definition: see definition, circular.

Hi Phil,

thank's for your reply. First of all - perhaps it's important for
understanding - the application resides on a network drive and is
started through a DOS batch file. Before calling therein the app, the
current PATH setting is supplemented by the path for runtime dll's
(e.g.:  path %path%;n:\dll).

This approach works perfectly for all other Xbase apps. Now, in this
special error case, I have found out that adding the path settings from
my dev pc in the start batch solves the problem - but I don't no why!


> Get rid of INCLUDE etc. and just keep the PATH settings, and you'll
> probably find that the problem is still resolved (provong that it was
> something on the PATH).

When removing only one of the path settings INCLUDE, XPPRESOURCE or LIB
I get the error!

> After that, you can amend the PATH, slowly removing each directory to test
> it, and keep any directory which causes an error.  This should help you
> narrow down where the problem is.

You can believe me that I have already tried this in and out. The
application runs only without an error when I use my path settings.
What I'am wondering about is the fact, that many of these paths point at
local Alaska directories which are not available on the Win98 machines.

For example: when removing C:\ALASKA\XPPW32\BIN or C:\ALASKA\XPPW32\LIB
from the PATH setting I will get the error. I can't imagine why these
paths are necessary for a correct working though they never can be found
on the workstations.


Regards,
Siegmar