> Only takes a compiler switch for me to switch my code between 32 and 64

> bit. I'm lazy.

>Clearly you are lazy! I've been developing applications since the early

>80's, and it's never so easy as "switching compilers".

 

Maybe I don't understand exactly what you mean, but a person isn't 'lazy'

for not doing something he doesn't need to do! It sounds like you are saying

he was duty bound to change a lot of stuff when switching from 32 to 64-bit,

even if his code worked just fine by just re-compiling with the new

compiler.

 

I think what he was saying is that code can often be written in such a way

that it requires little or no changes when moving to a new compiler. One

could argue he is anything but 'lazy', since he likely spent a lot of time

and effort making sure his code was transportable. Those people that are

'lazy' tend to just get to work in the environment it does, without

considering if it isn't written 'correctly' it could require a lot of

changes when a new compiler is used.

 

Although he did accuse himself of being 'lazy', so what the hell do I know!

LOL )

 

"dzomlija" <dzomlija.2zoav4@no-mx.forums.net> wrote in message

news:dzomlija.2zoav4@no-mx.forums.net...

>

> Stephan Rose506152 Wrote:

>> Now that only smells like bad design to me.

>>

>> Only takes a compiler switch for me to switch my code between 32 and 64

>> bit. I'm lazy.

>>

>

> Clearly you are lazy! I've been developing applications since the early

> 80's, and it's never so easy as "switching compilers".

>

> When I made the move from 16-Bit (DOS and Windows 3.1) to 32-Bit

> (Windows 95) programming, much of the code I had written for Windows 3.1

> went through such extensive changes that I actually achieved better

> results by starting from scratch. VERY FEW applications re-compiled to

> 32-Bit without requiring revision.

>

> And the same holds true with the transition from 32-Bit to 64-Bit.

>

>

> --

> dzomlija

>

> ____________________________________

> Peter Alexander Dzomlija

> Do you hear, huh? The Alpha and The Omega? Death and Rebirth? And as

> you die, so shall I be Reborn...

>

> - ASUS A8N32-SLi-Deluxe

> - AMD Atlon 64 Dual-Core 4800+

> - 4GB DDR400

> - ASUS nVidia 6600

> - Thermaltake Tai-Chi Watercooled Chassis

> - 1207GB Total Formatted Storage

> - Vista Ultimate x64

> - CodeGear Delphi 2007http://dzomlija.spaces.live.com/blog/

On Wed, 07 Nov 2007 04:09:55 -0600, dzomlija wrote:

> Stephan Rose506152 Wrote:

>> Now that only smells like bad design to me.

>>

>> Only takes a compiler switch for me to switch my code between 32 and 64

>> bit. I'm lazy.

>>

>>

> Clearly you are lazy! I've been developing applications since the early

> 80's, and it's never so easy as "switching compilers".

 

Seeing how you don't know what a compiler switch is and think that it

means I'm "switching compilers", I have a hard time believing that.

 

For your info, it is a command line argument that I pass to my compiler

that tells it if my target is 32-bit or 64-bit, and my code is written to

compiler properly for either target.

 

So yes, it *is* that easy.

>

> When I made the move from 16-Bit (DOS and Windows 3.1) to 32-Bit

> (Windows 95) programming, much of the code I had written for Windows 3.1

> went through such extensive changes that I actually achieved better

> results by starting from scratch. VERY FEW applications re-compiled to

> 32-Bit without requiring revision.

>

> And the same holds true with the transition from 32-Bit to 64-Bit.

 

No it doesn't, unless of course you don't understand how to write your

software in such a way that it doesn't matter what it is compiled for.

 

Matter of fact, I use two different systems to work on my projects. One

is a 32-bit system and defaults to a 32-bit target while the other is a

64-bit system and defaults to a 64-bit target. So I'm switching between

32-bit and 64-bit on a daily basis depending on if I'm working from the

office or home without a single code change.

 

--

Stephan

2003 Yamaha R6

 

å›ã®äº‹æ€ã„出ã™æ—¥ãªã‚“ã¦ãªã„ã®ã¯

å›ã®äº‹å¿˜ã‚ŒãŸã¨ããŒãªã„ã‹ã‚‰

On Wed, 07 Nov 2007 10:50:25 -0800, Peter Oliphant wrote:

>> Only takes a compiler switch for me to switch my code between 32 and 64

>> bit. I'm lazy.

>

>>Clearly you are lazy! I've been developing applications since the early

>>80's, and it's never so easy as "switching compilers".

>

> Maybe I don't understand exactly what you mean, but a person isn't

> 'lazy' for not doing something he doesn't need to do! It sounds like you

> are saying he was duty bound to change a lot of stuff when switching

> from 32 to 64-bit, even if his code worked just fine by just

> re-compiling with the new compiler.

 

I need to change absolutely nothing going from 32-bit to 64-bit. I

actually do it on a daily basis as I use two different systems and one is

a 32-bit system and the other is a 64-bit system with the compiler set to

produce 64-bit code.

>

> I think what he was saying is that code can often be written in such a

> way that it requires little or no changes when moving to a new compiler.

> One could argue he is anything but 'lazy', since he likely spent a lot

> of time and effort making sure his code was transportable. Those people

> that are 'lazy' tend to just get to work in the environment it does,

> without considering if it isn't written 'correctly' it could require a

> lot of changes when a new compiler is used.

 

Not only is it transportable between different compilers, but it is also

written to run under Windows or Linux and 32-bit or 64-bit under either

operating system requiring no code changes from me. I just set the

appropriate compiler switches that specify my target platform and I'm

done. Takes about 5 seconds.

 

Did some extra work go into this ahead of time? Sure. I'm even performing

some additional portability work on the code at the moment to ease my API

dependencies which are too heavy for my liking in some parts of the code

right now. That'll even make it possible to "relatively easily"

completely change APIs in the future. I say relatively because an API

change will require a complete UI rework no matter which way I twist it

and turn it. But at least, I can limit it to that only.

 

So yea, I definitely don't mind investing additional time up front when I

know it's going to save me lots of time, trouble and headaches later.

>

> Although he did accuse himself of being 'lazy', so what the hell do I

> know! LOL )

 

Haha, well lazy in the sense that I'm too lazy to rewrite 700+ pages of

code as Telstar was bragging about and rather develop a system ahead of

time that doesn't require me to do so in the first place. =)

 

 

 

--

Stephan

2003 Yamaha R6

 

å›ã®äº‹æ€ã„出ã™æ—¥ãªã‚“ã¦ãªã„ã®ã¯

å›ã®äº‹å¿˜ã‚ŒãŸã¨ããŒãªã„ã‹ã‚‰

"Charlie Tame" <charlie@tames.net> wrote in message

news:Ow36%23VMIIHA.4712@TK2MSFTNGP04.phx.gbl...

>> Win98 also needs far less RAM than XP or linux as it is generally

>> available.

 

Actually that was repaired a bit in WinME..

Win95 and Win98 could virtualize or ram cache on the

fly much more ram than the motherboards had slots for,

in WinME the ability to run not just cache data in ram

was available but *disabled by default* <duh>, this is

an old MS technology that looks like it is already being

reconsidered to 'virtualize applications' under the next

Windows OS shell (not in vista cruiser)...

Personally imho dropping one of the 9x shells onto an

NT style disk and file format would work quicker.

> Yes RAM is a consideration, depends I guess on the general value of the

> machine too since all adds to cost

 

Ram was enormously expensive back in 9x days...

upto 200 usd per mb for best quality PC ram in mid

1990's. Anyways..the 9x file format was more

promiscous allowing debugging and process locking

at a much lower level than the NT systems...it was

also a file format about as stable as typical nix types

that could fall over with a passing wind...the best thing

was enabling (by default) the file check and replace.

In most part those things have improved, just a little.

 

umphff...you can buy today a lowball desktop computer

without any monitor or toys complete with OS for about

the same as a decent stick of vcc133 128mb ram circa' 1998....

It was thought at the time that computers wouldn't be

accepted en mass until the 300usd pricepoint was broken

and it's close to that now with some laptops.

 

NT Canuck

'Seek and ye shall find'

Stephan Rose wrote:

> On Wed, 07 Nov 2007 10:50:25 -0800, Peter Oliphant wrote:

>

>>> Only takes a compiler switch for me to switch my code between 32 and 64

>>> bit. I'm lazy.

>>> Clearly you are lazy! I've been developing applications since the early

>>> 80's, and it's never so easy as "switching compilers".

>> Maybe I don't understand exactly what you mean, but a person isn't

>> 'lazy' for not doing something he doesn't need to do! It sounds like you

>> are saying he was duty bound to change a lot of stuff when switching

>> from 32 to 64-bit, even if his code worked just fine by just

>> re-compiling with the new compiler.

>

> I need to change absolutely nothing going from 32-bit to 64-bit. I

> actually do it on a daily basis as I use two different systems and one is

> a 32-bit system and the other is a 64-bit system with the compiler set to

> produce 64-bit code.

>

>> I think what he was saying is that code can often be written in such a

>> way that it requires little or no changes when moving to a new compiler.

>> One could argue he is anything but 'lazy', since he likely spent a lot

>> of time and effort making sure his code was transportable. Those people

>> that are 'lazy' tend to just get to work in the environment it does,

>> without considering if it isn't written 'correctly' it could require a

>> lot of changes when a new compiler is used.

>

> Not only is it transportable between different compilers, but it is also

> written to run under Windows or Linux and 32-bit or 64-bit under either

> operating system requiring no code changes from me. I just set the

> appropriate compiler switches that specify my target platform and I'm

> done. Takes about 5 seconds.

>

> Did some extra work go into this ahead of time? Sure. I'm even performing

> some additional portability work on the code at the moment to ease my API

> dependencies which are too heavy for my liking in some parts of the code

> right now. That'll even make it possible to "relatively easily"

> completely change APIs in the future. I say relatively because an API

> change will require a complete UI rework no matter which way I twist it

> and turn it. But at least, I can limit it to that only.

>

> So yea, I definitely don't mind investing additional time up front when I

> know it's going to save me lots of time, trouble and headaches later.

>

>> Although he did accuse himself of being 'lazy', so what the hell do I

>> know! LOL )

>

> Haha, well lazy in the sense that I'm too lazy to rewrite 700+ pages of

> code as Telstar was bragging about and rather develop a system ahead of

> time that doesn't require me to do so in the first place. =)

 

 

Trying to do work that doesn't require constant revisits is not lazy it

is simply smarter, and often cheaper for the end customer, and a less

"Instant" bonus is that the less frequently you have to go "Fix"

something the better your word of mouth reputation gets.