Recent posts

#81

Windows API / Re: Buffer alignment

Last post by sinsi - March 30, 2025, 03:04:09 PM

Misaligning the buffer by 1 and following the code in a debugger I get to NtNotifyChangeDirectoryFileEx.
That fails with HRESULT 80000002 which, funnily enough, is

0x80000002
STATUS_DATATYPE_MISALIGNMENT
{EXCEPTION} Alignment Fault
A data type misalignment was detected in a load or store instruction.

Still not sure why it causes a fault, but I need a break from debugging.

#82

Windows API / Re: Buffer alignment

Last post by zedd151 - March 30, 2025, 01:42:51 PM

Well, nobody has yet answered sinsi's question:

Wonder why align 4 is so important?

Maybe nobody here knows for certain.

My guess®™ is that somewhere in the code for ReadDirectoryChangesW() they explicitly check the buffer alignment, I'm guessing in the interest of speed.

https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-readdirectorychangesw
ERROR_NOACCESS when buffer is not aligned on a dword boundary.

But of course, it does not explain why. 

The ultimate answer: Because Microsoft says so. 
Raymond Chen might know, he seems pretty knowledgeable about MS inner workings.

#83

Windows API / Re: Buffer alignment

Last post by NoCforMe - March 30, 2025, 11:21:41 AM

Well, nobody has yet answered sinsi's question:

Wonder why align 4 is so important?

My guess®™ is that somewhere in the code for ReadDirectoryChangesW() they explicitly check the buffer alignment, I'm guessing in the interest of speed.

Otherwise, how could a function possibly fail if data wasn't DWORD aligned?
Are there any x86/x64 instructions that would fail under that circumstance?

#84

The Campus / Re: Transferring text from sou...

Last post by sinsi - March 30, 2025, 11:04:35 AM

You could also count the string as you copy it, saves a call to lstrlen.

#85

Windows API / Re: Buffer alignment

Last post by LordAdef - March 30, 2025, 10:55:26 AM

The alignment is important because the FILE_NOTIFY_INFORMATION structure is variable in length, because of it's last member FileName.

The other structure members are DWORDs, so you must align at 4 bytes (at least?).

8 byte and 16 byte alignment should also work ?! But this is just a guess by myself.

There was a discussion a couple of years ago about this. Marinus suggested me to align 16  and 32 for performance in a certain code.

I just checked, out of curiosity, and I aligned 32 in the most important loop, and 16 in some other ones. Apart from that, I used 4

#86

The Campus / Re: Transferring text from sou...

Last post by LordAdef - March 30, 2025, 10:51:42 AM

I would add one thing

Code Select Expand

    sub eax, 1
    jnz @B
    mov [esi].char[ebx], al ;<< zero-terminate the destination string
done:
A byte-by-byte copy is fine here since button text is usually not very long

Thanks Sinsi. I was actually, adding the zero termination in my call. But since I am using the length function, I thought that was too much

[Could this be a bug in JWASM v2.14 from Dec 20 2020?]

#87

16 bit DOS Programming / Re: JWASM: ERROR A2030: Instru...

Last post by bugthis - March 30, 2025, 09:30:04 AM

Could this be a bug in JWASM v2.14 from Dec 20 2020? - No, it's still there in the current version.

Thanks for testing.

Instead of an answer, here's the relevant JWasm code ( cpumodel.c ) - or rather the data definitions:

Code Select Expand


#define INIT_LANG       0x1
#define INIT_STACK      0x2
#define INIT_OS         0x4

struct typeinfo {
    uint_8 value;  /* value assigned to the token */
    uint_8 init;   /* kind of token */
};

static const char * const ModelAttr[] = {
    "NEARSTACK", "FARSTACK", "OS_OS2", "OS_DOS" };

static const struct typeinfo ModelAttrValue[] = {
    { STACK_NEAR,     INIT_STACK      },
    { STACK_FAR,      INIT_STACK      },
    { OPSYS_DOS,      INIT_OS         },
    { OPSYS_OS2,      INIT_OS         },
};

A little riddle: can you see the bug just be examining that data?

Yes, either the names are wrong in:

Code Select Expand

static const struct typeinfo ModelAttrValue[] = {
    { STACK_NEAR,     INIT_STACK      },
    { STACK_FAR,      INIT_STACK      },
    { OPSYS_DOS,      INIT_OS         },
    { OPSYS_OS2,      INIT_OS         },
};
and it must be changed as follows:

Code Select Expand

static const struct typeinfo ModelAttrValue[] = {
    { NEARSTACK,     INIT_STACK      },
    { FARSTACK,      INIT_STACK      },
    { OS_DOS,        INIT_OS         },
    { OS_OS2,        INIT_OS         },
};
of the order of OPSYS_DOS and OPSYS_OS2 needs to be swapped.

Code Select Expand

static const struct typeinfo ModelAttrValue[] = {
    { STACK_NEAR,     INIT_STACK      },
    { STACK_FAR,      INIT_STACK      },
    { OPSYS_OS2,      INIT_OS         },
    { OPSYS_DOS,      INIT_OS         },
};
If STACK_NEAR, STACK_FAR, OPSYS_OS2, and OPSYS_DOS are defined somewhere outside of your code snippet, then I suspect the latter.
And ultimately, it could be a combination of both, in which case it would need to be changed as follows:

Code Select Expand

static const struct typeinfo ModelAttrValue[] = {
    { NEARSTACK,     INIT_STACK      },
    { FARSTACK,      INIT_STACK      },
    { OS_OS2,        INIT_OS         },
    { OS_DOS,        INIT_OS         },
};
It's also possible that the wrong values are being assigned. OPSYS_OS2 and OPSYS_DOS are given exactly the same value. Perhaps one of them should be INIT_LANG? INIT_LANG is not used anywhere and it may well be that the value in the struct is used later for differentiation and is therefore dependent on the correctly assigned value. On the other hand, OS/2 and DOS are both operating systems, so the value INIT_OS could also be correct. It just depends on what the rest of the code says.

I guess it's a bug that exists since the very beginning of jwasm - that is 03/2008, so it celebrates its 17th birthday these days.

Great, then I found a bug in JWASM, which can be fixed, and JWASM will have one less bug in future versions.
Unfortunately, I don't have a GitHub account and therefore can't create a bug report. If you could report the bug to the developers, that would be great.

#88

Windows API / Re: Creating menus dynamically

Last post by NoCforMe - March 30, 2025, 09:06:26 AM

A bit off-topic but I don't like resources due to the fact that it is easy to change them (BeginUpdateResource etc.)
Anything from a practical joke (hah, this menu says "shit" lol) to nasty (infected images).

Well, here's another small advantage I see to not using resources in this case (menus):
If you use a resource editor, you need to duplicate the IDs attached to each menu item by copying them from your code to the resource file (or vice versa).
And if you change them in one place you have to change them in the other to keep them in sync.
I was going to say you could put them in an include file, but you can't, as the resource compiler only recognizes C header files, not assembly-language EQUs. (You can use include files in C/C++.)
With this method there's only one set of IDs and they're right in the source code.

#89

Windows API / Re: Creating menus dynamically

Last post by NoCforMe - March 30, 2025, 09:02:41 AM

Scroll down to see what TPM_VERNEGANIMATION does. "Animates menu from bottom to top". Probably works fine without it.

Probably.

Heh; makes me wonder how much stuff like this is in my code that although it works OK, could do without it (or might actually be better done without).

Or conversely, how much of my code works OK but would be better if some small thing was added.

#90

Windows API / Re: Creating menus dynamically

Last post by zedd151 - March 30, 2025, 08:55:56 AM

A bit off-topic but I don't like resources due to the fact that it is easy to change them (BeginUpdateResource etc.)
Anything from a practical joke (hah, this menu says "shit" lol) to nasty (infected images).

Then again it's easy to change any strings with a hex editor, whether it is in resources or not. If a hacker/spammer/script kiddie is determined enough, not a lot can be done to stop them entirely, if that is the type of thing that you are talking about.