Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 02, 2009
- 1307 views
Sorry, this doesn't work like instant messenger or phone, then I'd be able to correct the things I didn't know. I haven't set up the chat client yet.
That's up the the user who owns the box. That person might want to have DEP off for valid reasons.
You are right, I am only voicing my opinions for my new project with Vista and Euphoria.
I had forgot that DEP was on XP as well as Vista. It is more apparent to me on Vista.
- The executable (with DEP) would only be useful on Vista (I believe) unless there is code that detects previous versions and lets them run skipping the DEP code.
XP supports DEP iirc. The code to detect different versions of Windows has already been written, so DEP support will exist when the executable runs on XP or Vista but that executable will still run on 98 without any problems.
lol. You guys are farther ahead than I thought. I knew that was possible, but I didn't think that you had written it already. However, Bernnie has been mentioning problems on the forum in the past about getting a stable version working for Win98. That is why I thought it might be better to split the installation package to have different executables for those platforms.
- If this executable will only be used on Vista, it could make use of other newer features that are only found on Vista or later.
The only examples you've stated of this are DEP and new Vista-only APIs. The former (aside from working on XP) has a backwards compatible approach and the latter can be done without the need for a separate Vista-only executable. (The APIs just need to be wrapped.)
I see you don't understand my enthusiasm. A year ago, I wouldn't think it would be possible for me to customize the Euphoria Interpreter for my own needs, to add to it the stuff that I wanted. Today, many of those features have been added into version 4.0 including regular expressions and a decent math library. I want to add a graphics library for windows that is as easy to use as the one for DOS. Vista does not support DOS, especially Dos graphics in full-screen mode. With the Windows API working, even under DEP, then the programmer can make any sized window and draw to it, even making full screened (fast action or slow action) games with the Windows API. It would return the functionality that Euphoria had under DOS and under Win98 for newer versions of Windows under differing modes of operation, particularly Vista under DEP mode of operation.
I suggest that the Windows Distribution be split into three (3) main parts:
DOS32 is totally different (almost as far apart from Vista as it is from OS X).
However, XP and 98 are mostly compatible. XP just has a larger API.
I don't know enough about Vista to comment, but I've heard it said that it was a smaller change from XP than XP was from NT.
- It should be noted that ex.exe is only fully supported on Win98 (and earlier) and only mostly supported on WinXP
ex.exe works fine on Vista IF you perform a few changes to the OS. You've correctly noted that this is supported through a backwards compatibility layer. (The majority of the issue is with ex.exe's usage of full screen mode.)
Not sure if I should mention the EUVISTA=1 option here.
ex.exe usage of memory poking has caused me a few problems, which is why I don't run it on Vista. It has caused a few crashes when I was first testing it on Vista. It doesn't like when ex.exe pokes to memory and then tries to call that as an Assembly function. The same program worked fine on Win98, but crashed on Vista (32-bit) x86. I image the problem has already been noted, that Vista doesn't like a program calling a function in a certain part of memory. I don't think many of the old DOS techniques work. I've only tested a few samples, and figured that Vista dropped a lot of support for DOS.
The libraries for Windows functions would also need to be split up accordingly as jimcbrown suggested.
The libraries could contain API functions in groupings as follows:
- functions as old as Win3.1 API and as new as Win98 in winlib98.ew or w32lib98.ew (8.3 filename for backwards compatibility) -- these would be for the Win98 package
- functions as old as NT 4.0 and as new as WinXP (that are only in the WinNT branch of the API) in winnt32lib.ew or winxp32lib.ew -- these would be for the Win2000/XP package
- functions as old as Vista (and newer) in vista32lib.ew
This is not a bad idea. However, it is possible to have a single win32lib that handles all cases - attempts to actually use a function that isn't supported on 98 would be detected at run time and fail but the same code from the same library should work fine on Vista.
On the other hand, XP and NT are not going to lose support for the old 3.1 API so segregation here may not make sense. It makes more sense for Vista if Vista and WIndows 7 have lost or will lose older APIs (but this can be tested at run time using the same library and the same executable as that which runs on 98).
I did read something about a desire at least from Microsoft to "phase out" older technology in favor of new technology. It goes something like this, with Windows 3.1 there was one way to do something, with Windows 98 they added two more ways to do it, with Windows NT they added another way, with .NET there is yet another way. Which way should we do it now? Let's recommend the newest API syntax.
We'll have to wait and see if they really do "phase out" the older APIs.
