Implemented OCTAL supportby (no login)OCTAL support is now fully implemented and will be available in Demo #7 PS. I guess the Octospiders from Rama will be happy about this! I'd never even used &O... until someone reported QB64 didn't support it! from IP address 58.106.166.186 |
Every used chmod on Linuxby qbguy (no login)It uses octal: 1 is execute, 2 is write, 4 is read. Each digit represents different types of permissions: User, group, and everyone. Plus, base 8 is just like base 10... if you're missing 2 fingers. from IP address 75.9.218.72 |
u = user (owner of the file) g = group (group that the file belongs to) o = others (users that aren't the owner and aren't a member of the group to whom the file belongs) a = all `chmod 700 file` gives only the file's owner the ability to read, write and execute the file. `chmod go-rwx file` does the same thing (removes group and others permissions to read, write and execute). `chmod a+rwx file` gives all users and groups the ability to read, write and execute the file. `chmod 777 file` does the same thing. You can also specify separate things like "a+x" (allow all users to execute a file) or "o-w" (allow only the owner and owning group to write to the file by disallowing others write access). Some commonly used ones are: 755 - allow read/execute access to all, and allow the owner to fully manipulate the file 744 - allow read access to all, and allow the owner to fully manipulate the file 700 - only allow the owner to fully manipulate the file 644 - allow read access to all, and allow the owner to read from and write to the file 500 - only allow read/execute access to the file 000 - is this even used? perhaps by a newbie... who would want to disallow ALL access? I have yet to figure out how umask values work though. The whole four-digit thing is what gets me. :P ------------------ Waiting patiently for Windows 7, XHTML 2.0, CSS 3.0, PHP 6.0, the ratification of C++0x, and the day that I can code without logic troubles. from IP address 12.208.126.190 |
Four Digit chmodby qbguy (no login)The extra octal digit are setuid, setgid, and sticky. Sticky does absolutely nothing on Linux. If a file has the setuid attribute, it runs as the owner of the file (with elevated privileges) rather than with the privileges of whoever is running it. If it has setgid, it runs with the privileges of the group of the file. Setuid is 4, setgid is 2. sticky bit is 1, but it doesn't acutally do anything. from IP address 76.195.133.68 |
* If root sets the sticky bit makes it impossible for non-root to delete filesby qbguy (no login)from IP address 76.195.133.68 |
------------------ Waiting patiently for Windows 7, XHTML 2.0, CSS 3.0, PHP 6.0, the ratification of C++0x, and the day that I can code without logic troubles. from IP address 12.208.126.190 |
INPUT doesn't accept ALT+numpad input yet.by Dav (no login)Testing my patcher program, I notice extended ascii chraters (inputed the normal ALT+numpad way) aren't accepted by QB64, like Qbasic does.... example: input "Type ALT+234: " , a$ print a$, asc(a$) - Dav from IP address 75.181.132.39 |
RE: INPUT doesn't accept ALT+numpad input yet.by (no login)I'll be adding support for this very soon. Thanks for the reminder, I'd forgotten to put this on the todo list. from IP address 58.106.166.186 |
*ALT+numpad charcter input has been implemented for Demo #7by (no login)from IP address 58.106.166.186 |
QB64 Bugs that I posted earlier and are still thereby qbguy (no login)A=064 PRINT A Still prints 48 because C++ thinks its octal. a=3 b=2 PRINT A+++++B PRINT A-----B Still produces a mysterious C++ error -- should print 8 and -2 A = &HFF B = &O64 PRINT A, B Produces an error -- should print 255 and 52. you can't do octal the QBASIC way, but you can do it the C++ way LOL. from IP address 75.9.218.72 |
...and haven't been forgotten!by (no login)I still plan to fix many more bugs before QB64 Demo #7 is released, as listed in a previous post. I didn't list two of the bugs you mentioned i) eg. a=a+++++++b ii) eg. a=064 because if you wrote a program like that in the QBASIC/QB4.5/QBX interpreter the extra +'s and leading 0 would have been automatically removed. So these just aren't a priority atm. As for &Onumber, supporting octal is on the list of things to support for Demo #7, so support for this will be added. Also, there are many known QB64 only (irrelevant for QBASIC source) bugs related to things like using bit-type variables in certain statements. The BUG-fixing focus this month is for bugs you might get compiling programs developed in QBASIC. from IP address 58.106.166.186 |
QB64 BUG: really long variable namesby qbguy (no login)aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab = 20 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaac = 30 PRINT aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab PRINT aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaac In QBASIC, it produces an "Identifier too long" error. In QB64, it compiles. The two variables count as different. AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB=2 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC=2 PRINT AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB, AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC In QB64, it compiles, but the two variables count as the same. In QBASIC, it produces an error. from IP address 75.9.218.72 |
* That should be AAAAA{255 a's}C=3 instead of AAAA{255 a's}C=2by qbguy (no login)from IP address 75.9.218.72 |
QB64 supports longer variable names than QBASIC (more...)by (no login)QB64 supports variable names with up to 256 characters. The compiler currently has very little error checking at compile time, so it doesn't return an "Identifer too long" error for variables longer than this yet. Worth noting, but not a priority atm. from IP address 58.106.166.186 |
QB64 Error handling being upgraded...by (no login)I'm currently working on the (rather boring) task of upgrading QB64's error handling to make it even more like QBASIC. The upgrade will address issues such as: i) Multiple errors being reported for a single command: Example: a=SQR(-1)+SQR(-1)+SQR(-1) In QBASIC: Creates 1 error In QB64: Creates 3 errors! ii) Processing of SUBS/FUNCTIONS with invalid data returned from a previous error calculating one or more of the SUB/FUNCTION parameters. Example: PRINT SQR(-1) In QBASIC: Didn't print anything In QB64: Prints 0 iii) Incorrect handling of errors occurring inside conditional statements: Example: IF SQR(-1)=2 THEN PRINT "QBASIC PRINTS THIS!" In QBASIC: After RESUME NEXT, it prints the message In QB64: After RESUME NEXT, it skips the conditional expression. Furthermore, after RESUME it runs the wrong line of code. There will always be some differences between QB64's error handling and QBASIC's error handling. These are: i) OVERFLOW errors will not happen in QB64 ii) In a line such as: a=SQR(-1) The value of a will be undefined. from IP address 58.106.166.186 |
* ------------------------ "For each programmer, there is an equal and opposite programmer who can't stand to read the first programmer's code." - Snook from IP address 71.102.249.174 |
Error handling upgrade complete (+other interesting info)by (no login)The next focus is implementing OCTAL via the &O prefix This is difficult because (like &H) it can appear in so many different parts of a BASIC program (.BAS CODE, DATA, files being read, input from keyboard, etc.) and requires different checks based on the context it is being used in (so a copy paste doesn't usually suffice). RE: The suggested update to be released tomorrow Don't expect any more updates till I release Demo #7 at the end of this month. The focus of Demo #7 was fixing incompatibilities. So what will be the focus of Demo #8? Implementing user defined types from IP address 58.106.166.186 |
from IP address 12.183.134.76 |
Surprisedby (no login)I compiled a QB45 program with QB64 and it worked great in the QB64 directory. Then I copied the program to another directory, C:\BasicDemos. When I tried to run it there, it was a "no go", as the executable needed companion files, SDL.dll, SDL_mixer.dll, and in a subdiretory, C:\BasicDemos\data, I had to copy from the C:\QB64\data directory five additional files, QB64ICON.BMP, QB64.PAL, QB64EGA.PAL, CHARSET8.RAW and CHRSET16.RAW. I imagine that when Galleon puts out the first installment of QB64 v1.0, it will be possibly to compile standalone EXEs. I am not complaining, just surprised. I think Galleon is doing a great thing in supporting the QB community. He has to have spent hundreds of hours on QB64 so far. Way to go, Galleon! Regards, from a fan of QB64, MarineDon from IP address 68.164.63.184 |
And be thankful Don that it doesn't need the .Net Framework to run!by Pete (Login The-Universe)R If it did, well that would require professional 'file' movers. Those files you mentioned can be freely distributed and I guess that will be needed as part of the QB64 finished project too or am I mistaken? Pete Castle Manager from IP address 70.177.5.114 |
RE: Needing DLLs and DATA folder to accompany the produced .EXEby (no login)The DATA folder is soon to be made obsolete, but there will be functions provided to change the icon etc., perhaps meta-commands. As for the DLL files, QB64 uses open sourced libraries so there is no reason the code for the DLL files couldn't be recompiled as static libraries if they are not provided in that form already. However, one would have to weigh up the benefits vs the disadvantages of doing this very carefully. There is a reason DLL files were invented! from IP address 58.106.166.186 |
------------------ Waiting patiently for Windows 7, XHTML 2.0, CSS 3.0, PHP 6.0, the ratification of C++0x, and the day that I can code without logic troubles. from IP address 12.208.126.190 |
* Pete loves DLL'sby Pete (Login The-Universe)R from IP address 70.177.5.114 |
Unicode and UCASE$by qbguy (no login)If qb64 supports unicode, will it use a font like Courier New (fixed width) or a font like Arial (variable width) (A variable width font would be hard to use with LOCATE). Also, how will UCASE$ work with unicode strings. Like will ſ (long s) become a capital s or stay as a long s? Will é (lowercase E with accent) become É (uppercase e with accent) or will it stay the same? With CP437 strings, accented characters stay lowercase, so it might be weird if unicode and cp437 strings behave differently. Anyway, if we have unicode, we can have chess pieces in SCREEN 0: ♔♕♖ from IP address 75.9.218.72 |
>Anyway, if we have unicode, we can have chess pieces in SCREEN 0: ♔♕♖ Not in full screen "screen 0"... That is restricted by the VGA hardware, unless I am mistaken, to the normal characters. Regards, Michael from IP address 12.183.134.132 |
After all, Windows XP STILL uses code pages instead of just becoming straight UTF-16 (or was it UCS-2?) like the rest of the OS. PowerShell 2.0 is supposed to have Unicode support with its graphical interface, but it still defaults to US-ASCII, where the code page is 1252 (Windows-1252, which is really a modified version of ISO-8859-1, so it ISN'T US-ASCII). Why must Windows be SOOO difficult!? <rant id="Off_Topic"> [Compose] + ` + a = à (lowercase 'A' with a grave accent) [Compose] + ~ + n = ñ (lowercase 'N' with a tilde) It is that easy in Linux once you set up the keys (KDE made this a snap in the Control Center). I usually use the right Alt key (AltGr) as the Compose key. In Windows, I need to install Microsoft Keyboard Layout Creator, the latest version of which has some incompatible features in Windows XP according to the dialog box that pops up each time I launch the program, and then it may not even compile. Once it finally compiles, if it does, the keyboard layout then needs to be installed via the appropriate setup program the compilation process creates (it creates IA-64, i386 (x86) and x86_64 MSI files along with a setup.exe which I can only assume installs the version most appropriate for the platform). Why do I now feel like one of those "Get a Mac" or "Hi, I'm Linux" adverts? </rant> ------------------ Waiting patiently for Windows 7, XHTML 2.0, CSS 3.0, PHP 6.0, the ratification of C++0x, and the day that I can code without logic troubles. from IP address 12.208.126.190 |
Console's now, and consoles in the not too distant futureby (no login)Consoles now: Support multiple pages, colors, locating, etc. depending on what OS you are using. Consoles in the future: ??? The above is why I made QB64 use an emulated SCREEN 0 window, a graphic surface, and not a pure console provided by the OS. QB64 will have a pure console mode soon too, but it will only support simple PRINT, INPUT etc. commands which don't rely on anything but "outing" characters to the console window (note: backspace and CLS are achieved by outing special control characters). Pure console mode shouldn't be relied upon to effect color, locate and pcopy commands correctly. from IP address 58.106.166.186 |
* Will later versions support LOCATE using curses in the future?by qbguy (no login)from IP address 75.9.218.72 |
* Another library for locate in console is conio (URL)by qbguy (no login)http://sourceforge.net/projects/libconio/ from IP address 75.9.218.72 |
Curses uses the move() function while CONIO uses gotoxy() or setxy(), depending upon the implementation. Interestingly enough, there are actually two implementations of CONIO that I know of. There is the one that qbguy pointed out and the other one is known as "CONIO2". CONIO2 distributes their implementation as a DevPak for the Dev-C++ IDE for Windows, but it is only a tarball compressed using a bzip2 utility. Any decent archiving utility can open it right up. I wish these things were open source though. They'd be more useful to me then because I'd be able to cross-compile them. http://sourceforge.net/project/showfiles.php?group_id=115967 ------------------ Waiting patiently for Windows 7, XHTML 2.0, CSS 3.0, PHP 6.0, the ratification of C++0x, and the day that I can code without logic troubles. from IP address 12.208.126.190 |
RE: full screen "screen 0"... That is restricted by the VGA hardwareby (no login)But... QB64 doesn't use hardware SCREEN 0, it uses an emulated window which is a graphical surface. So it will be able to support printing Unicode characters in screen 0. from IP address 58.106.166.186 |
------------------ Waiting patiently for Windows 7, XHTML 2.0, CSS 3.0, PHP 6.0, the ratification of C++0x, and the day that I can code without logic troubles. from IP address 12.208.126.190 |
I wrote a new program that keeps track while you add words to a list, essentially to see how many words you know. It compares your words to the dictionary but/and keeps the words separately if it isn't found. Anyway, I used FREEFILE a lot (well, seven times). I always make sure I use it when working with files. I don't know where it is in your plans but I didn't see it in the README. I'm guessing it'll wait until demo #8 (which is fine), but I was curious. For now, I just assigned each open statement its own number. I also noticed CONST failed (though the README says that), but a) it fails to compile in C++ while passing the conversion step, and b)why? Don't get me wrong, I know I'm not writing qb64, but that seems simple. (though I'm sure you know) CONST qb = 64 const int qb = 64; I guess if the problem is elusive and complex that would explain why it passes conversion but fails to compile. So anyway, what's the status on FREEFILE, demo #8?, and I'm curious about CONST. P.S. With those simple changes (turned CONSTs into variables, hardcoded file numbers) it compiled and runs, though it's slow(er than QBasic, not devastatingly so),,, but I'm sure that'll change. I'm using error handling, inputing from, outputing to, and appending to files, I have two subs, using GOSUBs, basic variables and loops, some arrays (one is two-dimensional), lots of LOCATEing, COLORing, and PRINTing, and last and very nicely handled(on your part) VIEW PRINT (8 TO 25 and the whole screen btw). It took very little effort to make the .exe. Keep up the great work! PhyloGenesis ------------------------ "For each programmer, there is an equal and opposite programmer who can't stand to read the first programmer's code." - Snook from IP address 71.102.249.174 |
Whereas you can do the following: a = 64 'a wasn't DIMmed and DEFINT isn't in effect, so 'a' is a SINGLE b$ = "hello" 'strings require a '$' suffix unless DIMmed you can't do: a = "hello" because you have a type mismatch. With CONST, the issue is different: CONST hexkey = "0123456789ABCDEF" 'valid code It isn't very difficult to deduce the type given that you need to scan for quotes anyway, but I thought I might bring up the issue of non-suffixed strings. Reusing the code for DIM might work if a 'const' property was added to variables or something... That could then be translated to 'const' directly in C++. It's just an idea, and it shouldn't really concern Galleon since he already said Demo #7 will be a bugfix release for those pre-v0.60 bugs (version numbering/demo numbering is confusing to me at the moment, but I'm not exactly myself right now either. :P) rpgfan3233 ------------------ Waiting patiently for Windows 7, XHTML 2.0, CSS 3.0, PHP 6.0, the ratification of C++0x, and the day that I can code without logic troubles. from IP address 12.208.126.190 |
Consts and Dims...by counting (no login)I'm not sure they need necessarily be handled in the same way. The syntax is mutually exclusive in QB: consts require an "= ...", QB dims don't support them. If you want to treat consts as variables, you'd have to add type detection - e.g. 24 is an Integer, 32768 is a Long, "42" is a String, 33000% is invalid, etc. If QB64 is just doing a translation, then it sounds to me like Const evaluation will be tough. It may help though, that const only handles simple expressions in the rhs. No powers or functions. I think it's just +-*\/, mod, relations and bitwise functions. It might be possible write code to evaluate expressions like that to get a literal value, and then do a text substitution in places where it's used. from IP address 86.164.34.141 |
RE: FREEFILE and CONSTby (no login)I'll implement FREEFILE so it is available in Demo #7. CONST could be implemented using C++ DEFINES, but rounding and keeping to the exact way they are used in QBASIC wouldn't be possible. Rather than writing a "hack" version and having to rewrite it I'd prefer to write it properly in the first place. Implemented CONST is a very high priority atm. Consider the following... CONST a=1+1.5# CONST b=a+a DIM c(b) AS INTEGER How many elements are in array c? Is c a static or dynamic array? I'd also like the QB64 compiler to know the value of the CONST variables to make optimization (eg. when range checking the index used to read an array element) easier to implement. from IP address 58.106.166.186 |
> I'll implement FREEFILE so it is available in Demo #7. Sweet, thanks. > CONST could be implemented using C++ DEFINES Why defines? What is the difference between CONST c = 0 and const short int c = 0; ? > Rather than writing a "hack" version... Certainly. (no hack version) > Implemented CONST is a very high priority atm. Yay. :-) > Consider the following... CONST a=1+1.5# CONST b=a+a DIM c(b) AS INTEGER How many elements are in array c? Is c a static or dynamic array? < Five elements, well six considering QBasic uses 0->b rather than 0->(b-1). c is a static array, because it uses a const to define its size. To figure this out, I did: CONST a = 1 + 1.5# 1 + 1.5# is of type double because the 1.5# is a double. CONST a = mydouble# causes a to be (in C++ terms) const double a = 1 + 1.5; CONST b = a + a a is a double, so a + a is a double, so b is a double and equal to 5. Therefore: DIM c(5) AS INTEGER I know b is a double because: d& = b * 8000 CONST e = 5 d& = e * 8000 fails at the last line because e is an integer. > I'd also like the QB64 compiler to know the value of the CONST variables Okay, well this probably wouldn't be hard because you have much of the needed code elsewhere, but it does require a lot more than I was talking about: CONST a = 1 + 1.5# const double a = 1 + 1.5; is easy, but would require more work than the very simple CONST a = 1 const short int a = 1; which requires almost zero effort. Although, do you have a function that takes an expression and determines its return type? PhyloGenesis ------------------------ "For each programmer, there is an equal and opposite programmer who can't stand to read the first programmer's code." - Snook from IP address 71.102.249.174 |
------------------ Waiting patiently for Windows 7, XHTML 2.0, CSS 3.0, PHP 6.0, the ratification of C++0x, and the day that I can code without logic troubles. from IP address 12.208.126.190 |
All recently reported problems have now been fixed!by (no login)QB64 now works under all windows versions and is very stable. (Be sure to have applied the WIDTH patch to V0.63SC) I'll now be focusing on fixing bugs reported before Demo V0.60 was released such as: *paint (...,...) without a color parameter fails *error handling incorrect under certain circumstances *PRINT doesn't print certain control characters yet *certain functions which accept a floating point number always return a DOUBLE precision answer. *exponential bug *octal support (&O) not implemented except for via OCT$(...) Keep those bug reports rolling in, Galleon from IP address 58.106.166.186 |
About the PRINT + control characters...by Dav (no login)This is no big deal to me, but thought you should know about it. Sometimes PRINT CHR$(7) WILL produce the bell sound here, and sometimes not. For example, the following code: for t = 1 to 5 print chr$(7), t sleep 1 next I never hear more than 4 bells, sometimes 3, never 5. And always bell 1 is silent. (This is on my w2k machine). By the way, Great Qbasic combatability so far! My Binary file viewer compiles and works perfect in QB64. It uses DEF SEG/POKE instead of PRINT to show the characters on the screen in SCREEN 0. http://www.qbasicnews.com/dav/files/binview.bas - Dav from IP address 75.181.132.39 |
After 3 bells the fight is over Daveby (Login burger2227)R The sound of a BEEP is actually delaying the sounds of the next ones. Loops move pretty fast! Faster than BEEPS. So you lost some. There are several Control characters that are used for Text formatting that just cannot and should not be printed to the screen. CHR$(13) is one that has no actual character, but some can be shown using special routines. I found one way was to stop a program with Ctrl-Break and restart and run it again from the QB menu. Some old printer Control characters no longer work on newer printers. Ted from IP address 71.60.226.47 |
Heh..by Dav (no login)Well, that make good sense, and it was my 1st thought too. But even doing only this makes no sound... PRINT CHR$(7) SLEEP2 The first beep never sounds. I thought perhaps there may an audio init problem to look in to. I didn't know new printers have ditched to printer control stuff, but hearing about it doesn't surprise me. from IP address 75.181.132.39 |
Like Galleon has mentioned,by (Login burger2227)R Some PRINT Control characters need fixed. These are 1 to 31 ASCII codes. Some are not normally visible. The first 26 are combinations of Ctrl - alphabet letter. That is why they are called control codes. Ted from IP address 71.60.226.47 |
* Could also be a problem with SLEEP. Try a TIMER loop instead.by (Login burger2227)R
from IP address 71.60.226.47 |
* Okay, but can't until tomorrow (got to SLEEP myself now).by Dav (no login)from IP address 75.181.132.39 |
Workaround...by Dav (no login)It works correctly now (they all play) when I put a delay before the first bell, like a SLEEP 2. I guess the auido init takes a sec or two? - Dav from IP address 75.181.132.39 |
INPUT #...,numeric-variable doesn't compileby (no login)The QB64 compiler gives the error that a string variable was expected. This is a bug added when line input was implemented several demos ago that I was unaware of till yesterday when it was brought to my attention. It was a simple cause of removing a rogue line which turned all INPUT # statements into LINE INPUT # statements. I'll hold off releasing an updated version of the compiler till Easter Monday, hopefully there won't be any Easter eggs in QB64! from IP address 58.106.166.186 |
*** Patch to fix WIDTH statement (makes audio.bas run correctly) ***by (no login)The WIDTH statement was causing the problem due to a thread issue. The download below is a patch for Demo V0.63SC. It contains a ~63KB file to replace. Instructions are included on how to apply this patch. The patch will not be required for future versions. http://www.mediafire.com/?sy4bl2m5jf0 from IP address 58.106.166.186 |
------------------ Waiting patiently for Windows 7, XHTML 2.0, CSS 3.0, PHP 6.0, the ratification of C++0x, and the day that I can code without logic troubles. from IP address 12.208.126.190 |
Confirmed by me.by (Login MystikShadows)R Things seem to be smooth now...as far as what is supposed to be fixed. Good work :-) from IP address 69.205.201.142 |