Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#2023 closed Feature Request (Rejected)

Windows 98/ME (ANSI) compile support needed again

Reported by: anonymous Owned by:
Milestone: Component: AutoIt
Version: Severity: None
Keywords: Cc:


I took a poll of my users: about slightly less than 1/2 of the users of my software are wanting windows 98/ME support. A lot of these may be business users and home users. large-format printers seem to work best with old OS's...
etc. so sometimes users can't upgrade to windows 7, xp, or whatever.

please make ANSI code generation a possibility again. thank you.

support for ANSI got dropped, and it shouldn't have. it needs to come back in.

I don't want to deal with that older compiler version, it doesn't have features I need, plus about 30 of my programs have now been updated to reflect the new syntax and libraries.
thank you.

honestly, I don't know whether this is a bug or a feature request. reporting as bug.

Attachments (0)

Change History (9)

comment:1 Changed 13 years ago by Jpm

  • Type changed from Bug to Feature Request

comment:2 Changed 13 years ago by TicketCleanup

  • Version deleted

Automatic ticket cleanup.

comment:3 Changed 13 years ago by Valik

  • Resolution set to Rejected
  • Status changed from new to closed

No. AutoIt is now a UNICODE application. Most of the ANSI conditional stuff is gone. There are also features that would have to be conditionally removed so the binary would even run on Windows 9x. This makes the code a huge mess just to cater to a small subset of potential users. It's not worth the time or effort to maintain. Tell your users to use an operating system that isn't older than their children or stop using a computer entirely.

comment:4 follow-up: Changed 13 years ago by jmichae3@…

I don't know about you, but I like serving my users with applications they can use. they are my customers. If they are still using windows 9x, fine with me, I will try my best to make my apps work on windows 9x. no need to cop an attitude here. I guess I need to start investigating GUI toolkits to replace autoit. thank you for your time.

comment:5 in reply to: ↑ 4 Changed 13 years ago by Jos

Replying to jmichae3@…:

If they are still using windows 9x, fine with me, I will try my best to make my apps work on windows 9x.

What is the issue with using the latest version of Autoit3 that still supports ANSI? It is like Win9X not developed anymore but can still be used fine.


Last edited 13 years ago by Jos (previous) (diff)

comment:6 follow-up: Changed 13 years ago by jmichae3@…

I admit I was upset by what you had said, and I shouldn't have said what I said, and I am sorry. I heard that the digital mars C++ compiler has some sort of microsoft MSLU unicode layer for unicode on top of windows 9x systems.

the the unicows.exe MSLU itself which is about 300KB

this provides a UNICODE layer on top of windows 9x/me. so this may mean you can keep the unicode stuff while still running. all you would need to do is tell the users they need to execute this program in their installers if it's a windows 9x/me machine. this requires OS detection. I have code for doing this in NSIS, but not innosetup.

I am going to do some testing to see if this works. I hope it does, if my ISP will work today.

as I said before, the older version of autoit is a different language (at least different libs), and I have already converted my code to the new version. I don't really want to go backwards because I like/need the new features in some cases.

comment:7 Changed 13 years ago by anonymous

can't seem to get that unicows to do what I want it to. has no instructions, it just asks you where to dump 2 files (.dll and .pdb). not user friendly to average joe user or to developer. kb article has no instructions either. I guess you are supposed to program against it by dynamically loading the DLL. the license is miles long but it is a redistributable, as long as you distribute it properly with your app.

comment:8 Changed 13 years ago by anonymous

does the older version work on vista/windows 7/windows 8 in the program files directory, which is a protected directory?
this is also a need. cross-platform in an ANSI version. I may need to go back to an ANSI version if this will work (I have no 7 boxed to test with).

you can have an XML manifest windows resource in an executable to make it vista/7/8 compatible with certain conditions: it must not have an assembly version, type, processorArchitecture, name. no description. trustinfo looks different. it looks basically like this (someprogram.exe.manifest):

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">



<ms_asmv2:requestedExecutionLevel level="asInvoker">





this you link into the executable as a windows resource (or you use the microsoft mt.exe manifest tool).
the .rc file looks like this:

#include "winuser.h"
1 RT_MANIFEST "someprogram.exe.manifest"

this works with windows 98, xp, vista, 7, and probably 8 and allows the program to run in c:\program files\ without getting shoved into the Virtual Store.

comment:9 in reply to: ↑ 6 Changed 13 years ago by Jos

Replying to jmichae3@…:

I admit I was upset by what you had said, and I shouldn't have said what I said, and I am sorry.

Don't know whether you noticed but I don't think you were upset with me.
Let's stop this dialog here and have that in our forum where this belongs.


Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

as closed The ticket will remain with no owner.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.