how is 64 bit better?

[stratum]

I know one company which used to use COBOL software written in 1980's running on windows, possibly on MSDOS mode, until just 1-2 years ago.

[mcbpete]

Haha, yeah the logistics in some places are so convoluted it's sometimes best to just keep things as is. Here's an information screen at a bus terminal still rocking a Commodore 64 earlier this decade:

[PurpleSunray]

Windows is not likely to drop any 32 bit support, otherwise COBOL compilers from 1990's wouldn't work. Big problem

Think that era was an even smaller number of bits (16-bit era), which I think was dropped circa Win 7

You can still run win16 apps on your Win10 after enabling NTVDM.
MS is not like Apple on that, they usually try to maintain backward compatiblity -> not very likely that MS will drop (without a way to still run it) 32bit support any time soon.

[mcbpete]

Alas NTVDM is no longer supported in 64-bit versions of Windows (which, if you're on Windows 10 is quite likely)

[mystran]

Windows is not likely to drop any 32 bit support, otherwise COBOL compilers from 1990's wouldn't work. Big problem

Think that era was an even smaller number of bits (16-bit era), which I think was dropped circa Win 7

Actually with 16-bit it's a case of 32-bit vs. 64-bit Windows rather than a specific version and there's a technical reason: 16-bit applications under 32-bit Windows (or any other 32-bit OS) used so called "vm86mode" of the CPU which emulates 16-bit "real mode" under 32-bit protected mode, but "vm86mode" is not available when you are running in 64-bit long mode (instead you have the 32-bit compatibility mode).

So.. basically supporting 16-bit applications directly under 64-bit operating system is "inconvenient" enough that it's just not worth it, especially considering any 64-bit CPU can run any MSDOS-era applications under an emulator like DOSBOX quite fast enough for most practical purposes.

[quikquak]

Haha, yeah the logistics in some places are so convoluted it's sometimes best to just keep things as is. Here's an information screen at a bus terminal still rocking a Commodore 64 earlier this decade:

Haha, yeah some of us remember coding on 8 bit computers. Wow, that code was tiny, back when entire OSs were 32K bytes in size...

[whyterabbyt]

Haha, yeah some of us remember coding on 8 bit computers.

Its surprisingly common these days....
https://en.wikipedia.org/wiki/Atmel_AVR

[Guillaume Piolat]

On x86, 64-bit code is usually up 5% to 15% faster when compared to the same 32-bit code.
- more registers
- because of this wealth of registers, different calling conventions: https://en.wikipedia.org/wiki/X86_calli ... onventions
- the "red zone" optimization of the stack that only happen in 64-bit https://eli.thegreenplace.net/2011/09/0 ... on-x86-64/

[GaryG]

I know one company which used to use COBOL software written in 1980's running on windows, possibly on MSDOS mode, until just 1-2 years ago.

We still have a couple of minor finance systems that are 16 bit DOS...

I inherited the support of them and the first call was that they wouldn't work with the new networked printer system we installed. After messing about with net use etc for a bit I actually looked into the app and saw there was a print to file option which generated the same info but as a csv file. I asked if that was an acceptable workaround and was told it would be great as the first thing they did with the printed report was manually enter the figures into a spreadsheet...

[BertKoor]

COBOL can be compiled to 64bit without issues for quite some time already:
https://www.microfocus.com/products/visual-cobol/

8bit instructions won't ever die. Processor virtualisation & emulation is the answer. Never played old arcade games with MAME?

I also recall a friend of mine had a look at his pentium processor with a thermal camera, and could locate where the 16bit instructions of his DOS box were executed.

Technology is moving forward and there's nothing you can do about it. Not too long ago all TV broadcasts were in 4:3 aspect ratio with just 500 scan lines. Now nearly everybody has bought a flatpanel TV and the 16:9 aspect ratio in full HD is widely adopted in the market.

Same with DAWs, everything is getting bigger & better, and thus 64bits.

[pc2000]

Technology is moving forward and there's nothing you can do about it. Not too long ago all TV broadcasts were in 4:3 aspect ratio with just 500 scan lines. Now nearly everybody has bought a flatpanel TV and the 16:9 aspect ratio in full HD is widely adopted in the market.

Same with DAWs, everything is getting bigger & better, and thus 64bits.

Best possible comment!

[quikquak]

Naaa, 128 and 256 bit processors will be much better... along with the memory cache.
Apple will redact all your old 64 bit stuff, and label it as slow and old, "...and the needle returns to the start of the song, and we all sing along as before..."

[Miles1981]

32bits instruction sets are more than 10 years old. They don't have any SIMD (more or less).

What exactly are you smoking?

All the SIMD extensions work perfectly fine in 32-bit mode and SSE2 even predates x86-64.

Indeed, my bad, I was stuck in a preOS support... Which happened a long time ago.

[umd]

I dont understand why everyone is making 64 bit. How is it better? honestly performance wise, i cant tell the difference between my 32 bit daw and 64 Bit, both of which i use.

the jbridger is really buggy, Most of my fav vsts are 32.

64bit plugins are certainly better if you use plugins that use lots of RAM. Other than that, you won't notice any difference ( 32bit plugins can also do 64bit processing ).

The bridging stuff is not perfect ( 100% compatibility is an unrealistic goal ), but, I have been using it myself for many years ( and mostly for live performances ), and I certainly don't want it to be "really buggy".

If you can tell me how to reproduce any issues you're having I will gladly have a look.