1. Rob: Reply about OW 1.4 full-screen issue
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 22, 2006
- 507 views
I decided to try mentioning the problem with OW going full-screen by subscribing to their news-server, rather than google groups. I gotten replies within a few hours. <reply> From: Hans-Bernhald Broeker To: openwatcom.users.c_cpp Subject: Re: DOS Watcom C/C++ problem I tried to reproduce that on a machine running OW 1.4 and Windows XP, but failed. I think that means you'll have to explain in more detail what that program does, how exactly you build it (OW compiler and linker options used), and what the program properties are. Please note that DOS programs have *two* places in the settings dialog where you can select windowed mode or something else: Program->run as: (normal window/minimized/maximized) Screen->Display: (full screen / windowed) </reply> <reply> #2 I guess he is changing video mode... thus triggering full screen in the first place... (just a guess) regards John </reply> What should I reply back with? Say that none of that works? Tell him that you use: wcc386 /w0 /zq /j /zp4 /fpc /5r /otimra /s xxxx.c ... wlink FILE xxxx.obj @objfiles.lnk ... option osname='CauseWay' libpath C:\WATCOM\lib386 libpath C:\WATCOM\lib386\dos OPTION stub=C:\EUPHORIA\bin\cwstub.exe format os2 le ^ OPTION STACK=262144 OPTION QUIET OPTION ELIMINATE OPTION CASEEXACT FILE C:\EUPHORIA\bin\ec.lib Can you help, because I wouldn't know how to answer technical questions about the Euphoria interpreter? Regards, Vincent
2. Re: Rob: Reply about OW 1.4 full-screen issue
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 22, 2006
- 489 views
Robert: I built a small "Hello World" program in C and compiled using the same compiler and linker options as EMAKE. I took out one thing from OBJFILES. FILE C:\EUPHORIA\bin\ec.lib I compiled it and the program ran in windowed mode. So that makes me think that there is something in "ec.lib" that is causing Open Watcom to start full-screen? Regards, Vincent
3. Re: Rob: Reply about OW 1.4 full-screen issue
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 22, 2006
- 510 views
Vincent wrote: > I built a small "Hello World" program in C and compiled using the same > compiler > and linker options as EMAKE. I took out one thing from OBJFILES. > > FILE C:\EUPHORIA\bin\ec.lib > > I compiled it and the program ran in windowed mode. So that makes me think > that > there is something in "ec.lib" that is causing Open Watcom to start > full-screen? Thanks. I'm not saying that all DOS C programs compiled by OW1.4 will go to full screen. I identified about 5 different points during the interpreter start-up and/or final cleanup which each force it to full screen. If I remove all of them, it won't go to full screen. The trouble is, I can't remove them all. They all do something useful, if not essential. What do they have in common? They are all calls to the Watcom graphics library. e.g. _getvideoconfig(), _gettextposition(), _setactivepage, set_visualpage, _outtext. Most of them will eventually be needed by the Euphoria program, even if they are somehow removed from the startup. For instance, _outtext is used when you try to print something on the screen. Even if this full-screen annoyance were resolved, the only thing OW1.4 has going for it, is a DOS time() function that is always fast. With 10.6 the time() function can also be fast if you call tick_rate(). Most programs couldn't care less if time() takes a millisecond instead of a microsecond. It normally isn't used inside performance-critical sections of code. It's just used to measure elapsed time, for benchmarking or something. The other advantage, I suppose, is the warm and fuzzy feeling of being up to date with the latest version of Watcom. I've established that I can easily have that feeling. I just have to type two commands: move watcom watcom10.6 move openwatcom watcom Thanks for looking into this issue. I'm not worried about it anymore. 10.6 works fine. I'll investigate OW1.5 whenever it comes out. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
4. Re: Rob: Reply about OW 1.4 full-screen issue
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 22, 2006
- 490 views
- Last edited Feb 23, 2006
Robert Craig wrote: > > Thanks. > > I'm not saying that all DOS C programs compiled by OW1.4 will > go to full screen. > > I identified about 5 different points during the interpreter > start-up and/or final cleanup which each force it to full screen. > If I remove all of them, it won't go to full screen. The trouble is, > I can't remove them all. They all do something useful, if not essential. > > What do they have in common? They are all calls to the Watcom > graphics library. e.g. _getvideoconfig(), _gettextposition(), > _setactivepage, set_visualpage, _outtext. Most of them will > eventually be needed by the Euphoria program, even if they > are somehow removed from the startup. For instance, _outtext > is used when you try to print something on the screen. > > Even if this full-screen annoyance were resolved, > the only thing OW1.4 has going for it, is a DOS time() > function that is always fast. With 10.6 the time() > function can also be fast if you call tick_rate(). > Most programs couldn't care less if time() > takes a millisecond instead of a microsecond. It normally > isn't used inside performance-critical sections of code. > It's just used to measure elapsed time, for benchmarking > or something. > > The other advantage, I suppose, is the warm and fuzzy > feeling of being up to date with the latest version of Watcom. > I've established that I can easily have that feeling. > I just have to type two commands: > move watcom watcom10.6 > move openwatcom watcom > > Thanks for looking into this issue. > I'm not worried about it anymore. > 10.6 works fine. > I'll investigate OW1.5 whenever it comes out. > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> Thats fine. Relax, no need to get all upset over it. I'm not trying to pressure you to use it. I was just trying to figure it out why it was occuring. So basically you are saying that it's a problem with the Open Watcom graphics library? So all the routines you use cause it to switch to full screen mode? Should I report this to the Open Watcom development team as a bug report? If it's in fact a problem and nobody reports it, then it will likely persist in OW 1.5 and later. So I feel obligated to report it if you consider it improper operation. Regards, Vincent
5. Re: Rob: Reply about OW 1.4 full-screen issue
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 23, 2006
- 482 views
Vincent wrote: > So basically you are saying that it's a problem with the Open Watcom graphics > library? So all the routines you use cause it to switch to full screen mode? Yes. > Should I report this to the Open Watcom development team as a bug report? > > If it's in fact a problem and nobody reports it, then it will likely persist > in OW 1.5 and later. So I feel obligated to report it if you consider it > improper > operation. I don't know if they would consider it to be a bug or not, but I think most people would prefer that their DOS window stay small, and not be forced to full-screen, unless they are running a graphics program. So, yes, I'd appreciate it if you would report it to them in some formal way. Thanks, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
6. Re: Rob: Reply about OW 1.4 full-screen issue
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 24, 2006
- 521 views
Well I reported it to them and replies just kept on coming (popular thread). The Open Watcom maintainer Michal Necasek needed alot of convincing to accept that they are different. He and others said that the new Watcom graphics library makes calls to VBE (Vesa Bios Extention) functions that may trigger full-screen under NTVDM. He basically said that major modifications would need to be made in the graphics library to "fix" this. So he really isn't willing to play with it, but welcomes any changes others make in it; but messing with this could break backwards compatability with all the Open Watcom versions down to 11.0c. One person pointed this link to me: http://support.microsoft.com/?scid=kb%3Ben-us%3B812681&x=9&y=14 All interesting ideas. But then some people reported the full-screen problem with Windows 98 (doesnt use NTVDM), so that may completely invalidate their diagnosis; I'll test this on my Windows 98 laptop. What I found interesting in the 11.0c release notes is this: The graphics library now performs the VESA test before testing for vendor specific graphics cards. This fix is intended to broaden the number of graphics cards that are supported. I'm thinking that maybe this has something to do with it. Anyway, there seems to be a few solutions to the problem. You can use the latest Open Watcom and the 10.6 graphics library and it will produce windowed DOS programs. You can also ofcourse also use Watcom 10.6 altogether. However despite the full-screen issue, there seems to be some fantasic advantages with the newer Open Watcom graphics library. 1) Support for many many more graphics cards in SVGA+ mode. 2) Support for *alot* more video modes: upto 1600x1200 @ 32 bit color! 3) Bug fixes and video caching optimizations. So basically putting the full-screen issue aside, you could very easily extend DOS Euphoria's pixel graphics to true 32 bit color and super high UXGA resolution and have support for the vast majority of graphic cards. So there are choices here to make if you switch to OW in the future. You can either avoid the full-screen issue or greatly enhance DOS Euphoria's pixel graphics feature. Regards, Vincent
7. Re: Rob: Reply about OW 1.4 full-screen issue
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 24, 2006
- 487 views
Vincent wrote: > > Well I reported it to them and replies just kept on coming (popular thread). > The Open Watcom maintainer Michal Necasek needed alot of convincing to accept > that they are different. > > He and others said that the new Watcom graphics library makes calls to VBE > (Vesa > Bios Extention) functions that may trigger full-screen under NTVDM. > He basically said that major modifications would need to be made in the > graphics > library to "fix" this. So he really isn't willing to play with it, but > welcomes > any changes others make in it; but messing with this could break backwards > compatability > with all the Open Watcom versions down to 11.0c. > > One person pointed this link to me: <a > href="http://support.microsoft.com/?scid=kb%3Ben-us%3B812681&x=9&y=14">http://support.microsoft.com/?scid=kb%3Ben-us%3B812681&x=9&y=14</a> > > All interesting ideas. But then some people reported the full-screen problem > with Windows 98 (doesnt use NTVDM), so that may completely invalidate their > diagnosis; I'll test this on my Windows 98 laptop. > > What I found interesting in the 11.0c release notes is this: > > The graphics library now performs the VESA test before testing for > vendor specific graphics cards. This fix is intended to broaden > the number of graphics cards that are supported. > > I'm thinking that maybe this has something to do with it. > > Anyway, there seems to be a few solutions to the problem. > You can use the latest Open Watcom and the 10.6 graphics library and it will > produce windowed DOS programs. You can also ofcourse also use Watcom 10.6 > altogether. > > However despite the full-screen issue, there seems to be some fantasic > advantages > with the newer Open Watcom graphics library. > > 1) Support for many many more graphics cards in SVGA+ mode. > 2) Support for *alot* more video modes: upto 1600x1200 @ 32 bit color! > 3) Bug fixes and video caching optimizations. > > So basically putting the full-screen issue aside, you could very easily extend > DOS Euphoria's pixel graphics to true 32 bit color and super high UXGA > resolution > and have support for the vast majority of graphic cards. > > So there are choices here to make if you switch to OW in the future. You can > either avoid the full-screen issue or greatly enhance DOS Euphoria's pixel > graphics > feature. Thanks a lot for all your work on this. This is very interesting information. For now I'll stick with 10.6, but you've given me a better idea of the pros & cons. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
8. Re: Rob: Reply about OW 1.4 full-screen issue
- Posted by Igor Kachan <kinz at peterlink.ru> Feb 24, 2006
- 498 views
Robert Craig wrote: > > Vincent wrote: > > [snip] > > 1) Support for many many more graphics cards in SVGA+ mode. > > 2) Support for *alot* more video modes: upto 1600x1200 @ 32 bit color! > > 3) Bug fixes and video caching optimizations. > > > > So basically putting the full-screen issue aside, you could very easily > > extend > > DOS Euphoria's pixel graphics to true 32 bit color and super high UXGA > > resolution > > and have support for the vast majority of graphic cards. > > > > So there are choices here to make if you switch to OW in the future. You can > > either avoid the full-screen issue or greatly enhance DOS Euphoria's pixel > > graphics > > feature. > > Thanks a lot for all your work on this. > This is very interesting information. > For now I'll stick with 10.6, but you've given me > a better idea of the pros & cons. Hello Robert, See please code below, it works more than x20 faster with ex_r.exe, compiled using licensed code and OW1.3 or OW1.4, than with official ex.exe 2.5. I have noticed this thing just now, I never tested this code on speed, with official ex.exe too. On ex_r.exe I have 0.879 .. 0.930 sec, on ex.exe I have 22.36 .. 22.41 sec. The machine I use is P4 1.8Gz, nVIDIA videocard.
---draw_01.ex program -- draw.e lib by Igor Kachan using RDS archive libs. -- 24.02.2006 sequence vc,lines, color integer border, width, height, first, last, row global procedure init_fill_r() vc=machine_func(13,0)--M_VIDEO_CONFIG width=vc[5]--VC_XPIXELS height=vc[6]--VC_YPIXELS end procedure procedure Fill(integer x, integer y) object line integer xb, xe row = y-first+1 line = lines[row] xb = x while 1 do if not xb or line[xb] = border then exit end if xb-= 1 end while xb+= 1 xe = x+2 while 1 do if xe > width or line[xe] = border then exit end if xe+= 1 end while xe -= 1 lines[row][xb..xe]=border -- block them! pixel(color[xb..xe],{xb-1,y}) if y>0 then -- check line above if y-1<first then line = get_pixel({0,y-1,width}) lines = prepend(lines, line) first -= 1 else line=lines[y-first] end if for i=xb to xe do if line[i] != border then Fill(i-1, y-1) line=lines[y-first] -- update! end if end for end if if y<height-1 then -- check line below too if y+1>last then line = get_pixel({0,y+1,width}) lines = append(lines, line) last += 1 else line=lines[y-first+2] end if for i=xb to xe do if line[i] != border then Fill(i-1, y+1) line=lines[y-first+2] -- update! end if end for end if end procedure -- Fill() procedure fill_r ( integer x, -- start point, horizontal coordinate integer y, -- start point, vertical coordinate integer pc, -- paint color integer bc -- border color ) -- fills area outlined by border color with paint color -- screen edges are also (default) borders if get_pixel({x,y})=bc then return -- exit immediately if start point on border end if -- position(20,1) ?{x,y} -- save for use by Fill() border = bc color = repeat(pc, width) -- solid color lines = {get_pixel({0,y,width})} first = y last = y Fill(x,y) end procedure -- fill_r() function case_la(integer c, object x) -- convert Latin atom or sequence to upper or to lower case integer d d='a' - 'A' if c then return x - (x >= 'a' and x <= 'z') * d else return x + (x >= 'A' and x <= 'Z') * d end if end function -- case_la() procedure error(integer i, integer t) position(1,1) if i=1 then puts(1,"bad operator - " & t & '\n' & " ^ in line S of function Draw(S,X,Y,C)."& "\npress Enter to exit program.\n") elsif i=2 then puts(1,"bad syntax - " & t & '\n' & " ^ in line S of function Draw(S,X,Y,C)."& "\npress Enter to exit program.\n") end if --i = getc(0) abort(i) end procedure global function Draw(sequence S,atom X,atom Y,integer C) integer sx,sy,sv,x,y,p,z,L,t,a,d,I,k,u sequence s s={} for i=1 to length(S) do t = S[i] a = find(t,"CcBbNnUuDdLlRrEeFfGgHhMmPp0123456789+-,; ") if not a then error(1,t) else if t != ' ' and t !=';' then s &= t end if end if end for s = case_la(0,s) L = length(s) d = 0 I = 1 while 1 do p = 0 x = 0 y = 0 sx = 0 sy = 0 sv = 0 t = 0 if I<=L -- interpretation of a comand then u= s[I] if not find(u,"cbnudlrefghmp") then error(2,u) end if if u='c' then k='C' -- color elsif u='b' then p='B' I+=1 u=s[I] -- go to elsif u='n' then p='N' I+=1 u=s[I] end if -- come back if find(u,"defghlru") then k = 'D' end if -- moving/drowing -- if find(u,"ghl") then x =-1 end if -- left-down/left-up/left if find(u,"efr") then x = 1 end if -- right-up/right-gown/right if find(u,"ehu") then y =-1 end if -- right-up/left-down/down if find(u,"dfg") then y = 1 end if -- down/right-down/left-down if find(u,"du") then x = 0 end if -- up/down if find(u,"lr") then y = 0 end if -- left/right if u='m' then k = 'M' d=1 a=1 t=1 end if -- to point if u='p' then k = 'P' d=1 a=1 t=1 end if -- paint -- {-1,1} * n -- to do I+=1 if k='M' or k='P' then z=2 -- 2 numbers command parameter else z=1 -- 1 number command parameter end if for i=1 to z -- 1 or 2 numbers of command parameter do if d=1 or d=2 then if I>L then exit end if u=s[I] if u='+' then t= 1 a=2 I+=1 -- new coordinate is more than old one elsif u='-' then t=-1 a=2 I+=1 -- new coordinate is less than old one end if -- on +/- end if -- on d while 1 -- values of comand parameters do u = s[I] if u>= '0' and u<= '9' then u-= '0' if d = 1 then sx = sx * 10 + u -- 1st half elsif d = 2 then sy = sy * 10 + u -- 2nd half else sv = sv * 10 + u -- single parameter end if I+= 1 if I > L then exit end if elsif u = ',' -- delimiter of a pair then d = 2 t = 1 I+=1 else exit end if end while -- end of values if d=1 then sx *= t elsif d=2 then sy *= t end if end for -- on end if -- on I < L -- interpretation is finished ----------------------- execution of a command if k='C'-- command 'C' then C=sv -- set up a color elsif k='P'-- command 'P' then fill_r(X,Y,sx,sy) -- filling an area elsif k='D'-- command 'D' then z=sv if not p -- without a prefix then pixel({C},{X,Y}) for i=1 to z do X+=x Y+=y pixel({C},{X,Y}) end for elsif p='B' -- go without drowing then for i=1 to z do X+=x Y+=y end for elsif p='N' -- drow and come back then pixel({C},{X,Y}) for i=1 -- by pixels to z do X+=x Y+=y pixel({C},{X,Y}) end for for i = z -- come back to 1 by -1 do X-=x Y-=y end for end if k=0 elsif k='M' -- command 'M' then x=sx y=sy if a=2 then if not p then machine_proc(2,{C,0,{{X,Y},{X+x,Y+y}}}) X+=x Y+=y elsif p='B' then X+=x Y+=y elsif p='N' then machine_proc(2,{C,0,{{X,Y},{X+x,Y+y}}}) end if end if if a=1 then if not p then machine_proc(2,{C,0,{{X,Y},{x,y}}}) X=x Y=y elsif p='B' then X=x Y=y elsif p='N' then machine_proc(2,{C,0,{{X,Y},{x,y}}}) end if end if k=0 d=0 a=0 end if if I>L then exit end if end while -- end of interpetation and execution of the string S return {X,Y,C} end function procedure next(integer a) while get_key()=-1 do end while if a then clear_screen() puts(1, "any key to proceed ... \n") end if end procedure object ok ok=machine_func(5,261) init_fill_r() atom T constant Ukg = "R 3F 1R 2f1r1d1r 3c3e1u2 h1L1u1h1L2H 1l" & "6 c1 4g1l2 g2l1 g2d2g2u1e2r1c10e1r2e1r3", cros = "bu1nu3f1nr3g1nd3h1nl3br1", UUU = "m150,240c12m+170,+0c3m200,20", VVV = "be9 c2 nm-19,+15 c3 m-15,+19 c12 l4 u100 m 320,290" puts(1, "any key to proceed ... \n") ok = Draw(Ukg, 320,100,15) next(1) ok = Draw(cros,320,300,10) next(1) ok = Draw(UUU, 200,20,15) next(1) pixel(14,{310,280}) ok = Draw(VVV, 320,280,14) next(1) ok = Draw("d3r5br5r5br5nu5nd5r5",50,50,15) ? ok ok = Draw("d30r30u30l30br5bd5p2,14",250,250,14) next(1) puts(1, "the test of speed now ...") T=time() for j=0 to 600 by 60 do for i=1 to 600 by 2 do ok = Draw(Ukg,20+i,80+25*sin(i)+j,12) end for end for T=time() - T position(2,30) ? T next(1) ok = machine_func(5,-1) --- end of draw_01.ex program
I think you'll like OW1.4 more with this example to go away from your old very good but obsolete now 10.6. Yes, there is some minor risk about old archive packages, but what to do? Regards, Igor Kachan kinz at peterlink.ru
9. Re: Rob: Reply about OW 1.4 full-screen issue
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 24, 2006
- 489 views
- Last edited Feb 25, 2006
Igor Kachan wrote: > Hello Robert, > See please code below, it works more than x20 faster with ex_r.exe, > compiled using licensed code and OW1.3 or OW1.4, than with official > ex.exe 2.5. <snip> > I think you'll like OW1.4 more with this example > to go away from your old very good > but obsolete now 10.6. > Yes, there is some minor risk about old archive packages, > but what to do? Have you tried adding "machine_proc(38, 18.3)" at the top of your program? That will drastically speed up the time() function. Try it and see if it speeds up your program. If it doesnt then OW must be doing something else faster. > Regards, > Igor Kachan > kinz at peterlink.ru Regards, Vincent
10. Re: Rob: Reply about OW 1.4 full-screen issue
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 25, 2006
- 499 views
Igor Kachan wrote: > Robert Craig wrote: > > Vincent wrote: > > > > > [snip] > > > > 1) Support for many many more graphics cards in SVGA+ mode. > > > 2) Support for *alot* more video modes: upto 1600x1200 @ 32 bit color! > > > 3) Bug fixes and video caching optimizations. > > > > > > So basically putting the full-screen issue aside, you could very easily > > > extend > > > DOS Euphoria's pixel graphics to true 32 bit color and super high UXGA > > > resolution > > > and have support for the vast majority of graphic cards. > > > > > > So there are choices here to make if you switch to OW in the future. You > > > can > > > either avoid the full-screen issue or greatly enhance DOS Euphoria's pixel > > > graphics > > > feature. > > > > Thanks a lot for all your work on this. > > This is very interesting information. > > For now I'll stick with 10.6, but you've given me > > a better idea of the pros & cons. > > Hello Robert, > > See please code below, it works more than x20 faster with ex_r.exe, > compiled using licensed code and OW1.3 or OW1.4, than with official > ex.exe 2.5. > > I have noticed this thing just now, I never tested > this code on speed, with official ex.exe too. > > On ex_r.exe I have 0.879 .. 0.930 sec, > on ex.exe I have 22.36 .. 22.41 sec. > > The machine I use is P4 1.8Gz, nVIDIA videocard. I also have a P4 1.8GHz with nVIDIA video card. Yes, your SVGA demo runs much faster with ex.exe built with OW 1.4 than with 10.6. And with 10.6 I had to add: use_vesa(1), and it still hung up a couple of times. However, when I tried VGA (mode 18) the speed was the same. This is useful information. Maybe you'll eventually convince me to switch. For now, translator users can use OW1.4 to get much faster SVGA graphics than with the interpreter. Their programs might run correctly on more graphics cards too. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
11. Re: Rob: Reply about OW 1.4 full-screen issue
- Posted by Igor Kachan <kinz at peterlink.ru> Feb 25, 2006
- 478 views
Robert Craig wrote: > Igor Kachan wrote: [snip] > > > > On ex_r.exe I have 0.879 .. 0.930 sec, > > on ex.exe I have 22.36 .. 22.41 sec. > > > > The machine I use is P4 1.8Gz, nVIDIA videocard. > > I also have a P4 1.8GHz with nVIDIA video card. > > Yes, your SVGA demo runs much faster with ex.exe built with > OW 1.4 than with 10.6. And with 10.6 I had to add: use_vesa(1), > and it still hung up a couple of times. > > However, when I tried VGA (mode 18) the speed was the same. > > This is useful information. > Maybe you'll eventually convince me to switch. Any one can use bilingual ex_r.exe to get faster interpretation for SVGA just now, so the problem is not that urgent and you have some time for better testing of OW_1.4..1.x, Rob. > For now, translator users can use OW1.4 to get much faster > SVGA graphics than with the interpreter. Their programs > might run correctly on more graphics cards too. Yes, translated/compiled with OW_1.4 that program gives 0.659 .. 0.714 sec in SVGA mode. To Vincent: I use just 2 calls of time() in that test, so there is almost nothing to do with time() in that program, it is not a multitasking one. Regards, Igor Kachan kinz at peterlink.ru
12. Re: Rob: Reply about OW 1.4 full-screen issue
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 25, 2006
- 475 views
Igor Kachan wrote: > Any one can use bilingual ex_r.exe to get faster > interpretation for SVGA just now, so the problem > is not that urgent and you have some time for better > testing of OW_1.4..1.x, Rob. Sounds good. What I'll probably do is build and use my own version of official Euphoria v3.0 interpreters using Open Watcom v1.4 and my free upgrade v3.0 C back-end source code. Open Watcom v1.5 may have LFN support (not sure yet) and plenty of other new features and improvements. Robert might become more interested with that and use it for Euphoria v3.1. We'll have to see how everything plays out. > To Vincent: I use just 2 calls of time() in that test, > so there is almost nothing to do with time() in that program, > it is not a multitasking one. Yes... I did a test afterwords and SVGA modes perform 22x faster when compiled with Open Watcom v1.4 verses Watcom v10.6. As I've mentioned earlier, the newer graphics library can go beyond SVGA and 256 colors. > Regards, > Igor Kachan > kinz at peterlink.ru Regards, Vincent