Timeline



Jan 29, 2021:

2:37 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) closed by Jos
Fixed: Fixed by revision [12482] in version: 3.3.15.4

Jan 27, 2021:

3:05 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by Jos
Think the easiest solution is going to be to build SciTE & ScilLexer with VC in stead on nmake for the time being, like we do with the lite version. I have made these now available in directory /ia32 and removed all other test compiles. Could you try those once more, and when working, will move them into the Beta so that will be the next standard for Production? Thanks for your testing! Jos
11:59 AM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by Ant
Not sure if it's any help, but I came across this predefined macro. You may well know about it already. If not, it indicates at run time which /arch option was set. Maybe it can be used to check whether the /arch:IA32 option is actually being picked up by compiler.
8:41 AM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by Ant
Unfortunately, it didn't work with any of the set-ups. It was worth a shot, though. By the way, I tried the software on another almost identical machine, just to rule out some kind of glitch in my device / set-up. The same error occurred, albeit with a slightly different offset in the signature. Both machines are up-to-date (as much as they can be).

Jan 20, 2021:

8:31 AM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by Jos
Replying to Ant: > Sadly, neither did the trick. Tried them in the beta, AutoIt3 and SciTE4AutoIt3 set-ups. > > So, to summarise: > 1. the full version of ScITE fails, > 2. the "lite" version runs fine, even though it uses the same project file as the full version, and > 3. the full version runs fine when compiled under Visual Studio 2017 with the <EnableEnhancedInstructionSet> option set to NoExtensions. > > The /arch:IA32 compiler option seems to be the right one. A Visual Studio bug that causes SSE2 code to be generated unintentionally with that option is described here. > Thanks for your feedback. I had a look at that article and it does sound similar but I am not seeing that /fp: build flag so am not sure it is. To test, I changed the buildflags to: […] as they indicate that the second parameter shold be a tempory workaround. The result is stored in directory ia32/namkeia32. Could you try that set aswell? Thanks Jos
7:33 AM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by Ant
Sadly, neither did the trick. Tried them in the beta, AutoIt3 and SciTE4AutoIt3 set-ups. So, to summarise: 1. the full version of ScITE fails, 2. the "lite" version runs fine, even though it uses the same project file as the full version, and 3. the full version runs fine when compiled under Visual Studio 2017 with the <EnableEnhancedInstructionSet> option set to NoExtensions. The /arch:IA32 compiler option seems to be the right one. A Visual Studio bug that causes SSE2 code to be generated unintentionally with that option is described here.

Jan 14, 2021:

1:59 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by Jos
I have added 2 versions to the ia32 directory: maknono compiled mak file with: -DUSE_MSVC_SSE=OFF -DUSE_MSVC_SSE2=OFF makyesno compiled mak file with: -DUSE_MSVC_SSE=ON -DUSE_MSVC_SSE2=OFF Have a go and see if that solves anything... else I might have to consider doing the compile with Visual Studio instead of nmake.

Jan 13, 2021:

4:54 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by anonymous
Unfortunately, it doesn't. When dropped into each of the beta, AutoIt3 and SciTE4AutoIt3 set-ups, the original error occurs. I'm way out of my depth here, but could the desired command line options be as follows? […] In other words, use SSE (compatible with my machine) but don't use SSE2 (incompatible with my machine). Feel free to ignore me; this is an uninformed stab in the dark. If it exists, I can't find the on-line documentation for these options.

Jan 8, 2021:

8:04 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by Jos
Ok, adding this in the vcxproj file does the trick then for the VC2017 build: […] Previously I added this to the standard scite.mak and scitilla.mak files but that doesn't seem to work: […] Found somewhere another option to try: […] .. and uploaded that to https://www.autoitscript.com/autoit3/scite/download/beta_SciTE4AutoIt3/ia32/mak/ Could you try that version for me to see if that fixes it? Jos
3:25 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by Ant
Btw, thanks very much for that, mLipok. I only just spotted the new username.
3:15 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by Ant
We have progress. Having successfully installed the (2015) redistributable package, both the lite and the full versions of SciTE that you compiled with Visual Studio (in "comment9") open and seem to run fine when dropped into the beta set-up. So this means the recent Visual Studio SciTE compilations have something (that ensures compatibility with my device) that the published versions don't.
3:21 AM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by mLipok
Replying to Jos: > .....which I believe are standardly installed these days....... Unfortunately not. I have similar issue at my work, when we install some software on fully udpated Win10 Pro, then we must to especially install this following vcredist pack. @Ant Try to install those 3 following MS Visual C++ Redistributable package: vcredist_x86_2005.exe vcredist_x86_2008.exe vcredist_x86_2015.exe EN version->vcredist_x86_2015.exe

Jan 7, 2021:

9:14 AM Ticket #3800 (Number() - case sensivity with scientific notation by using $NUMBER_AUTO) closed by J-Paul Mesnage
Fixed: Already solver for the next Beta/Release
7:48 AM Ticket #3800 (Number() - case sensivity with scientific notation by using $NUMBER_AUTO) created by AspirinJunkie
Following Script: […] produces: […] The capitalized letter "E" …

Jan 6, 2021:

7:21 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by Jos
I feels like you are running on a (very) old/limited OS as these files are part of the standard Microsoft Visual C ++ Redistributable package, which I believe are standardly installed these days. So it could very well be that older systems aren't compatible with the latest version of the VisualStudio compiler and SciTE options set for the compiler/linker. When this is the case, you will have to use the latest version available of WinXP on the downloadpage, unless you have other ideas. Jos
4:23 PM Ticket #3798 (SciTE4AutoIt incompatibilty with SSE instruction set) updated by Ant
Sorry for taking a while to reply. Both sets of files when placed in their respective installations produce an application error message reporting that the file MSVCP140.DLL is missing. Presumably, this is a runtime file that's been added to the project, perhaps by Visual Studio, but isn't included as a distributable with any of the AutoIt, SciTE or beta packages (and is therefore unrelated to the original error). If the file is needed, are you able to include it with the beta files?

Jan 5, 2021:

10:06 AM Ticket #3001 (Added AutoIt3x_64.dll to Excel Add-in list loads it as initial spreadsheet.) closed by J-Paul Mesnage
Works For Me: After deep analysis with Water it is working for us

Jan 3, 2021:

4:01 PM Ticket #3702 (Make Execute capable of processing declarations) updated by J-Paul Mesnage
Hi sorry for this long delay, but I thing that using Dim $a[$d1] or Dim $a[$d1][$d2] or Dim $a[$d1][$d2][$d3] when needed do the job no need to extend Execute() Can you provide a more complete script which can describe what you need? Thanks Happy new year
2:31 PM Ticket #2652 (Allow ExpandVarStrings to expand com properties as well.) updated by J-Paul Mesnage
Owner, Status changed
Hi, I introduce a new option to expand expression Opt("ExpandExpStrings", 1) to expand string containing expression such as "($vars.widget.window.title)" a COM evariable must be evaluated before it can be used. Fix sent to Jon
8:51 AM Ticket #3525 (Support for binding to multicast group) updated by J-Paul Mesnage
Owner, Status changed
I add a new function UDPJoinMulticastGroup(Ipaddr, Port, IPMulticastGroup) I sent the fix to Jon Thank, sorry for the long delay

Jan 1, 2021:

6:13 AM Ticket #2866 (regread cant read x64 keys remote) updated by J-Paul Mesnage
Owner, Status changed
Fix sent to Jon
Note: See TracTimeline for information about the timeline view.