Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: 64 bit file suffix is not ideal

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1

    Default 64 bit file suffix is not ideal

    Hi,

    It's great that we now can compile to both 64 bit as well as 32 bit and I'm currently migrating a project to compile to both 32 bit as well as 64 bit.

    As that means I now have a Programs folder with both 32 bit as well as 64 bit versions of the same components things are starting to get ... well.. messy.

    So for the moment my solution is to suffix every binary with either "32" or "64" in order to not end up getting confused, but as I start renaming more files it also starts to highlight that this is not exactly ideal.
    Especially not if you have a binary that already has a numbering scheme in its name (case in point Hammer4.exe or Hammer464.exe...)

    Other development tools tend to have a deploy folder that has the bitness in it.
    Eg. deploy to "Win32" and "Win64"
    With having different folders you don't end up with binaries that have a different bitness in the same folder.
    Especially as 32 bit binaries don't work with 64 bit ones.. IMO they should not be together.
    Just like the Studio and other development tools are also in a "Bin64" folder whereas the 32 bit components are in the "Bin" folder.

    Thanks
    --
    Wil

  2. #2
    Join Date
    Feb 2009
    Location
    Somewhere in Vermont, USA - unless I'm not
    Posts
    9,518

    Default Re: 64 bit file suffix is not ideal

    It's really none of my bitness, but 2 folders sounds like a good idea to me.

    Garret

    All my life,I always wanted to be somebody. Now I see that I should have been more specific.


  3. #3
    Join Date
    Apr 2009
    Location
    Wilmington NC, USA or Oaxaca Mexico
    Posts
    813

    Default Re: 64 bit file suffix is not ideal


  4. #4
    Join Date
    Feb 2009
    Location
    Adelaide, South Australia, Down under
    Posts
    2,223

    Default Re: 64 bit file suffix is not ideal

    I always create a deploy.bat in the programs directory and a ./deploy directory. I guess I took that habit from visual foxpro.
    But it would be nice if Df would also be slightly more deployment oriented.
    Marco Kuipers
    DataFlex Consultant
    28 IT Pty Ltd - DataFlex Specialist Consultancy
    Adelaide, South Australia
    www.28it.com.au

  5. #5
    Join Date
    Feb 2009
    Location
    Hengelo, Netherlands
    Posts
    9,017

    Default Re: 64 bit file suffix is not ideal

    Wil,

    While I personally like this suggestion I wonder how fast we end up in the same situation as Windows itself. I mean putting the 64 bit binaries in a folder named System32 and the 32 bit binaries in SysWow64...

    For the hammer I think you should not produce a 32 bit version any longer and just drop the "64" extension under project properties. Why? How many 32 bit computers with Windows 10 32 bit will be around these days? And if there are a couple; is that your target? For many developers there is the question if all their application dependencies are 64 bit but I expect that you control all dependencies of the Hammer so they can all be 64 bit Unicode before DataFlex 2020 is really released.
    Regards,
    Data Access Worldwide
    Vincent Oorsprong

  6. #6

    Default Re: 64 bit file suffix is not ideal

    Vincent,

    It is what all the other tools do...
    If you deviate from what the rest of the world does then you should do it better and I don't think the suffix game is better.
    To me it seems that the suffix workaround was a quick fix that got you guys not have to worry about it and focus on bigger fish to fry.
    However now that you bring 64 bit support into the hands of DataFlex developers, I think this needs to get addressed.
    This was one of the first things that stood out to me as weird, but I had decided to first use it before I would comment on it.

    re. only releasing a 64 bit version of a product (yes in this case The Hammer as it is a good target to play with)
    There's a couple of arguments against that.
    1. During a transition period you will want to be able to compile to both targets.
    2. Testing and the ability to see if an issue is a 64 bit problem or a 32 bit one. This one alone would have you adapt the renaming game on all your binaries.
    3. Some customers are on 32 bit, some are on 64 bit.
    4. If you have multiple versions of your product released, you'll be having 32 bit and 64 bit. With binaries in different names you'll either have to backport that naming scheme to previous version or have the extra overhead.
    5. Some people still run 32 bit OS's.. saying "sorry not supported" is not exactly the best marketing step you can take.
    6. Microsoft still supports 32 bit. As you mention "Windows 10" I had a quick peek at Microsoft's official statement here: https://support.microsoft.com/en-us/...cle-fact-sheet and it doesn't even mention 32 bit as a differentiator. But it does mention that LTSC/LTSB versions of Windows 10 are supported until 2029, so I suspect that we will have to support 32 bit on the desktop for at least until 2029... (wow)
    Unfortunately MS never made it easy to move from a 32 bit OS to a 64 one, the solution they suggest is "reformat" which is a no go for most end users.

    I agree that The Hammer will move to 64 bit and that it is an OK thing to demand when your customers are developers.
    For the moment though The Hammer 4 can still run under DF19.1 too and that won't change as long as DataFlex 20.0 isn't released.
    So I will have to do the suffix rename game now.. and once The Hammer 4 (or TH5) is 64 bit only I will have to rename back to the original naming scheme.

    FWIW for The Hammer itself I'm fine with the suffix, it is bigger projects where I can see this to be less ideal.
    --
    Wil

  7. #7
    Join Date
    Feb 2009
    Location
    Brazil
    Posts
    2,427

    Default Re: 64 bit file suffix is not ideal

    oops

    Click image for larger version. 

Name:	bitness folder.PNG 
Views:	61 
Size:	19.1 KB 
ID:	13322

    ---------

    Suppose your app has tons of config and .ini files.. (I have worked in a project like this in the past.. more than 10 .ini or .cfg files ) all of them located in the programs folder, together with the .exe.

    What will happen then, if for some reason, you need to have different content, in such .cfg and .ini files that deppends on bit-level.. (32 or 64) ?

    So, the current approach of just adding suffix, you will have to change your source code do load different .cfg/.ini files as well, as you will be forced to rename them as well in order to avoid conflicts.

    I believe that there is no better solution.. better all depends on use-case.. We should have flexibility.. thats the point.

    We should have both approaches... Either working with sufix, or working with sub-dirs.
    Samuel Pizarro

  8. #8
    Join Date
    Feb 2009
    Location
    Peoria, IL
    Posts
    5,291

    Default Re: 64 bit file suffix is not ideal

    The only valid reason I see to have 32 bit apps currently is if there are dependencies that force you (32 bit drivers etc). Or perhaps you have some embedded app that needs to run on Windows XP.
    Chuck Atkinson

    All generalizations are false, including this one - Mark Twain

  9. #9
    Join Date
    Feb 2009
    Posts
    785

    Default Re: 64 bit file suffix is not ideal

    Hi,

    I am using several active-x controls which are and will not be available in 64 bit. They moved over to .NET and development is happening there. So I have to find replacement controls and do the work again. Do not think the possibility of finding 64 bit replacement com controls will be that easy. I would love to move over using the newer .NET controls with additional features not available in the com controls.

    So for the time being it will remain 32 bits for me.

    Peter
    Peter H. van Wijk
    X-Organize Consultancy N.V.

  10. #10
    Join Date
    Feb 2009
    Location
    Peoria, IL
    Posts
    5,291

    Default Re: 64 bit file suffix is not ideal

    We have several .NET controls wrapped and working quite nicely.
    Chuck Atkinson

    All generalizations are false, including this one - Mark Twain

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •