WinDev, WebDev & WinDev Mobile from a VFP Perspective

[stanlyn]

Hi,

Are any vfp developers using the WinDev, WebDev & WinDev Mobile sdks from PC Soft from France? If so, please share your likes and dislikes.

I need to build desktop, web and mobile apps. I started developing VFP apps back in 1998. I'm hitting the 2gb limits in many of the language's commands and functions as well as table file limits.

I've tried many including Alpha Anywhere solutions and wound up abandoning them. I'd like to find something that offers a near single code base, and one that uses a paradymne similar to VFP.

So far, the best I've found is PC Soft's tools. So, what would you all adopt?

Thanks,
Stanley

 

[stanlyn]

Hi,

Still no response after almost 3 days.

This was also asked at

http://27130.foren.mysnip.de/read.php?27131,566540

and has generated a lot of help and interest that can shed light on what is involved for any of us VFP developers to evaluate WinDev, WinDev Mobile, and WebDev.

Thanks,
Stanley

 

[JRB-Bldr]

I need to build desktop, web and mobile apps.

I'm hitting the 2gb limits

You appear to have 2 separate issues which may or may not be resolved with a single solution.

I have no knowledge of WinDev, WinDev Mobile, or WebDev, but I have worked to resolve these issues with alternate approaches.

For the 2GB limit, I'd recommend changing your 'backend' to MS SQL Server.
Yes, the VFP Query results from the SQL Server must remain below 2GB, but the data tables themselves would no longer have that limitation.

When you say you need to be apps for multiple environments...
* Does this mean that the SAME application needs to run in all of those places?
* Or you need a web/mobile that can integrate to data from a legacy FP/VFP system?
* Or what?

Good Luck,
JRB-Bldr

 

[stanlyn]

Hi JRB-Bldr,

Really I've been looking for a VFP replacement tool for a while now. Since there is so much opportunity and need in the mobile and web space and large >2gb file and data sizes in use today, I started looking for a VFP replacement, as probably sooner than later VFP will no longer run on the next new Windows.

When I mentioned the >2gb sizes above, its more that the table size limits. All the low level file stuff suffers from that as well. Also is saving the filesize that adir() sees (which is correct), the largest integer that can be saved to a field is 2,147,483,647 taken from

https://msdn.microsoft.com/en-us/library/3kfd3hw9(v=vs.80).aspx?f=255&MSPPError=-2147217396

I ran into that about 5 years ago, which resulted in us stopping further development of one of our products. Since then, the file sizes are growing larger and larger. Since then, I've learned how to do api calls for similar stuff.

And yes, integrating all the past VFP stuff I've done with a new platform to create desktop, mobile and web from a single code base is important.

So far, the sdks from PC Soft looks the most promising over Embarcadero's Delphi, Alpha Anywhere, Lianja, Visual Studio, and many others I've tested.

Thanks for answering,
Stanley

 

[Scott24x7]

Stanlyn,
Worrying about VFP running on the "next new version of windows" is a "concern" I've heard since MS announced they would stop making new versions of VFP... back around Win 2000.
Intel architecture is more a driver of that compatibility than the Windows version. And that's not going to go away any time soon. Even when Intel went from 32bit to 64bit, and the OS with it, VFP's 32 bit continues to run. MS have a backward compatibility legacy that they have maintained for quite a long while, and they won't abandon that any time soon either. Worrying about this issue is like worrying you will run out of oxygen. It will happen to Earth but so far in the future, we'll all be extinct by then anyway.
Now, if you're still concerned, then you still have 2 options:
1) Don't upgrade the OS if your mission critical application doesn't run on it. Nothing says you must
and
2) Run it in a Virtual Machine... So run the new OS, but create a virtual environment using your favorite hypervisor and run it there. It will work just like it always has on an OS that it is compatible with. VM world is outside the hands of MS (Except for Hyper-V) and their whole intent is to ensure that you can run anything anywhere, on hardware that is compatible.

So this is a "fear" I hear all the time, but it's really founded in the same space as the fear of the number 13 or the fear o eating ice cream on a Tuesday.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[stanlyn]

Hi Scott,

I'm really not concerned that much about VFP not running on today's systems. As soon as MS announces a 128bit Os, then 32bit OS's days is numbered, as MS's history shows that it runs on current (128b) and one level back (64b). Remember when 16bit apps quit working? It happened the day we moved to 64bit systems.

My apps depend on several 3rd party active-x components and most of the vendors creating those tools has abandoned active-x for .net and d-com.

As far as VFP is concerned, I've had a lot of issues with the >2gb file sizes using low level commands. early on it was not an issue, but as time goes by we are having to deal with larger and larger files. I will also be running into the >2gb table size probably within the next year. Many say I should refactor it to SQL, but that would be a major rewrite and doing so in VFP doesn't make sense since its dead with respect to fixes, updates, security patches, and abandonment by the 3rd party tool vendors.

It doesn't make sense to spend a lot of resources converting it for SQL, when the world is moving to mobile and web based and VFP is not or never was a contender in that space. So, I'd rather spend those resources on learning today's technologies providing solutions for what today's users want and expect.

It has been a major undertaking to evaluate what our next tool will be. So far, based on what I've seen, read, questioned, and what several ex-VFP programmers have told me is that it won't take long for us VFP'ers to feel right at home and all have said its a much more rich environment. Plus, it is a single code base allowing the same code with minor mods to be able to run in all 3 spaces, web, desktop, and mobile.

Considering what I've laid out here, is there any reason to develop any new apps in VFP? I will support what I've already written, except for the one where the 2gb limit is expected soon. I'll rewrite it using the new tools.

Thanks,
Stanley

 

[stanlyn]

Hi,

For anyone interested, I've started two rather in-depth threads that has involved some ex-VFP programmers that are shedding a lot of light on comparing VFP vs WinDev. Find them at:

http://27130.foren.mysnip.de/read.php?27131,567105

and

http://27130.foren.mysnip.de/read.php?27131,566540

Thanks,

Stanley

 

[Scott24x7]

Sanlyn,
I don't understand why you like 128bit OS to death of 32 bit... when the 64bit OS's already run 32bit apps still... you're missing how this actually works.
And again, VM is going to continue to support virtually any OS present or past (and that relates to future as well.) You're worried over something that's not going to happen. And still... just because a new OS is created doesn't mean you have to migrate to it... Just stick with what you have if you have that critical a legacy app. Otherwise, migrate your app... C, C++, C#, VB, all these face the same issue (prior versions) when new OS's are released. This isn't a "VFP" issue. Otherwise, it's just "the sky is falling" mentality.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Take it from adressable memory alone:

16 bit: 64 KB
32 bit: 4 GB
64 bit: 16 EB (exa bytes)
128 bit: 256 ?B (I don't think a name for this exists)

The step from 16 to 32 was not a doubling of adress space, it was 16 doublings. And the step from 32 to 64 bit is 32 doublings. Each 10 doublings, each 10 bits add a factor of 1024, which roughly is a magnitude defined by factor 1000 in our decimal system, too. So the step to 128 is 6 magnitudes and remaining 4 doublings = factor 16, therefore 16x16=256 somegreeknumberword bytes.

From that perspective we'll never see the need for 128 bit CPUs merely for adress space reasons. There are 128 bit and 256 bit busses already in graphics, but merely for a higher parallel throughput, that doesn't end 32 bit code. The need for higher bit cpus will simply arise for performance and precision reasons, eg having wider ALU registers.

Bye, Olaf.