1. Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 02, 2009
- 1351 views
Euphoria on Vista
- Today, I am starting a project aimed at producing a stable and safe version of the Interpreter targeting the MS Windows Vista platform. I will be calling it tentatively "EuphoriaVista". This comes after the Euphoria Interpreter v3.1.1 for Windows, which seems to be targeting WinXP, crashed my system twice. I am not a full-time programmer, so I would be interested in whatever community support I could get with it.
- One of the problems is that GUI Windows (API calls from the Interpreter) wont work with DEP on. DEP protects Vista from malicious code and leaving it off leaves my system vulnerable to attack and file system corruption from other programs, as well as the ones I'm debugging. File system corruption could lead to "Genuine Windows" Anti-Piracy Limited Access Auto-Protect Mode (which happened to me once). In that mode, an annoying dialog pops up and you are limited to Internet access only, while you try to verify that your Windows copy is genuine. Once it's verified as genuine, you get your computer back.
- The next problem is that Microsoft is dropping support for older code and older APIs in favor of newer and "safer" APIs and system library functions (such as UNICODE instead of "ascii", TCHAR instead of CHAR for character data, StringCchPrintf instead of "sprintf" to avoid buffer overflow the length and the character count is passed, etc.)
- Since Windows 2000 (perhaps since NT), Windows is a UNICODE system internally. Any "ascii" strings passed to API functions using "functionA" format have to be converted to a UNICODE string before they are processed. This is provided for back-wards compatibility, however, all new programs targeting NT systems should be built using the "functionW" version of the API function passing a full UNICODE UTF-16 "like" string to the function. [The exact UNICODE encoding is based on the OS version, but they are all based on a 16-bit WCHAR]
- Most new programs targeting the MS Vista and later are meant to be written in "dot net" (.NET) a compiled executable format with a program compress inside it similar to Euphoria's *.il method. [Sun's Java uses a similar technique to produce Java class files.]
- Microsoft provides a free [for a home user at least, I don't know about commercial, someone would have to help me understand the legal jargon] programming tool "Microsoft Visual C++ 2008 Express Edition" (and other Express editions in VB, C#, Web) that compiles for the Vista platform [I think all Vista versions and supported processors, there are many output formats it supports] and can produce "dot net" (.NET) executables. (http://www.microsoft.com/Express/)
- 64-bit Operating Systems. A newer data type "long long" or "__int64" is used extensively, and the standard method for calling functions is different, but uniform across all function calls.
- Different privilege levels, and security descriptors that a programmer now has to account for.
- Vista and later systems use a method for protecting memory so that traditional Euphoria machine code embedded in source files does not work. [It has to be called from the program's own memory, I think, or it has to be hard-coded in the executable or in a project *.dll that the Interpreter can link to.]
- It may be easier to map the "dot net" (.NET) framework to the Interpreter its self. Each call to a "dot net" (.NET) function that the Interpreter uses could be in a C style switch statement.
- Euphoria v3.1.1 still uses the "functionA" version of the Windows API. Many older libraries use outdated machine code that wont work on Vista.
- EuphoriaVista will only use "safe" functions as specified by Microsoft and use recommended Windows API functions for the target Windows version whenever possible.
- The goal is to write source code in Euphoria, and have it run on Vista in a safe and predictable manner.
These are only some of the problems when porting to Vista. I will be working on a "Hello World" Windowed App demo of my "EuphoriaVista" porting project to post to the archive.
I will also be reading up on results on the forum matching keyword Vista in the next few days, to see where the community stands on supporting the Vista OS.
jcmarsh
2. Re: Starting project EuphoriaVista Interpreter
- Posted by jimcbrown (admin) Jan 02, 2009
- 1399 views
Euphoria on Vista
- Today, I am starting a project aimed at producing a stable and safe version of the Interpreter targeting the MS Windows Vista platform. I will be calling it tentatively "EuphoriaVista". This comes after the Euphoria Interpreter v3.1.1 for Windows, which seems to be targeting WinXP, crashed my system twice. I am not a full-time programmer, so I would be interested in whatever community support I could get with it.
I think it says much for Vista that 3.1.1 could BSOD the entire system. ;) Sorry, I couldn't resist.
Both 3.1.1 and 4.0 are currently trying to target the entire range of Windows systems from 98 to Vista, as well as OS X, Linux, and FreeBSD.
- One of the problems is that GUI Windows (API calls from the Interpreter) wont work with DEP on. DEP protects Vista from malicious code and leaving it off leaves my system vulnerable to attack and file system corruption from other programs, as well as the ones I'm debugging. File system corruption could lead to "Genuine Windows" Anti-Piracy Limited Access Auto-Protect Mode (which happened to me once). In that mode, an annoying dialog pops up and you are limited to Internet access only, while you try to verify that your Windows copy is genuine. Once it's verified as genuine, you get your computer back.
- Vista and later systems use a method for protecting memory so that traditional Euphoria machine code embedded in source files does not work. [It has to be called from the program's own memory, I think, or it has to be hard-coded in the executable or in a project *.dll that the Interpreter can link to.]
Shawn Pringle has written DEP support, and is in the process of integrating it to the current 4.0 branch. The next alpha release will fully support DEP. This includes support for calling embedded machine code (although the libraries themselves might need slight modification, e.g. changing allocate() to allocate_executable() or similar).
- The next problem is that Microsoft is dropping support for older code and older APIs in favor of newer and "safer" APIs and system library functions (such as UNICODE instead of "ascii", TCHAR instead of CHAR for character data, StringCchPrintf instead of "sprintf" to avoid buffer overflow the length and the character count is passed, etc.)
- Since Windows 2000 (perhaps since NT), Windows is a UNICODE system internally. Any "ascii" strings passed to API functions using "functionA" format have to be converted to a UNICODE string before they are processed. This is provided for back-wards compatibility, however, all new programs targeting NT systems should be built using the "functionW" version of the API function passing a full UNICODE UTF-16 "like" string to the function. [The exact UNICODE encoding is based on the OS version, but they are all based on a 16-bit WCHAR]
- Euphoria v3.1.1 still uses the "functionA" version of the Windows API. Many older libraries use outdated machine code that wont work on Vista.
I see exactly three places in the source code where the functionA form is directly called (and two of those are in pathopen.e where we have to choose between A and W). The current console code in be_w.c using WriteConsoleOutput() uses the ascii format as well.
All of this looks trivial to change (and could be #ifdef'd and uname()'d to maintain backwards compatibility with 98).
True unicode support for Euphoria is a long term goal that'll probably come in 4.1 or 4.2
- Most new programs targeting the MS Vista and later are meant to be written in "dot net" (.NET) a compiled executable format with a program compress inside it similar to Euphoria's *.il method. [Sun's Java uses a similar technique to produce Java class files.]
- Microsoft provides a free [for a home user at least, I don't know about commercial, someone would have to help me understand the legal jargon] programming tool "Microsoft Visual C++ 2008 Express Edition" (and other Express editions in VB, C#, Web) that compiles for the Vista platform [I think all Vista versions and supported processors, there are many output formats it supports] and can produce "dot net" (.NET) executables. (http://www.microsoft.com/Express/)
What's the benefit of switching from the current il to producing .NET output?
- It may be easier to map the "dot net" (.NET) framework to the Interpreter its self. Each call to a "dot net" (.NET) function that the Interpreter uses could be in a C style switch statement.
This is going to be unpopular due to the speed hit we'll take. (This will be as slow as, or even slower than, using INT_CODES.)
- 64-bit Operating Systems. A newer data type "long long" or "__int64" is used extensively, and the standard method for calling functions is different, but uniform across all function calls.
I can only speak for Linux here (where adding this kind of support is very easy).
- Different privilege levels, and security descriptors that a programmer now has to account for.
The interpreter itself should work at the lowest possible privilege level, and the coder is responsible for calling the right APIs to perform elevation and such (possibly using a vista32lib.ew to do so). This is the way it should be.
- EuphoriaVista will only use "safe" functions as specified by Microsoft and use recommended Windows API functions for the target Windows version whenever possible.
- The goal is to write source code in Euphoria, and have it run on Vista in a safe and predictable manner.
That should already be the case for the 4.0 alpha. If it isn't then we have a bug that needs to be fixed.
3. Re: Starting project EuphoriaVista Interpreter
- Posted by irv Jan 02, 2009
- 1349 views
- The goal is to write source code in Euphoria, and have it run on Vista in a safe and predictable manner.
Good luck with that. I have enough trouble trying to get Vista to run in a safe and predictable manner.
4. Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 02, 2009
- 1325 views
Thank you for the feedback jimcbrown.
Vista has been out since 2006, and Microsoft still plans on building on that technology for future releases. It makes sense to design Euphoria for future releases of Windows.
I understand the developer's desire to keep the source code for all operating systems in one development branch, however, sometimes I feel like "I just want the darn thing to work on my computer." I was throwing out all of the options in a brainstorming manner. How I will proceed with this project at this point is still unknown. I have many ideas and have to eliminate the worst choices to find the way I want to go with it.
My depth of knowledge of different Windows operating systems is extensive, but I do programming to get a particular task done. I would like to see more interfaces to Windows API functions at a higher level, which is why I mentioned .NET and Java. There is a way to interface Java from C code, at least on Windows, and there is a way to integrate .NET code into a C project using MS Visual Studio.
I can eliminate those ideas from my collection of ideas for this project, and leave them for later, possibly a library.
My next post will be kind of long, so I'll stop this post here.
5. Re: Starting project EuphoriaVista Interpreter
- Posted by jimcbrown (admin) Jan 02, 2009
- 1319 views
I understand the developer's desire to keep the source code for all operating systems in one development branch, however, sometimes I feel like "I just want the darn thing to work on my computer." I was throwing out all of the options in a brainstorming manner. How I will proceed with this project at this point is still unknown. I have many ideas and have to eliminate the worst choices to find the way I want to go with it.
Other than stating that 3.1.1 caused Vista to BSOD and the issue with DEP that iis being fixed in 4.0 alpha 3 (the DEP issue also applies to XP), you have not given a clear statement on what specifically is broken on Euphoria that makes it Vista incompatible. A few basic tests were done on Vista and eu 4.0 seems to work fine there. (More testing and bug reports are welcome of course.)
Vista has been out since 2006, and Microsoft still plans on building on that technology for future releases. It makes sense to design Euphoria for future releases of Windows.
uname() is already Windows 7 compatible. :P
My depth of knowledge of different Windows operating systems is extensive, but I do programming to get a particular task done. I would like to see more interfaces to Windows API functions at a higher level, which is why I mentioned .NET and Java. There is a way to interface Java from C code, at least on Windows, and there is a way to integrate .NET code into a C project using MS Visual Studio.
I can eliminate those ideas from my collection of ideas for this project, and leave them for later, possibly a library.
Integration with .NET and Java isn't necessarily bad. It is very complex (and would probably need to be a separate development branch at a minimum), but it could be worthwhile. Also, JNI and Mono work on non Windows platforms, so this could benefit other OSes besides Vista. (Mono even has some API compatibility with .NET I believe.)
You have some great ideas, jcmarsh. I look forward to seeing how you progress your project with them.
6. Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 02, 2009
- 1319 views
Euphoria for Vista Concerning the Win32 distribution of Euphoria v3.1.1 and v4.0
Things I know through trial or error:
- Interpreter will not work under DEP (yet), work is under way.
- It should only run under DEP for security reasons and system stability
- To make it run under DEP new code will have to be added to the source (pending)
- 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.
- 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.
I suggest that the Windows Distribution be split into three (3) main parts:
- DOS32 and Win98 compatible (designed to run on Win98)
- WinNT/2000/XP compatible (designed to run on WinXP with Win2000 support using exw) (Note: ex is only supported by WinXP using a backwards compatibility layer that is dropped from later version of Windows)
- Vista compatible (designed to run on Vista, exw only--ex will crash it is unsafe on Vista)
- It should be noted that ex.exe is only fully supported on Win98 (and earlier) and only mostly supported on WinXP
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
- Vista 64-bit support will have to wait until the source can compile for 64-bit on IA64 (Intel) and x86-64 (such as AMD64) architectures
These are all suggestions. I will be looking forward to any feedback.
7. Re: Starting project EuphoriaVista Interpreter
- Posted by jimcbrown (admin) Jan 02, 2009
- 1321 views
Euphoria for Vista Concerning the Win32 distribution of Euphoria v3.1.1 and v4.0
Things I know through trial or error:
- It should only run under DEP for security reasons and system stability
That's up the the user who owns the box. That person might want to have DEP off for valid reasons.
- 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.
- 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 suggest that the Windows Distribution be split into three (3) main parts:
- DOS32 and Win98 compatible (designed to run on Win98)
- WinNT/2000/XP compatible (designed to run on WinXP with Win2000 support using exw) (Note: ex is only supported by WinXP using a backwards compatibility layer that is dropped from later version of Windows)
- Vista compatible (designed to run on Vista, exw only--ex will crash it is unsafe on Vista)
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.
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).
- Vista 64-bit support will have to wait until the source can compile for 64-bit on IA64 (Intel) and x86-64 (such as AMD64) architectures
I guess there aren't enough copies of XP 64-bit to make sense to support it.
8. Re: Starting project EuphoriaVista Interpreter
- Posted by jeremy (admin) Jan 02, 2009
- 1258 views
I develop 4.0 on and use Vista solely, I've never had a crash that others did not have on XP. What type of problems are you experiencing?
Jeremy
9. Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 02, 2009
- 1327 views
Other than stating that 3.1.1 caused Vista to BSOD and the issue with DEP that iis being fixed in 4.0 alpha 3 (the DEP issue also applies to XP), you have not given a clear statement on what specifically is broken on Euphoria that makes it Vista incompatible. A few basic tests were done on Vista and eu 4.0 seems to work fine there. (More testing and bug reports are welcome of course.)
Specifically, I would not run ex.exe on Vista even with DEP "off".
With DEP "on" window.exw doesn't work (but I heard that is being fixed). It returns with an error, the ex.err dump begins with:
C:\EU4a\demo\win32\window.exw:230 in procedure WinMain() A machine-level exception occurred during execution of this statement szAppName = 2249440 hwnd = <no value> msg = 21404904 wndclass = 21077648 WndProcAddress = 21050440 class = 13812233 id = 5 icon_handle = 60686645 ... called from C:\EU4a\demo\win32\window.exw:256 Global & Local Variables [...] C:\EU4a\demo\win32\window.exw: LoadIcon = 22 LoadCursor = 23 GetStockObject = 24 RegisterClassEx = 25 CreateWindow = 26 ShowWindow = 27 UpdateWindow = 28 GetMessage = 29 TranslateMessage = 30 DispatchMessage = 31 PlaySound = 32' ' BeginPaint = 33'!' GetClientRect = 34'"' DrawText = 35'#' EndPaint = 36'$' PostQuitMessage = 37'%' DefWindowProc = 38'&' wav_file = 2446312 Euphoria = 21404856 ps = 2427656 rect = 2249416 my_title = 2446344
window.exw:230
hwnd = c_func(CreateWindow, { 0, -- extended style szAppName, -- window class name my_title, -- window caption WS_OVERLAPPEDWINDOW, -- window style CW_USEDEFAULT, -- initial x position CW_USEDEFAULT, -- initial y position CW_USEDEFAULT, -- initial x size CW_USEDEFAULT, -- initial y size NULL, -- parent window handle NULL, -- window menu handle 0 , --hInstance // program instance handle NULL}) -- creation parameters
It fails at the Window creation. I don't know if many of the programmers have tested it with DEP "on" so that's why I'm sharing this output. With DEP "off" it will run even with sound, however, it makes the system more unstable (and vulnerable). In my opinion, it would be best to leave DEP "on" if you get Vista. I don't know how Genuine Windows protection works on WinXP, as far as I know it just disables updates. On Vista it can lock you out with only limited Internet connection, until it can be restored under Safe Mode. Changing the DEP option while working with exw.exe activated the Genuine windows protection mode. I don't know what exactly set it off, but I would be glad when exw.exe fully supports DEP "on" with Windowed Apps.
Integration with .NET and Java isn't necessarily bad. It is very complex (and would probably need to be a separate development branch at a minimum), but it could be worthwhile. Also, JNI and Mono work on non Windows platforms, so this could benefit other OSes besides Vista. (Mono even has some API compatibility with .NET I believe.)
You have some great ideas, jcmarsh. I look forward to seeing how you progress your project with them.
Deciding which ideas I have time for and the know-how to do is a tough question for me. I can design things that will work, but they might not be the best way to do them. That's one reason I'll need help on creating something other people can make use of as well.
10. Re: Starting project EuphoriaVista Interpreter
- Posted by jimcbrown (admin) Jan 02, 2009
- 1323 views
Other than stating that 3.1.1 caused Vista to BSOD and the issue with DEP that iis being fixed in 4.0 alpha 3 (the DEP issue also applies to XP), you have not given a clear statement on what specifically is broken on Euphoria that makes it Vista incompatible. A few basic tests were done on Vista and eu 4.0 seems to work fine there. (More testing and bug reports are welcome of course.)
Specifically, I would not run ex.exe on Vista even with DEP "off".
have you tried:
C:\> set EUVISTA=1 c:\> ex
DOS programs that actually use graphics require you to switch to the standard VGA driver before they can be run on Vista (and they'll require full screen mode).
With DEP "on" window.exw doesn't work (but I heard that is being fixed). It returns with an error, the ex.err dump begins with:
<snip>
It fails at the Window creation. I don't know if many of the programmers have tested it with DEP "on" so that's why I'm sharing this output. With DEP "off" it will run even with sound, however, it makes the system more unstable (and vulnerable). In my opinion, it would be best to leave DEP "on" if you get Vista. I don't know how Genuine Windows protection works on WinXP, as far as I know it just disables updates. On Vista it can lock you out with only limited Internet connection, until it can be restored under Safe Mode. Changing the DEP option while working with exw.exe activated the Genuine windows protection mode. I don't know what exactly set it off, but I would be glad when exw.exe fully supports DEP "on" with Windowed Apps.
Yep, this sounds like a known issue. You can download a DEP enabled version of euphoria from the rapideuphoria.com archives already (by Shawn Pringle, the same person who is adding support to the main 4.0 branch).
As a side note, what is failing is the c_func() call itself (because of the "tricks" it uses to pass an arbiturary number of parameters of arbiturary types to the c function), not the CreateWindow api. We crash before we actually reach that point.
Integration with .NET and Java isn't necessarily bad. It is very complex (and would probably need to be a separate development branch at a minimum), but it could be worthwhile. Also, JNI and Mono work on non Windows platforms, so this could benefit other OSes besides Vista. (Mono even has some API compatibility with .NET I believe.)
You have some great ideas, jcmarsh. I look forward to seeing how you progress your project with them.
Deciding which ideas I have time for and the know-how to do is a tough question for me. I can design things that will work, but they might not be the best way to do them. That's one reason I'll need help on creating something other people can make use of as well.
I am happy to help with the little that I am able to give.
11. Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 02, 2009
- 1308 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.
12. Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 02, 2009
- 1314 views
- Last edited Jan 03, 2009
have you tried:
C:\> set EUVISTA=1 c:\> ex
I have not tried EUVISTA=1, appears to only be in the new source code. I will have to read up about it.
Yep, this sounds like a known issue. You can download a DEP enabled version of euphoria from the rapideuphoria.com archives already (by Shawn Pringle, the same person who is adding support to the main 4.0 branch).
I will look for it, and create a new test directory on my hard drive for it.
13. Re: Starting project EuphoriaVista Interpreter
- Posted by mattlewis (admin) Jan 03, 2009
- 1282 views
- Most new programs targeting the MS Vista and later are meant to be written in "dot net" (.NET) a compiled executable format with a program compress inside it similar to Euphoria's *.il method. [Sun's Java uses a similar technique to produce Java class files.]
I think that MS would *like* for everyone to use .NET, but I don't think that there's any danger of native code going away. Having said that, I did have a mostly working (mostly, as in, not all features of euphoria were supported) MSIL version of ooeu working. It outputted MSIL code which used an assembly written in C# that served as the 'back-end.' It was horribly slow, due to the way I emulated euphoria's datatypes. There's probably a better way.
- 64-bit Operating Systems. A newer data type "long long" or "__int64" is used extensively, and the standard method for calling functions is different, but uniform across all function calls.
At some point, euphoria will likely make the jump to 64 bits, but I think there's a lot of work to be done before that. And 64-bit operating systems aren't ready for prime time, other than in the server room.
- Euphoria v3.1.1 still uses the "functionA" version of the Windows API. Many older libraries use outdated machine code that wont work on Vista.
I think you must be thinking of win32lib. It will take a fair amount of work to make it work with unicode. [shameless plusg]I'd recommend using wxEuphoria, since it already does unicode.[/plug]
Matt
14. Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 03, 2009
- 1311 views
have you tried:
C:\> set EUVISTA=1 c:\> ex
I have not tried EUVISTA=1, appears to only be in the new source code. I will have to read up about it.
Yep, this sounds like a known issue. You can download a DEP enabled version of euphoria from the rapideuphoria.com archives already (by Shawn Pringle, the same person who is adding support to the main 4.0 branch).
I will look for it, and create a new test directory on my hard drive for it.
I have set environment var EUVISTA=1, and will be trying that shortly.
I have gotten Windowed Apps to work using Shawn Pringle's DEP include file. window.exw demo works perfectly, I even traced it to find out what it was doing. I added this code to the top of demo\win32\window.exw to get it working under Vista's DEP:
-- A Standard Windows Window coded at the primitive API level -- Most Euphoria programmers should simply use Win32Lib! --with trace trace(1) include std/os.e include std/machine.e include std/dll.e include xalloc4.e -- xalloc.e using std/* libraries for version 4.0 function call_back(object id) -- enable DEP denied API call_backs return xcall_back(id) end function
The scope of the call_back() function is local, so any call of it in this file will be redirected to xcall_back() which is safe for DEP. This program doesn't use any machine code, so I don't need the other global functions found in xalloc.e
BTW, I used the "May 4th, 2008" version of xalloc.e which is found in the demo directory of the dep.zip
15. Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 03, 2009
- 1275 views
- Most new programs targeting the MS Vista and later are meant to be written in "dot net" (.NET) a compiled executable format with a program compress inside it similar to Euphoria's *.il method. [Sun's Java uses a similar technique to produce Java class files.]
I think that MS would *like* for everyone to use .NET, but I don't think that there's any danger of native code going away. Having said that, I did have a mostly working (mostly, as in, not all features of euphoria were supported) MSIL version of ooeu working. It outputted MSIL code which used an assembly written in C# that served as the 'back-end.' It was horribly slow, due to the way I emulated euphoria's datatypes. There's probably a better way.
That's cool.
- Euphoria v3.1.1 still uses the "functionA" version of the Windows API. Many older libraries use outdated machine code that wont work on Vista.
I think you must be thinking of win32lib. It will take a fair amount of work to make it work with unicode. [shameless plusg]I'd recommend using wxEuphoria, since it already does unicode.[/plug]
Yes, I was thinking more of win32lib when I wrote about that. I have not tested wxEuphoria much (it was in early stages when I first looked at it), I will have to look at it again.
I think what I am talking about is there should be standard include files for the Windows functions that are exposed on a more primitive level so that other libraries can be more easily based on them. This might make win32lib and IDE maintenance much easier.
It would define all of the constants, a few management functions, and a bunch of definitions.
16. Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 03, 2009
- 1282 views
I am still getting an error when using DOS with Vista. It says it doesn't support full-screen mode. Perhaps there's another way of executing it, maybe from a shortcut.
SET EUVISTA=1
ex wire
[Windowed Dialog Box] 16 bit MS-DOS Subsystem C:\Windows\system32\cmd.exe - ex wire This system does not support fullscreen mode. Choose 'Close' to terminate the application. [Close] [Ignore] [End Windowed Dialog Box]
17. Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 03, 2009
- 1263 views
Would I have to recompile EX.EXE to get EUVISTA=1 to work???
I am still getting an error when using DOS with Vista. It says it doesn't support full-screen mode. Perhaps there's another way of executing it, maybe from a shortcut.
SET EUVISTA=1
ex wire
[Windowed Dialog Box] 16 bit MS-DOS Subsystem C:\Windows\system32\cmd.exe - ex wire This system does not support fullscreen mode. Choose 'Close' to terminate the application. [Close] [Ignore] [End Windowed Dialog Box]
18. Re: Starting project EuphoriaVista Interpreter
- Posted by jimcbrown (admin) Jan 03, 2009
- 1262 views
No.
Try running buzz.ex instead of wire.ex
Would I have to recompile EX.EXE to get EUVISTA=1 to work???
I am still getting an error when using DOS with Vista. It says it doesn't support full-screen mode. Perhaps there's another way of executing it, maybe from a shortcut.
SET EUVISTA=1
ex wire
[Windowed Dialog Box] 16 bit MS-DOS Subsystem C:\Windows\system32\cmd.exe - ex wire This system does not support fullscreen mode. Choose 'Close' to terminate the application. [Close] [Ignore] [End Windowed Dialog Box]
19. Re: Starting project EuphoriaVista Interpreter
- Posted by jimcbrown (admin) Jan 03, 2009
- 1282 views
- Last edited Jan 04, 2009
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.
Take a look at dos_rescue.ew from http://www.rapideuphoria.com/langwar.zip
20. Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 04, 2009
- 1287 views
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.
Take a look at dos_rescue.ew from http://www.rapideuphoria.com/langwar.zip
I've heard of dos_rescue.ew, maybe it will work now that window.exw works with the include file from dep.zip
BTW: I already knew buzz.ex worked, thanks
21. Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 04, 2009
- 1311 views
If you have time, or specific interest, take a look at: "List of Microsoft Windows application programming interfaces and frameworks" (Beware before you look at it, it is a long dizzing list.)
I'd like to be able to link to some of those frameworks now that call_back() works using xcall_back() from dep.zip (the DEP enabled version of the function)
After that I could write some code to link from Euphoria to Sun's Java using the generic C linkage method. For now, I am simply dynamically linking from the Interpreter, later once I know that works, I can start thinking about a Euphoria to Java (bit-code) translator.
22. Re: Starting project EuphoriaVista Interpreter
- Posted by SDPringle Jan 06, 2009
- 1224 views
We could retrofit win32lib. It seems you are doing so Mr. Marsh.
It is relatively easy to make win32lib use DEP but it is significant work to make it use all Unicode strings.
Suppose we define a unicode string like this a sequence of 16-bit or 18-bit(!) atoms with the first element in the sequence, s[1], being equal to a byte-order-mark value. Now, this byte-order value is a legal part of unicode and though we now live in an all little endian world it can be used as an encoding marker:this sequence is UNICODE. Now to all of those who say ASCII is part of UNICODE, remember some use 8-bit characters ala ANSI.
Shawn Pringle
23. Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 07, 2009
- 1261 views
We could retrofit win32lib. It seems you are doing so Mr. Marsh.
It is relatively easy to make win32lib use DEP but it is significant work to make it use all Unicode strings.
Suppose we define a unicode string like this a sequence of 16-bit or 18-bit(!) atoms with the first element in the sequence, s[1], being equal to a byte-order-mark value. Now, this byte-order value is a legal part of unicode and though we now live in an all little endian world it can be used as an encoding marker:this sequence is UNICODE. Now to all of those who say ASCII is part of UNICODE, remember some use 8-bit characters ala ANSI.
Shawn Pringle
lol - jcmarsh is just my screen name for forums, James Cook is my real name.
Those are some good ideas.
24. Re: Starting project EuphoriaVista Interpreter
- Posted by jcmarsh1 Jan 07, 2009
- 1245 views
What is the preferred way of submitting patches to Win32lib, DEP Enabled Euphoria (DEP.zip), and OpenEuphoria svn? I would probably have to find out who the authors of the libraries are, and somehow contact them.
I would like to help work on integrating Hardware DEP Enabled Euphoria into the main development branches of Win32lib, and OpenEuphoria now that I have it working on my system.
25. Re: Starting project EuphoriaVista Interpreter
- Posted by mattlewis (admin) Jan 07, 2009
- 1241 views
What is the preferred way of submitting patches to Win32lib, DEP Enabled Euphoria (DEP.zip), and OpenEuphoria svn? I would probably have to find out who the authors of the libraries are, and somehow contact them.
I would like to help work on integrating Hardware DEP Enabled Euphoria into the main development branches of Win32lib, and OpenEuphoria now that I have it working on my system.
I think the right approach is to make changes to euphoria, so that call_back works as expected with or without DEP turned on by the user.
Submitting code for euphoria is pretty informal. Either post here or [better] email the developer list telling us about your patch. Then, if it's reasonable, etc, a developer can commit it.
Matt