Index
> Main > Fasm won't compile |
| Author |
|
|
Vortex 25 Nov 2003, 10:00
Hi Klod,
All what you need to do is to type the following statement at the DOS command prompt.(similarly, yo can create also a batch file containing this instruction) Code: set include=c:\fasmw\include _________________ Code it... That's all... |
|||
25 Nov 2003, 10:00 |
|
|
Tomasz Grysztar 25 Nov 2003, 12:36
Is the "'c:\fasmw\include" a valid path for the include files (that is where you have extracted the archive)? Because all the rest (what have you added to the .ini file) seems to be OK.
|
|||
|
25 Nov 2003, 12:36 |
|
|
fasm9 25 Nov 2003, 13:21
Hi, admin
BTW, is there any other way to avoid this problem? is this possible? say, all files in one directory but no sub directory, so make fasmw.exe assume *.inc with him. -- Code: using System; class helloworld{static void Main(){Console.WriteLine("hello world");}} |
|||
|
25 Nov 2003, 13:21 |
|
|
Rotator 09 Dec 2003, 17:45
I have the exact same problem. I have tried everything. Nothing works.
And yes Privalov I am using VALID paths for the include files. No matter what I do with the ini file, I still get the same problems. Fasm won't compile. Hey Privalov, how about fixing this stupid problem instead of adding new features all the time? |
|||
|
09 Dec 2003, 17:45 |
|
|
Tomasz Grysztar 09 Dec 2003, 18:18
Are you using fasm or fasmw version? For the console version you need to set standard environment variable.
|
|||
|
09 Dec 2003, 18:18 |
|
|
Czubin 09 Dec 2003, 18:30
Try this : control panel > system : advanced : enviroment variables
Add a system variable : fasminc > C:\fasmw\include and reboot your computer , that did solves the problem for me |
|||
|
09 Dec 2003, 18:30 |
|
|
i-don 13 Dec 2003, 21:24
Same source code but different directory
Fasmw v1.50 seem has wierd/strange behaviour while compile a source code. I've compile an example from this forum and place the file under \examples directory. when I compile it, it ok. Then I place the same source code 1 level down under \examples to a new directory named \directory\intro . When I compile it, it produce an error "illegal instruction" for the line 1 of start: entry. here is the code: Code: format PE GUI 4.0 entry start include '%include%\win32a.inc' start: mov esi,user mov edi,wc macro invoke proc,[arg] {common invoke esi+proc-user,arg} virtual at edi ediwc WNDCLASS end virtual invoke GetModuleHandle,ebx mov [ediwc.hInstance],eax invoke LoadIcon,0,IDI_WINLOGO mov [ediwc.hIcon],eax invoke LoadCursor,0,IDC_ARROW mov [ediwc.hCursor],eax xor eax,eax mov [ediwc.style],eax mov [ediwc.lpfnWndProc],WindowProc mov [ediwc.cbClsExtra],eax mov [ediwc.cbWndExtra],eax mov [ediwc.lpszMenuName],eax mov [ediwc.hbrBackground],COLOR_BTNFACE+1 mov ebx,_title mov [ediwc.lpszClassName],ebx invoke RegisterClass,edi invoke CreateWindowEx,0,ebx,ebx,WS_VISIBLE+WS_DLGFRAME+WS_SYSMENU,64,64,127,127,NULL,NULL,[ediwc.hInstance],NULL mov ebx,msg msg_loop: invoke GetMessage,ebx,NULL,0,0 or eax,eax jz end_loop invoke TranslateMessage,ebx invoke DispatchMessage,ebx jmp msg_loop end_loop: invoke ExitProcess,0 proc WindowProc, hwnd,wmsg,wparam,lparam enter push esi mov esi,user cmp [wmsg],WM_DESTROY je wmdestroy invoke DefWindowProc,[hwnd],[wmsg],[wparam],[lparam] jmp finish wmdestroy: invoke PostQuitMessage,0 xor eax,eax finish: pop esi return data import library kernel,'KERNEL32.DLL',\ user,'USER32.DLL' import kernel,\ GetModuleHandle,'GetModuleHandleA',\ ExitProcess,'ExitProcess' import user,\ RegisterClass,'RegisterClassA',\ LoadIcon,'LoadIconA',\ LoadCursor,'LoadCursorA',\ CreateWindowEx,'CreateWindowExA',\ DefWindowProc,'DefWindowProcA',\ GetMessage,'GetMessageA',\ TranslateMessage,'TranslateMessage',\ DispatchMessage,'DispatchMessageA',\ PostQuitMessage,'PostQuitMessage' end data _title db '1024',0 msg MSG wc WNDCLASS Fasmw Environment If it's about the %include% environment, I've put an addition statement in fasmw.ini file to make it compatibility with previous version source code files (as example below): Code: [Environment] Include=c:\Fasmw\include Fasminc=c:\Fasmw\include Long file name Seem fasmw goes 16 bit on file management. when I compile a file with a name such as longfilename.asm, it will produce longfil~1.exe. On previous version (1.49) this does not happening to me. Resource handling unstable I've the same menu resource on other files and it's compile ok but in a few other files, it wouldn't compile and produce the same "Illegal instruction" like the above problem. see code below: Code: section '.rsrc' resource data readable directory RT_MENU, menus resource menus,\ IDM_MAIN,LANG_ENGLISH+SUBLANG_DEFAULT,main_menu menu main_menu menuitem '&PopUp',0,MFR_POPUP menuitem '&Say Hello',IDM_HELLO,0 menuitem 'Say &Goodbye',IDM_GOODBYE,0 menuseparator menuitem 'E&xit',IDM_EXIT, MFR_END menuitem '&Help', IDM_TEST,MFR_POPUP + MFR_END menuitem '&Test...',IDM_TEST,MFR_END hope you'll look into these problem. the compiler errors were too much noticing on un-neccessary so-called "Illegal". Hope this report will help you to rectify the bugs. greetings. [/code] |
|||
|
13 Dec 2003, 21:24 |
|
|
Tomasz Grysztar 13 Dec 2003, 23:11
I was not able to reproduce any of such behaviours. What system are you using?
|
|||
|
13 Dec 2003, 23:11 |
|
|
i-don 14 Dec 2003, 17:11
I'm using win95ocr2.
Now I'm understand why it wont compile. I was save the copy of the file using a text editor that convert all TAB characters to equivalent to TAB lenght with WHITESPACE characters. For subject "same code but different directory" and "Resource Handling unstable" was the same problem, I think. See attached screenshots. When I change to TAB, the error goes to the next line. To get simulate the problem, put whitespace to replace TAB in first instruction in (start:) section: Code:
mov esi,user
; ^-----^--- use white space instead,
; you will get the error.
Imagine, if I have to replace back all the WHITESPACE with TAB characters on long source code? It's quite a works! greetings.
|
|||||||||||||||||||
|
14 Dec 2003, 17:11 |
|
||||||||||||||||||
|
Tomasz Grysztar 14 Dec 2003, 17:46
What character do you mean by WHITESPACE? Fasmw will put spaces instead of tabs when you turn off "Optimal fill on saving options" and it will convert spaces into tabs where possible when you turn it on, but it both cases fasm compiles source without any problems.
Perhaps you should post your source files here, so I could take a look at them. It seems that your editor had put there the characters that are non-standard spaces. |
|||
|
14 Dec 2003, 17:46 |
|
|
i-don 14 Dec 2003, 19:08
WHITESPACE is the normal space character (spacebar). Turning ON or OFF on "Optimal fill on saving" does not given any effect after compiling the saved file.
BTW, take a look at the attached source code files for both problem.
|
|||||||||||||||||||||
|
14 Dec 2003, 19:08 |
|
|
Tomasz Grysztar 14 Dec 2003, 19:44
In the first source there are characters of code 0xA0 among the spaces - you can check it in any hex editor. They look like a space, but are definitely not spaces - what program did this?
You can fix your source by copying one such character into clipboard and then using "Replace" function of fasmw to replace all occurences of that character with regular space. And in the second one you just forgot to put the MFR_END in the last item, it should be: Code: menu main_menu
menuitem '&PopUp',0,MFR_POPUP + MFR_END
menuitem '&Say Hello',IDM_HELLO,0
menuitem '&Clear',IDM_CLEAR,0
menuitem '&Get Text',IDM_GETTEXT,MFR_END |
|||
|
14 Dec 2003, 19:44 |
|
|
i-don 14 Dec 2003, 22:41
I guess it's not a bugs entirely except incompatibility with the differences of WHITESPACE(ANSI hex:A0) I guess. It was fixed using replace tool. Thanks for the solutions.
I'm using Arisesoft Winsyntax Editor. Quite useful for me while browsing the Internet, because it has intergrated handy files manager with top[folder]-bottom[files] style oppose to window explorer which is using right[folder]-left[files] style. This feature are very good for limited screen view size also included the favourites folder for quick jump (see pic). I would updates source code from forums if there any changes with easy. I've no problem on other compiler like basic and c compiler on files that save using this editor. they compile without complaint about those characters (0xA0 or &hA0 or $A0 or A0h). And for the menu, I admitted this is human mistakes.  since I'm just learning ASM using FASM(great tool for learning asm), I have no idea where the mistake has actually occured and the error line just too short to figure out where exactly the problem. still, I was fooled by the error messages. so I kept scratching my head why the error hilighting on "menu main_menu" line every time change has been made.
could we have extended error messages in the error dialog box to show the group lines of section where the errors were possibly happened? With added scrollbars if neccessary? This would be wonderful to any typo/mistakes would be fixed easily for newbie like me. for example, it would hilight a group of lines where from begin to end of possible mistakes that caused the error instead of a single line. Just a suggestion. 
greetings.
|
||||||||||
|
14 Dec 2003, 22:41 |
|
|||||||||
|
Tomasz Grysztar 14 Dec 2003, 23:29
Well, fasm can be easily fixed to interpret 0xA0 as space character, though I have never heard that this is some kind of standard. The only file you have to change is the PREPROCE.INC. At the line 1441 you should find the following data:
Code: symbol_characters db 27 db 9,0Ah,0Dh,1Ah,20h,'+-/*:=|&~()[]<>{},;\#`' Change it to: Code: symbol_characters db 28 db 9,0Ah,0Dh,1Ah,20h,0A0h,'+-/*:=|&~()[]<>{},;\#`' Now there are some places where preprocessor recognizes spaces, and you have to add the check for 0A0h character there. First is after the "convert_line_data" label (about the 86 line). There is such piece of code: Code: convert_line_data: cmp edi,[memory_end] jae out_of_memory lods byte [esi] cmp al,20h je convert_line_data cmp al,9 je convert_line_data After adding a check for 0A0h character it should look like: Code: convert_line_data: cmp edi,[memory_end] jae out_of_memory lods byte [esi] cmp al,20h je convert_line_data cmp al,0A0h je convert_line_data cmp al,9 je convert_line_data The next change should be after the "symbol_character" label, about the 137 line: Code: symbol_character: cmp al,3Bh je ignore_comment cmp al,5Ch je concatenation_character Add the following two lines just after the above code: Code: cmp al,0A0h je convert_line_data And the last check is at the "concatenate_lines" label: Code: concatenate_lines: lods byte [esi] cmp al,20h je concatenate_lines cmp al,9 je concatenate_lines add to it the following two lines: Code: cmp al,0A0h je concatenate_lines I suggest to do all the above changes with FASMW, this way you'll be sure you won't get any 0A0h characters in code at this stage. Now recompile the fasm, and it should accept any 0A0h-spaces in your sources. As for the "menu" macro - yes, it can be made better, with ability to display appropriate message with "display" directive when some mistake like yours occurs, when I have some time, I'll have to rewrite all the resource macros, as they were written very quickly in a very simple form just to show that such things as resources can be generated with macros. But now fasm also has the ability to link the .res files generated by resource compiles (it's a new feature of fasm 1.50) - maybe you'll find that way of making resources more handy? |
|||
|
14 Dec 2003, 23:29 |
|
|
i-don 15 Dec 2003, 12:23
Working like a charm! thanks Privalov! I'll keep the above notes for future version of fasmw if it's not include this character control. at least, it serve my purpose well. hope my learning process speeding up so I can contribute to the fasm community too.
cheers. |
|||
|
15 Dec 2003, 12:23 |
|
< Last Thread | Next Thread > |
Forum Rules:
|