Hi,

Launching A-Shell in a Windows Server 2003 trigger the following error:

ashw32.exe - entry point not found
----------------------------------------
The procedure entry point InitializeCriticalSectionEx could not be located in the dynamic link library KERNEL32.dll

Note that A-Shell is working perfectly on every other computers, this only occurs on the server where A-Shell is installed.
I think this should be related to the server environment due some update but I think 2003 is not updated already but I'm lost about where to start digging.

Does anyone experienced something like this and can give me a tip?

Thanks in advance

Hi Jorge,

My first guess is that in the process of upgrading compiler environments, we introduced an incompatibility. (InitializeCriticalSectionEx is not a routine that A-Shell calls explicitly, so it's probably a side effect of some change in the Windows executable environment.)

Let me see if I can apply enough duct tape and axle grease to my old W2003 server machine and see if I can reproduce it. Stay tuned...

Jack

I was able to reproduce it with 6.4.1554.1 and W2003 here. Research in progress...

Wow!!!! that was a perfect shot, many thanks

Thanks may be premature...

I've managed to find a couple of other posts about this on Microsoft forums, but no real resolution. It seems that applications built with Visual Studio 2013 or above, or more specifically, are using the VS2013 runtime libraries, have this problem.

We switched to the VS2013 tools back in May, with 6.4.1549.0.

I've tried recompiling with the VS2013 option to target the VS2010 toolset, but that doesn't resolve it.

It might be possible to recompile using the complete Visual Studio 2010 environment, but there are various technical obstacles which I would have to overcome first, so it's not a quick fix.

The only quick fix I've come up with so far is to go back to 6.4.1548.8, which is the last version that seems to work on W2003. (You can get that from the 6.4 A-Shell/Windows download directory .

If you can live with that, great. If not, I'll continue investigating Plan B...

Anyway, Thanks still is the right word for the investigation and, in this particular customer, I think they will be fine to stay on this version.
I sent them the update and tomorrow they will confirm if the problem is fixed.

Good morning Jack, confirmed that 6.4.1548.8 does the trick.
By now they will be fine staying with this version but, at some point, probably, they will need to move up.
It's not urgent but, do you think this issue can be fixed ?

Thank you very much

I'm pretty sure it can be worked around, most likely by setting up a VS2010 development environment. (Somewhere in the process of multiple Windows updates my VS2010 environment that was resident on my main development machine became damaged, and for some inexplicable reason, Microsoft has deleted the SP1 patch for it from their downloads, so I haven't been able to reinstall it.) But I can probably reestablish it from a backup and/or an old machine. There is also the possibility of creating a special sub-configuration of the current compile environment with the older runtime modules substituted in.

Either way, it's going to be awkward though. Microsoft doesn't make it easy to have it both ways, i.e. remain backwards compatible while also staying up to date, which is why I've tended to keep the development environment a few years behind the current. But at this point, VS2010 is getting to be "ancient" (although what does that make us?) :rolleyes: And, unless I'm mistaken, Microsoft declared end-of-support for WS2003 over two years ago, so maybe it's time to start thinking about upgrading the customer to a newer version of Windows Server?

For sure, we can't be guilty for any update on our side that become not compatible with W2003.
In most cases, that would not even be an issue because A-Shell doesn't run directly on the server, except in this customer where I have a web version for some programs.
I'm not responsible for the infrastructure on this customer but, I'm going to send a recommendation to upgrade their server in a near future.

For me, you don't need to spend extra efforts on the attempt to keep it working for non-supported environments, like W2003, I think this customer will be ok to stay on the last working version of A-Shell until decides to upgrade the server, if not, we will try to think in a solution if needed.

Thank you very much

any chance of getting this to work on 2003 server. i kind of got attached to this server.
thanks

http://tedwvc.wordpress.com/2013/04...inked-applications-to-run-on-windows-xp/

The workaround sounds like it might have potential. I'm on the road today but will try to check it out in the next 24 hours or so and get back to you...

I guess I failed to post an update on this. I did try the workaround described above, but for whatever reason, it just seems to crash the program immediately when it starts. I also pursued some reports suggesting that it should be possible to create an XP-compatible executable from VS2013 using a variety of backwards-looking options, but despite several attempts, have not yet succeeded with that either. I even tried resurrecting my old XP development machine, but it seems to have given up. So that this point the status is still a big zero.

I'm not necessarily closing the door on the possibility of getting this to work, but at this point, it doesn't appear very promising.

That last post may have been premature. See the links and comments at the bottom of the thread XTREE: export CSV for a possible solution.

Hi,
Apologize to get back to this but, while running CX version in Windows 2003, I got this message for each button using icons from the ashlib library.
Is it possible to fix?
This doesn't happen using the same CX version in client computers, even running XP or newer Windows versions.

Well, if possible and if not a nightmare to fix it.

thanks

Ok, I see what the problem is. At some point the routine that loads image DLLs was upgraded to be more "Windows conformant", i.e. to tell Windows that the DLL was only going to be used for extracting image resources, which apparently allows Windows to handle it more efficiently in memory. The flag in question was not supported until Vista, but I didn't realize that it would cause the routine to abort in earlier versions. (I would have assumed that it just ignored bit flag options that it didn't know about.)

The fix is simple enough (check the Windows version and remove the flag if necessary), and I wouldn't be surprised if it isn't the last of this kind of fix required.

I'll review (and possibly apply some of) the outstanding patches and post another version in a couple of hours.

Ok, here it is:
ash-6.5.1627.1-w32cx-upd.zip

Note that in addition to the 1627.0 patches described in the ash65notes.txt , this version also contains compiler edit 852, which contains a couple of patches/enhancements that I'm in the process of making available separately and as part of the regular 6.5.1628.0 release.

Here's the latest 6.4 version supporting W2003/XP ...

ash-6.4.1556.8-w32cx-upd.zip