flat assembler
Message board for the users of flat assembler.

Index > Windows > [BUG] api/shell32.inc doesn't include StrStr and StrStrI

Author
Thread Post new topic Reply to topic
SFeLi



Joined: 03 Nov 2004
Posts: 140
Location: Severodvinsk, Russia
SFeLi
Import macro from api/shell32.inc doesn't define StrStrA/W and StrStrIA/W imports, but api macro in the same file mentions both StrStr and StrStrI, so fasm gives an 'undefined symbol' error when trying to call one of these functions. Adding
Code:
       StrStrA,'StrStrA',\
       StrStrW,'StrStrW',\
       StrStrIA,'StrStrIA',\
       StrStrIW,'StrStrIW',\
    

to api/shell32.inc at line 116 would fix that.
Post 20 Aug 2010, 11:18
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
mindcooler



Joined: 01 Dec 2009
Posts: 423
Location: Västerås, Sweden
mindcooler

_________________
This is a block of text that can be added to posts you make.
Post 20 Aug 2010, 12:32
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
CONFIRMED, this is a bug.

mindcooler, it is not the same case, here referring to StrStr succeeds, but later there is a fail inside the package-provided include files for doing this (i.e. the error generated for doing "alpha = StrStr" is quite different to that of "alpha = StrStrfuihwh23vbiugu").
Post 20 Aug 2010, 14:05
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
Actually this is part of a wider problem with the import macros. Some macros support only Win95 functions and others support later API functions. Adding StrStr means you lose the ability to safely compile for Win95.

IMO there should be a separate set of API macros for the various API versions. 95, 98, ME, NT, 2K, XP, Vista, 7. That way is becomes absolutely clear about which version of Windows the code is designed to support.
Post 31 Aug 2010, 02:16
View user's profile Send private message Visit poster's website Reply with quote
ziral2088



Joined: 16 Aug 2009
Posts: 15
Location: Ukraine
ziral2088
maybe stop supporting Win 95-ME ?
Cant find even where to look for PC with Win 95 or ME.
2k+ support is a good idea.
Post 31 Aug 2010, 05:48
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
IMO there should be a separate set of API macros for the various API versions. 95, 98, ME, NT, 2K, XP, Vista, 7. That way is becomes absolutely clear about which version of Windows the code is designed to support.
Since fasm itself doesn't cut you out from the instructions for processors newer than those you program for, it would not be in the same spirit to make such thing for WinAPI. The idea is: just provide them all, programmer should know what he uses anyway. However myself I don't do any word in the direction of increasing this completeness for Win32/Win64 headers - I really hoped for this project to succeed in this area.
Post 31 Aug 2010, 08:28
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
Tomasz Grysztar wrote:
Since fasm itself doesn't cut you out from the instructions for processors newer than those you program for, it would not be in the same spirit to make such thing for WinAPI.
Which reminds me, I really must get back to this project and update it for usage similar to the way that fasmarm selects the target CPU.
Tomasz Grysztar wrote:
The idea is: just provide them all, programmer should know what he uses anyway.
Unfortunately this is becoming increasingly hard for the programmer to know which-CPU-supports-what. There is such a large variety now, and the variety is continually increasing. I think the best place to do the detection is by the assembler.
Post 31 Aug 2010, 08:58
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
Unfortunately this is becoming increasingly hard for the programmer to know which-CPU-supports-what. There is such a large variety now, and the variety is continually increasing. I think the best place to do the detection is by the assembler.
I had an exactly opposite impression - that nowadays processor are able to mix so many different abilities and inabilities (just look at amount of such bits that CPUID returns) that any such system would only create more trouble rather than really help. If I wanted to use any AES instruction, I would also need to remember how the AES-enabling directive is called for the environment I use in addition to knowing the instruction names (which are standard). Thats unnecessary complication in my view.
Post 31 Aug 2010, 09:41
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
Tomasz Grysztar wrote:
I had an exactly opposite impression - that nowadays processor are able to mix so many different abilities and inabilities (just look at amount of such bits that CPUID returns) that any such system would only create more trouble rather than really help. If I wanted to use any AES instruction, I would also need to remember how the AES-enabling directive is called for the environment I use in addition to knowing the instruction names (which are standard). Thats unnecessary complication in my view.
The reason is because it is so easy to make a mistake. Just the SSE/SSE2 overlap is hard to remember properly, I have seen many examples posted in this board by myself and others where we have forgotten that some instruction is only SSE2+ even though it works on single precision values.

Did you see how I did it for fasmarm? I used a bitmap to define the current processor set of available instructions. Using symbolic names for the bits helps a lot. And the programmer only has to get it right once during the initial coding and then the assembler will check all following instructions and catch any inadvertant mistakes.

With an assembler that does no checks, when going back to old code and trying to change it, this is a prime time when "bad" instructions get included. And testing on a more capable CPU won't expose the error. It is only when the target users start running it and then complain about it crashing that the problems are exposed.

Programming for a lessor CPU than what the programmer currently uses is very problematic when relying in just the programmer's own restraint and memory.
Post 31 Aug 2010, 10:01
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
It is not that I see any problem with implementing such thing - I just don't see a reason. I never liked those directives and don't like them still.
It is like having to mark the procedure boundaries with "proc" and "endp", because the recommended way of programming is to have them as separated pieces of code. But assembly program may not fit into such boundaries. If they are implemented as additional macros, they I'm OK with it - and same goes for other such limitations, as instruction set ones. I had 8086.INC as a separate (one might say: exiled) macro package since almost the first releases of fasm. You can then even have macros emulate unavailable instructions for you - like 8086.INC did with SHL r/m,imm8 with imm8>1.
Post 31 Aug 2010, 10:25
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
Using macros is one way to solve, but it is also very space inefficient (uses lots more memory) and makes assembling slower (up to 10 times slower in many instances).

So for the original topic here, would you be okay with having multiple sets of API macros (or some other selection method) to allow for 95, 98, etc. API separation? If so, how would someone submit that for inclusion into the fasm download? Or would it always have to be a separate download?
Post 31 Aug 2010, 10:42
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
Using macros is one way to solve, but it is also very space inefficient (uses lots more memory) and makes assembling slower (up to 10 times slower in many instances).
That's why fasm core is made simple and quite fast so that you can do some heavy macro customizations and still have a "finite" compilation time. Wink
And I'm OK with people having to pay some price for the features I personally dislike. Twisted Evil

revolution wrote:
So for the original topic here, would you be okay with having multiple sets of API macros (or some other selection method) to allow for 95, 98, etc. API separation? If so, how would someone submit that for inclusion into the fasm download? Or would it always have to be a separate download?

It would have to be the part of the project I linked to. I must confess that I don't know who is responsible for it right now. I leave it up to you.
Post 31 Aug 2010, 11:18
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
On second thought, I might still convince myself to implement some instruction set restrictions as an optional directives that wouldn't restrict anything unless you used them (so default would still be "everything allowed", as it is now).
However the fact that there is a set of macros that does the job well, does not encourage me to consider it as something worth effort. You know already that I love to have as much as possible implemented as macros (BTW, do you know LaTeX? Wink). And fasm 1.x has this flaw in its architecture that any keyword must be disallowed globally for assembly-time defined symbols (which is another reason for trying to avoid introducing new keywords [another BTW: I think it was a bad choice to introduce "note" as a keyword type of segment in ELF executable]; I myself have some programs where I had to rename the "note" label because of this).
Post 01 Sep 2010, 11:49
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
Tomasz Grysztar wrote:
On second thought, I might still convince myself to implement some instruction set restrictions as an optional directives that wouldn't restrict anything unless you used them (so default would still be "everything allowed", as it is now).
However the fact that there is a set of macros that does the job well, does not encourage me to consider it as something worth effort. You know already that I love to have as much as possible implemented as macros (BTW, do you know LaTeX? Wink). And fasm 1.x has this flaw in its architecture that any keyword must be disallowed globally for assembly-time defined symbols (which is another reason for trying to avoid introducing new keywords [another BTW: I think it was a bad choice to introduce "note" as a keyword type of segment in ELF executable]; I myself have some programs where I had to rename the "note" label because of this).
I used two keywords for fasmarm: PROCESSOR and COPROCESSOR. And at startup they both default to everything-is-allowed to allow for backward compatibility. For x86 one could use: PROCESSOR, or FEATURES? Or perhaps CAPABILITY? EXECUTIONSET? INSTRUCTIONSET?

I don't know LaTeX. Is this related to assembly instruction sets? I thought it was a text layout language?

If you do decide to do it in some restricted form then targeting 286-and-lower vs 386-and-higher would be a good start. The long jumps need special attention when writing for 286 (and lessor) CPUs. Without the macros the programmer has no opportunity to force fasm to create the correct jump code.
Post 01 Sep 2010, 12:15
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
For x86 one could use: PROCESSOR, or FEATURES? Or perhaps CAPABILITY? EXECUTIONSET? INSTRUCTIONSET?
What about parameters specifying the various capabilities? I'd prefer not to use numerical values.

revolution wrote:
I don't know LaTeX. Is this related to assembly instruction sets?
It is related to the idea of heavy macro-based customization of otherwise simple language.

revolution wrote:
Without the macros the programmer has no opportunity to force fasm to create the correct jump code.
That's exagerration, it is enough to write jumps like "JE SHORT", etc.
Post 01 Sep 2010, 12:17
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
Tomasz Grysztar wrote:
revolution wrote:
For x86 one could use: PROCESSOR, or FEATURES? Or perhaps CAPABILITY? EXECUTIONSET? INSTRUCTIONSET?
What about parameters specifying the various capabilities? I'd prefer not to use numerical values.
But then you get back to the problem of keyword overlap with program labels. I also considered how to make the directives use textual parameters but couldn't come up with any suitable solution.
Tomasz Grysztar wrote:
revolution wrote:
Without the macros the programmer has no opportunity to force fasm to create the correct jump code.
That's exagerration, it is enough to write jumps like "JE SHORT", etc.
Okay, you are right. But using SHORT limits the range terribly. And on these smaller CPUs space/time is usually of a premium so making all jumps as JnCC SHORT $+5/JMP LONG TARGET is not efficient. Macros are the only practical way to get efficient (and correct) jump encoding.
Post 01 Sep 2010, 12:27
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
I also considered how to make the directives use textual parameters but couldn't come up with any suitable solution.
It is possible with some dedicated parsing, like the ones EXTRN has. In fact, I could even try to do such parsers for SEGMENT/SECTION directives and make all those keywords like READABLE no longer a global ones. Might be a good idea, I'm adding it to my TODO list.

Tomasz Grysztar wrote:
And on these smaller CPUs space/time is usually of a premium so making all jumps as JnCC SHORT $+5/JMP LONG TARGET is not efficient. Macros are the only practical way to get efficient (and correct) jump encoding.
And the restricting directives would not help you here (as they would restrict you in the same way as if every such jump had "short" type specified)- you'd still have to write macros. There would be no equivalent of TASM's JUMPS feature for the same reason that there is no LEA->MOV optimization in fasm (there was some long discussion about it back in 2004).
Post 01 Sep 2010, 12:35
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
Tomasz Grysztar wrote:
And the restricting directives would not help you here (as they would restrict you in the same way as if every such jump had "short" type specified)- you'd still have to write macros.
They would help because at least the programmer will get a compile error. IMO it is much better to get an error at compile time rather then generate code that the CPU cannot execute. With the error the programmer is alerted to the fact that they need to do something else to make the code work.
Post 01 Sep 2010, 12:47
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
They would help because at least the programmer will get a compile error.
The same error you get when you use SHORT keyword. I was answering to your argument that SHORT is not enough.

I'm going to stay with macros - this way you choose/modify them freely and add any instruction optimizations you want. And all those options could then be developed by people working on that "packaging project" - which I still hope to succeed one day.
Post 01 Sep 2010, 12:49
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.