Custom Query (80 matches)

I don't have the debug version and so I'm just going to send this info and hope you find it useful.

Just installed 0.6.21659 (2011-06-27) and removed from config.sys (but files still on drive) ver 050327

My system is SMP, running 2 cpu's under eCS v1.24.

Kernel is build

Signature: @#IBM:14.104a#@_SMP IBM OS/2 Kernel

Vendor: IBM Revision: 14.104 File Version: 14.104 Description: _SMP IBM OS/2 Kernel

Previously running odin 050327 with winrar v3.0 (it ran fine and if I start it with \050327\pe it still runs fine). Winrar is the only app I have tried. It crashes under this new version of odin. The program starts, draws a windows and then crashs (with no hangs).

From popuplog:

06-28-2011 23:43:13 SYS3175 PID 0077 TID 0001 Slot 00d5

D:\APPS\ODIN\SYSTEM32\PE.EXE

c0000005

1cf8cedd P1=00000001 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX EAX=00000000 EBX=000f0000 ECX=5dbf4050 EDX=000f0000 ESI=00000000 EDI=00000000 DS=0053 DSACC=f0f3 DSLIM=ffffffff ES=0053 ESACC=f0f3 ESLIM=ffffffff FS=0537 FSACC=00f3 FSLIM=00000fff GS=0000 GSACC= GSLIM= CS:EIP=005b:1cf8cedd CSACC=f0df CSLIM=ffffffff SS:ESP=0053:00129b58 SSACC=f0f3 SSLIM=ffffffff EBP=00129bdc FLG=00010256

KERNEL32.DLL 0001:0001cedd

I can provide the procdump file if you wish, it's 1.6MB file. My apologies for not having the info you need from a debug version.

Rgds, Jon

Odin does not use TZ to define the Windows time zone (GetTimeZoneInformation?() API). Instead, it uses WGSS for the initial TimeZoneInformation? setting but WGSS returns GMT on freshly installed systems.

We need to derive TimeZoneInformation? from TZ each time when KERNEL32.DLL gets loaded and update it if differs. This will make sure that if the user changes his system time zone setting (via the Clock Synchronization setting or manually in config.sys), it will get picked up by Odin.

I have a guess that if we build a Win32 application from sources, we don't need to switch the FS register from the OS/2 TIB to the Win32 TIB and back. This is a continuation of the idea from #82 (which already eliminates the need to do this FS switch in order for SEH to work).

If we can get rid of this switch completely, we will get save ourselves from having a milky-way of function wrappers used to call OS/2 functions from the Win32 context (and the other way around). Getting rid of something is always good as it reduces chaos.