Recent posts

#11

Game Development / Re: 4x4 Game

Last post by zedd151 - March 31, 2025, 05:16:42 PM

Some information regarding puzzle games of this type: https://en.m.wikipedia.org/wiki/15_puzzle

The information regarding solvability reaffirms that my method of guaranteeing that each random puzzle produced by my program is solvable, is sound. I start with a solved puzzle and randomly scramble it using valid moves.

You cannot just randomly place the 15 tiles and expect the puzzle to be solvable. As I stated earlier, 50% of all games generated by random placement only, will be unsolvable.

Also there are several different names for this type of puzzle, btw. 

I never knew (or had forgotten) what it was originally called, so I named my version of it simply "4x4". I only remember that they were given out at children's birthday parties as party favors (as well as other very cheap toys) when I was a youngster.
It was a plastic toy maybe 3 1/2 inches square and maybe a quarter inch thick. With interlocking numbered (1-15) sliding tiles, so they wouldnt fall out, or the player could win by simply taking out the tiles and putting them in solved order rather than actually trying to solve it by sliding the tiles.

I have also recently found that some call it a "sliding number puzzle".

#12

Windows API / Re: Buffer alignment

Last post by NoCforMe - March 31, 2025, 04:29:27 PM

Thanks for the excellent explanation.

#13

Windows API / Re: Buffer alignment

Last post by adeyblue - March 31, 2025, 03:52:38 PM

Again: was that an actual hardware fault caused by a CPU instruction, or something somehow generated by the Win32 function? (Or a hardware fault that was caught by C++ code?)

Code Select Expand

if((ULONG_PTR)buffer) & 3)
{
    ExRaiseDataytpeMisalignmentException();
}
That's what happens in the kernel for pretty much every native function that takes a struct parameter.
You don't see it often fail like that in 32-bit apps on 64- because if you send in misaligned buffer, you're only sending them to WoW, and WoW will call the kernel without dodgy buffers. With native bitness apps, it's pretty easy to do. Like the struct passed to VirtualQuery for instance, that needs 8 alignment on 64-bit because the first member of the struct is a pointer rather than a dword like the struct for ReadDirectoryChangesW.

As for why, this:

To detect misaligned memory accesses, perhaps? Those cause performance penalties

NT has been ported to loads of different architectures, it doesn't just run on PCs. Some of those don't do misaligned memory reads (Itanium for one) . Every platform does aligned reads, so you write one check to make sure the buffer is aligned and then you don't have to care about what the platform does if it isn't.

#14

Windows API / Re: Buffer alignment

Last post by NoCforMe - March 31, 2025, 02:30:50 PM

Seems to me (unless I'm quite wrong here) that Micro$oft is being a bit anal by penalizing the caller for having a misaligned buffer.

For Windows Apps alignment check is off in MS Windows - I guess, too many apps would crash if it's on.

But but but ... now we're back to square one:
If that's true, then why did sinsi get a fault back there in this post (#5)?
Again: was that an actual hardware fault caused by a CPU instruction, or something somehow generated by the Win32 function? (Or a hardware fault that was caught by C++ code?)

Very confused here ...

#15

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

Last post by zedd151 - March 31, 2025, 02:24:00 PM

Hi,zedd151

This is the 21st century. DOS is still stuck in 1980ish, imo. I just don't get it... at all.

Nowadays, most industrial automation control systems still use 16bit CPU.

I did not (obviously) know that. Thank you six_L. 
I wouldn't think though, that they are conceivably running MS-DOS or a derivative. More likely a different proprietary OS, designed specifically for the task.

#16

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

Last post by six_L - March 31, 2025, 02:22:38 PM

Hi,zedd151

This is the 21st century. DOS is still stuck in 1980ish, imo. I just don't get it... at all.

Nowadays, most industrial automation control systems still use 16bit CPU.

#17

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

Last post by bugthis - March 31, 2025, 02:06:28 PM

No, those makefiles all run fine in DOS, but need the HX DOS extender ( and the extender's HXLDR32 TSR loaded ). Additionally, I guess the DOSLFN TSR must be loaded to activate LFN support.

Couldn't you adapt the Makefile so that it can also be compiled on an 8086 or 286 on a FAT16 file system without LFN support? LFN support is also only available starting with MS-DOS 7.0, which is included with Windows 95b.
It would be a pity if you couldn't "bootstrap" the 16-bit Real Mode JWASM binary on a 16-bit x86 machine.

#18

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

Last post by _japheth - March 31, 2025, 01:31:48 PM

To fix some of the above errors in the OWDOS16.mak and possibly also OWDOS32.mak Makefile, the following corrections must be made:

No, those makefiles all run fine in DOS, but need the HX DOS extender ( and the extender's HXLDR32 TSR loaded ). Additionally, I guess the DOSLFN TSR must be loaded to activate LFN support.

[exception]

#19

Windows API / Re: Buffer alignment

Last post by _japheth - March 31, 2025, 01:26:01 PM

So, are you saying that this exception must be enabled by setting those bits? otherwise it won't occur?

Yes.

Why would anyone do such a thing?

To detect misaligned memory accesses, perhaps? Those cause performance penalties.

Seems to me (unless I'm quite wrong here) that Micro$oft is being a bit anal by penalizing the caller for having a misaligned buffer.

For Windows Apps alignment check is off in MS Windows - I guess, too many apps would crash if it's on.

And I forget just which rings things execute in: does the kernel run in ring 3?

No, your app runs in ring 3, the kernel in ring 0.

#20

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

Last post by bugthis - March 31, 2025, 12:14:24 PM

To fix some of the above errors in the OWDOS16.mak and possibly also OWDOS32.mak Makefile, the following corrections must be made:
1. Using an editor with Search & Replace function, all strings named "BINNT" must be replaced with "BINW". The reason is that the Open Watcom compiler and linker are located in the BINW directory in DOS, not in the BINNT directory. This applies in particular to the OpenWatcom package from FreeDOS.

2. Next, at the very beginning of the Makefile, the entry

Code Select Expand

!ifndef WATCOM
must be replaced with

Code Select Expand

!ifndef %WATCOMOtherwise, the Makefile cannot access the DOS environment variable WATCOM. It's important that there is no % sign at the end of the entry; this would be different in a normal DOS batch file.

3. The same steps will likely need to be performed for the

Code Select Expand

!ifndef DEBUG entry directly below, replacing it with

Code Select Expand

!ifndef %DEBUG if you want to reference a DOS environment variable named DEBUG here.
The same applies to the !ifndef TRMEM entry.

If you do that, the E14 error will at least point to the correct directory where WCC.EXE, WLINK.EXE and WLIB.EXE is located.

Code Select Expand

Error(E14): Cannot execute (\binw\wcc): Argument list too big
Unfortunately, the argument list is still too long. I don't know how to fix this error. I'm not familiar enough with Watcom Makefiles and it could also be related to DOS and its maximum line length.