Question, edit file versions ?

Discussions about everything else
Red_Fist
Godlike
Posts: 2163
Joined: Sun Oct 05, 2008 3:31 am

Question, edit file versions ?

Post by Red_Fist »

Since I have win7 64 bit and ued still works and the version for the file is "NA" not available.

If you got a program that says it don't work for win 64 bit, could one edit the file to have a NA "version" and then work ?

I can't find a program that changes versions of exe files to test my theory, I used to have one way back in the day.
Binary Space Partitioning
User avatar
EvilGrins
Godlike
Posts: 9668
Joined: Thu Jun 30, 2011 8:12 pm
Personal rank: God of Fudge
Location: Palo Alto, CA
Contact:

Re: Question, edit file versions ?

Post by EvilGrins »

I never had Win7 but I went from WinXP to Win10 and all my UT stuff still works.

Not to possibly over simplify the issue, do you still have the edsplash.bmp file in the /system folder? As weird as it may sound, without that 1 .bmp file, UnrealEd won't run.
Attachments
UT0002.jpg
UT0001.jpg
http://unreal-games.livejournal.com/
Image
medor wrote:Replace Skaarj with EvilGrins :mrgreen:
Smilies · viewtopic.php?f=8&t=13758
Red_Fist
Godlike
Posts: 2163
Joined: Sun Oct 05, 2008 3:31 am

Re: Question, edit file versions ?

Post by Red_Fist »

I don't mean an unreal program, but any program. wonder if that will work because Ued is as old as other programs and works in 64 bit, but has no version number.
need Higor on this, he would know.
Binary Space Partitioning
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Question, edit file versions ?

Post by sektor2111 »

Man... uuhh.. in order to not mess with bits colors blabbering, I'm using very old apps for images (PCX for UT) - apps from Win3.1 ages those so called shareware a bit "limited" with a nag screen with buttons or something which looks annoying but is not annoying at all, and I didn't fail with crusher textures as nowadays apps are doing, seriously....
If this Win10 is so "smart" probably it should have an almighty compatibility, right ? Like a wise old man living in 2 ages and knowing a lot of things - except its Alzheimer moments :ironic: .
Chris
Experienced
Posts: 134
Joined: Mon Nov 24, 2014 9:27 am

Re: Question, edit file versions ?

Post by Chris »

It's not that simple. You need to consider the differences between the OSs and most importantly, their target architectures.
In most cases Windows will have pretty good(not great) backwards compatibility depending on how much it relies on the WinAPI and weither it relies on functions or libraries that has come to be deprecated and obsolete in newer versions.
And last but not least (The most important one) is the target architecture, you can run an x86 build on x86 and x86-64 (64 bit windows build) targets, but you can't run x64 builds on x86 targets (32bit windows build) for obvious reasons.

File version meta data is just to tell you the version build of that file, and is therefore irrelevant to the compatibility of the target.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Question, edit file versions ?

Post by sektor2111 »

Eh I gotta admit that you are right at some points. But I'm still happy... Reason: I'm glad that they still did not developed 128 bits and claiming full compatibility with everything - dreams. Sometimes I'm nostalgic but... is not a problem. Time is changing/passing things are in the same state - other actors on the same stage. I was looking at these tablets - software there just remember me by times when I was programing a monthly PC reset/reinstall due to state where machine was going after so many awesome programs running :lol2:. Exactly this is happening when you start installing/checking stuff and then you need a factory reboot because machine has the dignity to not run all trash done by "experts" in new CPUs :rock:, so it goes fresh as a summer fruit...
the best part is your machine works pretty nice in a clean state and this is good. So - Testing remains the main work in all.
Red_Fist
Godlike
Posts: 2163
Joined: Sun Oct 05, 2008 3:31 am

Re: Question, edit file versions ?

Post by Red_Fist »

Yes but, UT - Ued is 1998 right ?

2008, 2018, 20 years !!! but yet windows cuts off other programs claiming it won't work that are not as old.

So by my estimation, if an old EXE can just be stripped of it's version, win7 64 would not know it was old, the same way UT still works.
On the other side, did they write UT knowing to make it always work 20 years later ?
I really don't see why every program since DOS or win 3.1 cannot just run, 16 bit, 32 bit, the CPU still takes the EXACT same commands built on the chip, like machine code, 100% the same for x86 and less of the same commands for 16 bit.

Need to find a program that can strip away version numbers to see what gives, will they or won't they work.
Now I do understand about the libraries and windows code, but I think they are sadistically cutting us off to not use them, like wow is it going to break the new windows, something fishy.
Binary Space Partitioning
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Question, edit file versions ?

Post by sektor2111 »

Red_Fist wrote:On the other side, did they write UT knowing to make it always work 20 years later ?
Something not very far, not very close. It was written about: "The better CPU = the better for game..." but that was the major goofing and a pretty much fake thing - a fantasy. This engine has hard-coded limits and not "computed limits" based on a benchmark at OS install or done in run-time 4 touchers, 10000000 iterations, 1000 paths, other arrays - these are the same in any CPU used, and then multi-core support is NONE, Calibrating to unpredictable CPU with speed stepping is also NONE. Only a single factor deviating execution in a new Kernel might go to a crash. Even if a last generation CPU is capable of a high speed processing UE1 will cap executions. If other stuff is based on the same "limits" we won't run everything in a new CPU and a new OS. More than that, programmers teams are changed as I can see so far, and these new dudes have mainly heads in clouds and don't have a clue about some base things, Internal sources from M$ were already speaking in private about problems and notice Higor's problems with compilers. Is not easy when Corporations are doing a mess with less skilled workers just for making money as a primary goal. I think in next 20 years in IT will be something like a chaos "Let's see if this do works" with very few exceptions. Look around and you can see some sudden self claimed "programmers" but having no clue what they do and finishing nothing - direct sample of evolution - start 100 things finishing nothing, or only one thing useless and borked in a self defaming spree.
nogardilaref
Masterful
Posts: 577
Joined: Tue Jun 20, 2017 1:00 pm
Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋

Re: Question, edit file versions ?

Post by nogardilaref »

Red_Fist wrote: So by my estimation, if an old EXE can just be stripped of it's version, win7 64 would not know it was old, the same way UT still works.
On the other side, did they write UT knowing to make it always work 20 years later ?
I really don't see why every program since DOS or win 3.1 cannot just run, 16 bit, 32 bit, the CPU still takes the EXACT same commands built on the chip, like machine code, 100% the same for x86 and less of the same commands for 16 bit.
That's not how it works at all. As Chris explained, it all goes down to the actual "dependencies" the program has, once you're in 64 bits.

UT and, consequently, UEd, do not rely on pretty much anything whatsoever from Windows itself (comparatively to many other programs and engines), nor other stuff which relies itself on Windows either, it's a whole self-contained program where almost everything it needs to run is built within the program itself, and that's mainly what made it still work nowadays in modern systems.

If you build a simple program in C++, like the basic "Hello World", this program will probably run without issues for the next 20 years or more, since you don't need any external libs and you are using standard stuff, which is always supported in one way or another.
However, the moment you depend on libs which themselves depend on other things which may change drastically over time (such as drivers or any APIs), you run the risk for it to simply stop working once the lib stops being updated and the functionality it needs from the operating system is stripped away in newer versions.

A great example of this are the renderers themselves. If you try to run the renderer the game comes with, since it depends on DirectX 6 or 7, something already completely obsolete in newer Windows versions, it will not work at all in most cases.
So you have to install a more modern renderer, such as D3D9, D3D10 or even D3D11, or OpenGL which tends to have better retro-compatibility.

And this is why you can still load the UT C++ headers in a modern Visual Studio and start to extend the engine with it, and it still works (after a few changes here and there that is, which have mostly to do with existing macros and deprecated stuff in newer compilers).

The version that you see in Windows itself, is just metadata, it's only informative to you, the user, it has no significance whatsoever when the program actually runs, and it's still optional (you can build a modern program and not define it anywhere afaik).

The only things which are able to make an old broken program to work again in a modern system, are:
1 - The compatibility mode of the program: "run as Windows 98" for example, which simply makes Windows provide to the program a Windows 98 API for example, which is generally just a wrapper to the actual modern libs in other to work.
2 - Installing manually libs (.dll files and the like) which the program needs, which might still work in a modern system, but are no longer present by omission as they're not supported any longer.
3 - Running it in a virtual machine: slower, but it generally guarantees that it will work, unless it uses stuff that a VM cannot provide yet (until a few years ago it had trouble with 3D acceleration, but that's figured out now I think).
4 - Recompiling it in a modern Visual Studio (after perhaps a few key changes here and there).

and maybe a few more, but those are all which come to mind.
Red_Fist
Godlike
Posts: 2163
Joined: Sun Oct 05, 2008 3:31 am

Re: Question, edit file versions ?

Post by Red_Fist »

I see, so it's basically "windows" interfering I found an old program called lathe.exe was 1992, and windows says it can't work. You set points on a graph and it created a 3D vase or whatever shape you make, but with color and basic lighting.
I might even be 16 bit. all there is, is a EXE no other files.

I did load it in VB and it says something on the lines of it can't find something, it just won't load, and it's version is just blank among others all blank.

Well poop, now I can't make my own RF-OS :loool:

I wish I went into programing, I did with BASIC waaaaaaaaaaaaaaay back when my brother brought home a computer with a 4k RAM, green screen, I was up all night was so cool. It was when waterbeds just came out, they opened a waterbed store.

I did a little bit on Atari 800XL in assembly machine code it was just so FAST in machine code, (and Atari BASIC) and bought a 360k floppy DOS 3 ,that floppy I put on layaway at K-Mart and cost me $169.00.

Now they are light years ahead, a whole different world.
Binary Space Partitioning
Chris
Experienced
Posts: 134
Joined: Mon Nov 24, 2014 9:27 am

Re: Question, edit file versions ?

Post by Chris »

You're going to want to run those 16bit applications in an emulator such as DOSBox or whatever. Windows now runs on the NT kernel (since Windows NT) and is now completely different from DOS, therefore it has absolute zlich support for 16bit applications. Heh.. 16 bits, can you imagine that? A limit of 64kb of memory space.

UE1 was never meant to run that fast, most of us know by now that the UScript run time and practically the entire architecture is terribly slow and inefficient. The main goal was convenience to encourage lazy coding and justify human unreliability causing lots of redundancy. Hats down to Higor and many others for putting the effort into trying to clean up some of the mess. Personally I don't find it reasonably efficient and worth the time to try and patch it all up. That being said there are some very nice designs and theories (the actual implementation is another matter..) put into this engine which I've sadly not seen in pretty much any new game on the market. It would be sweet to assemble a team of great developers and artists to create an entire new platform with some of the benefits from UE.. I can keep on dreaming.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Question, edit file versions ?

Post by sektor2111 »

Chris wrote: Heh.. 16 bits, can you imagine that? A limit of 64kb of memory space.
I think Sinclair Spectrum are on 8 bits using 64 kb. 16 bits goes to 640 kb base memory which is not that changed after all, those 640 kb are still a base for operations with memory if I'm not mistaking... the rest of memory was needing memory driver, read again, a memory driver called himem.sys... which I still have in WinXP dated 2008 else 2 GB memory probably would be a fantasy for use.
User avatar
Barbie
Godlike
Posts: 2792
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: Question, edit file versions ?

Post by Barbie »

sektor2111 wrote:16 bits goes to 640 kb base memory
Sorry to correct you, but 16 Bit = 2^16 = 65536 has nothing to do with the 640k limitation. This limitation was caused by the designer of the early PC architecture, who decided to give the lower 640 kiB memory area to the user and reserve the reminding upper 384 kiB for the system. (See Wikipedia.)
The 1 MiB border was caused by the Intel 8088 CPU that had 20 address lines what means that 2^20 = 1048576 = 1M memory cells were available.
sektor2111 wrote:himem.sys
Later used CPUs had more than 20 address lines and offered also a Protected Mode which allows access to memory above that 1 MiB border. himem.sys was a software that could be used in real mode by several other programs to coordinate the access to that memory according the specification XMS.

PS: I'm glad that these times of Seg:Ofs are gone...
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett
User avatar
rjmno1
Masterful
Posts: 716
Joined: Fri Aug 12, 2011 9:38 pm
Personal rank: masterfull
Location: https://sites.google.com/view/unrealtou ... oject/home
Contact:

Re: Question, edit file versions ?

Post by rjmno1 »

yes thats true but it also has something todo with the compatebility of the software and hardware.
We have all the so called 100% ibm compatible hardware.So when you have windows 10 it all needs to be downwards compatible with the hard and software.
Otherwise ut 99 does not run on the future upcoming personal computers.When a new windows version comes out i Always test if ut 99 runs on it.
It has all something todo with microsoft and hardware supplies.It also has something todo with compiling something also just like in ut 99 and unreal, and unrealed also.
Dos based games is another os wich we dont use these days, but they made a software program also for that to run on windows 10 ,7 and 8.0,8.1.
I have windows 10 installed at this moment and everything and ut 99 also runs just fine with it.
Some software packes just dont run after a period of time during lack of updating and a newer version comes out.
hymem.sys and other software wich was devolp during dos era are all loaded in the upper memmory area of the memmory banks they did that becouse the base memmory will be more.
Just like quemm did in the dos era.Also some tsr programs are loaded high in the upper memmory area.Thay did that becouse you will have more base memmory that 640 kb border.
Yes windows 10 is pretty good, and they are not planning a newer version of microsoft money maker.
I did read something that they will update windows 10 very often without building a other version of windows.
They will update windows 10 for a very long time, maby it will last for 15 or 20 years maby just forever.
because the hardware never stand still they just have to make alot of drivers, and the rest will come with the windows updates.
You also did have the emm386.exe memmory manager who did make alot possible loading tsr programs in a certon memory area.
Quemm 386 was bether with made more base memmory availeble for other programs, but was not compatible with all games.

information:

https://en.wikipedia.org/wiki/QEMM

https://en.wikipedia.org/wiki/EMM386

https://en.wikipedia.org/wiki/Upper_memory_area

https://en.wikipedia.org/wiki/DOS_memory_management

:tu:
unreal tournament 99
®
Image
Image
ImageImage
https://sites.google.com/view/unrealtou ... oject/home mine home ut99 website.
https://richardmoust105.blogspot.com/20 ... ef-in.html dutch blog page about ut99 settings.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Question, edit file versions ?

Post by sektor2111 »

Like I said I'm not sure about every detail but I know my details. My machine 386 from that time had 8 MB but all beyond 640k were useless if himem.sys was not defined - running a sort of virtual mode if I'm not wrong - because CPU was operating indeed in 64k blocks - inefficient compared with other hardware from that time. System was able to run small games and things in that base memory, the rest of "giants" have never run without accessing "extended memory". Also in those years I did not study so much IT - I was busy with... living life (swimming, parties, listening music, etc.) IT domain was not that developed here... that's why I'm a bit limited in here.
Post Reply