So on a 3 hour car ride I decided to try a bunch of these; tested Unit ID 3850-3915 for Player 9, they seem to work for any player 9+ (started with the random Unit ID choice of 3886).

All of the Non-Crashing ones showed a unit which made an invisible wall. The wall is very wide and only a pixel tall.

If the unit is visible then the wall can be destroyed, so you can make a destructible, mostly invisible, wall. Or you can make them invincible (by checking the invincible box). Better yet you can use the completely invisible units to form "perfect" invisible walls if you come across the need.

Interesting tidbit, if a unit is in range of the wall, (which is a very wide area) he can attack it, so you see the animation hit the center unit of the wall from a far distance (as you can see when modding unit range)

You can also make the unit a hallucination, and the wall will disappear like a regular hallucination would.

Most Useful:
Player Unit ID Effect
9 3908 Invisible Wall (cannot be attacked)
9 3889 Interceptor Wall (can be attacked, but never dies) (Crashes if selected!)
9 3900 Assimilator Wall (dies easy) (Crashes if selected!)
9 3904 Gateway (not a wall, sprite-like, can be walked on, attacked/destroyed)

Screen Shots



Full Log (if effect is a dash, that means it crashed)


More Details:


Works on: Windows XP, Windows 7
Doesen't work on: Windows 7x86
Not tested on: Vista, Earlier windows, Mac, Windows based lunix

Manipulated factors: Player# (9+), Unit ID, Invincibility, Hallucinated, Map Position (must not be near left/right edge)
Non-factors (won't have effect): Unit Index
Not-tested: Unit Health, Multiple Extended Units

Post has been edited 18 time(s), last time on Dec 27 2011, 6:22 pm by jjf28.

Screenshots? What OS are you running, as that probably matters.

This was done on Win XP, tested it, doesen't work on x86 win7 pc's

Gettin the screenies

Post has been edited 3 time(s), last time on Jun 20 2011, 5:40 am by jjf28.

That seems like a neat thing you found there, but if it's only supported on XP, the practicality has just plummeted. I like the Dragoon shots especially.

x86 win7's run nothing anyways, if someone could test for x64 i'd appreciate it found one

Post has been edited 2 time(s), last time on Jun 21 2011, 2:42 am by jjf28.

The OS does not matter. If it runs Starcraft.exe then the data layout is the same. Always.
If the data changes then that's up to Starcraft and not the OS.

Starcraft is a 32-bit application and even if you run a 64-bit system, it doesn't matter when it's only using the 32-bit subsystem.

Then why does the memory layout of SC change depending on the operating system? It doesn't really matter if it is was the OS or SC that made the memory change, the fact is the memory is different on different operating systems.

As my understanding goes, x64 and x32 are basically the same, x64 just has higher RAM limits, so I wouldn't count those as different or expect any change in this sort of thing. But x86 has changes to the way in which programming works including memory architecture that in many cases is ment to prevent buffer overflows and similar security risks posed by C and C++ - which I why, I assume, this doesen't work on my x86 PC.

For a test I ran this map from starcraft off my flashdrive on four different computers, a Win XP x32, Win XP x64, Win 7 x64, and Win 7 x86, it worked identically on the first three, but crashed on the windows 7 x86, it also showed different memories being referanced in starcrafts crash message when I tried some of the same units

So what, Vista disappears all of the sudden?

personally I don't care about vista since it's a programming disaster, but i'll add it

The only thing people actually complain about Vista is its comparability issues but you just gotta right click on the program and click Run as Admin but other than that, there isn't much wrong with it.

Try not to make this a discussion on Vista but rather the intent of the original topic.

Does 7 x86 work at all? Have you tried it for other values? It seems odd that this would be the odd-platform-out. At the very least, it would just be a memory allocation issue (I'd think). Have you tried compatibility modes on it?

I did have a vista for a while... It had more general problems than XP did (freezes, security vulnerabilities), and didn't run some programs from earlier systems (i'd say 5%)

You will, in addition, continously find little errors when running programs that did not appear on older systems - most of them are annoying and harmless but some will crash the program - developers tended to fix many of them for the new system but it's poor showmanship for a newer OS to force programs to adapt to them


I'll try it, but I think it's a memory structure differance

Update: Tried it as admin, winXP mode and such, didn't work, also tried the p15 scarab trick which also crashed in all the modes.

Post has been edited 2 time(s), last time on Jun 22 2011, 7:00 am by jjf28.

Odd, I'm on Vista and tried the assimilator wall out but when I select it, the game crashes

when I selected it, it crashed as well (though I couldn't select it directly)

It doesn't. Plain and simple. The memory layout is exactly the same. Only the values stored in the memory will change.

A 64-bit system is completely different than a 32-bit system, allowing 64-bit applications to take advantage of 64-bit operations (for example: a program can now copy 8 bytes immediately instead of having to copy 4 bytes twice). Though, it still contains a 32-bit subsytem, allowing backwards compatibility with older applications (32-bit applications use the 32-bit subsystem, and 16-bit applications use the 16-bit subsystem(is it still even supported?). A 32-bit application can't use the upper bounds of memory that a 64-bit system has access to, because a 32-bit app can only store addresses using 32 bits.

As to why it crashes in some operating systems: Your buffer overflow is is reading from a pointer, that pointer points to a block of memory which is coincidentally being allocated in the same block. In fact, it's such a coincidence that it could even be different on the same operating system.

It's a buffer overflow.
Here are some general rules:

• Don't rely on it.

Again, I just want to emphasize that the memory structure can't change. It's simply impossible. Not improbable, impossible.

Right, so the memory structures don't change, just the contents. That doesn't really change my point and you're simply arguing semantics.

The dynamic data is allocated, that allocation happens to be in the same block. With a different operating system, it might run, let's say, a compatibility module that allocates memory before program execution. The order in which the memory was allocated now changes, and now the data is allocated in a different block, and a different pointer is stored.

I'm saying the buffer overflow may be reading from that pointer. Not only can it be different for another operating system, it can even be different for the same operating system.
You could run WinXP and it might work fine 100%, I could run WinXP and it could fail 100%, just because it allocated something extra like an application watch-dog or something.

Additional research revealed the confusing nature of what x86 acctually is, sorry if I dragged anyone into my thinking

Quote

The term x86 refers to a family of instruction set architectures[2] based on the Intel 8086 CPU.

Quote

The 8086 gave rise to the x86 architecture of Intel's future processors.

Quote

Marketed as source compatible, the 8086 was designed so that assembly language for the 8008, 8080, or 8085 could be automatically converted into equivalent (sub-optimal) 8086 source code

Quote

An instruction set, or instruction set architecture (ISA), is the part of the computer architecture related to programming, including the native data types, instructions, registers, addressing modes, memory architecture, interrupt and exception handling, and external I/O. An ISA includes a specification of the set of opcodes (machine language), and the native commands implemented by a particular processor.

To note, you never mentioned x86 . Anyways, am I being misled by or misinterpreting my source articles?

As read, I took it that assembly code for x86 was setup differently in such a way that would change memory architecture into a form where it would all run the same - and be more secure.

Post has been edited 3 time(s), last time on Jul 11 2011, 5:46 am by jjf28.