Hi Rick,

It looks like nobody is talking about X# or XSharp here.

I've been using Web Connection to develop web apps for my clients. However, they found out that I am still using FoxPro runtime on the server which they believed it's no longer supported and no assurance how long will it last. They wanted me to get rid of this and re-write the app in C# MVC. This will be a nightmare for me if I re-write all my PRGs to C#. So, I found this X# compiler for VFP. I'm sure you already heard about this. Still at its early stage of development but it looks promising. It has PRG compiler built-in where you can keep your existing VFP codes with minimal changes. One benefit would be no more VFP runtime and COM deployment on the production server.

I wonder if this could be possible for "Web Connection" down the road as I see this product has been stable and matured for years.

Thanks

Dan

I don't think so, but it really depends on how well the X# compatibility goes.

With FoxPro we're looking at legacy technology and even moving FoxPro code to .NET isn't going to make it any less legacy 😄 as far as maintenance and development is concerned. While I think what X# is doing is pretty awesome in terms of technical accomplishment, I just don't see where and how this makes any sense for keeping existing applications going. Even assuming compatibility reaches a level in the mid 90% range it's still going to be problematic running into problems that you won't find until later in the dev cycle.

I feel the same way about VFP 10 and the native compiler. Whatever marginal benefits there might be in these new types of FoxPro based solutions they almost certainly will be negated by the side effects and behavior differences that are likely to crop up. If I have to still re-write at least to some degree to use a new platform it hardly seems worth it to do it with another legacy and even more niche environment.

FoxPro isn't great for Web applications due to its internal threading design, but using tools like Web Connection makes it possible to run even fairly large and complex and performant applications on the Web. IOW, it works and it's good enough for the majority of applications. Nobody is going to build the next Facebook with FoxPro 😏 For applications that were built with FoxPro in mind in the first place, it seems unlikely that there would be scalability/performance issues. In fact, I find my FoxPro Web apps often are snappier than my equivalent .NET or .NET Core applications (less latency, but... also less scalability). So keeping existing apps running with what works seems like a no brainer. Moving to some other the-same-but-not-quite-the-same technology has other risks and whether performance and scalability are significantly better to make this move worthwhile - the jury's still out for that.

+++ Rick ---

Hy, Last year, during the 2019 AtoutFox seminar (French speaking group of Foxpro developers), I attended a demonstration session on X #. It's impressive and for the vast majority of participants in this session, X # is the future to gently replace Visual Foxpro. This year due to corona virus, we were unable to have a further demonstration of the advancement of Foxpro command support under X #. I think (this remains a mere guess on my part) that support for Foxpro's vital functions and commands in building WEB applications should be operational by mid - 2021. Regards

I agree with you Rick, that's why I keep trying to push Web Connection. I've already proven its worth solidly and invested a lot building web applications. However, I am loosing the battle here because these folks learned that I am still using VFP behind-the-scene (due to audit). No matter how much effort I tried to justify, it stick to their minds that VFP is dead with the worry that Microsoft will soon pull the plug and that this old technology should not be used for any new projects moving forward. After endless debates, I gave up and found X# for the reason that I saw the opportunity here where I can re-use the same VFP codes I've already invested with minimal changes. I know it will be very challenging and risky but this is the closest thing I can get. But if I have a choice - Web Connection will still be my preferred tool.

Follow my humble opinion on the topic. I do not see it viable to keep anything based on Xbase, other than what we have today based on West Wind. I believe that if you have to use a new technology, the ideal would be something based on the new existing technologies. If we need manpower in the future, someone who understands well and wants to work with Xbase will become increasingly difficult.

I gave up and found X# for the reason that I saw the opportunity here where I can re-use the same VFP codes I've already invested with minimal changes. I know it will be very challenging and risky

And you really think that using X# is going to be any better in a future audit? People may think of FoxPro as legacy and at this point somewhat obscure, but how about a technology that nobody has ever heard of and probably never will outside of the tiny, tiny XBase community? And especially for those organizations that do these kind of software audits? You think they are going to look at that favorably?

How are you going to justify the fact that this is a virtually unknown tool? Finding people who know this tool and can work with it? The pool of eligible developers is going to be even more limited than what you have in FoxPro today. It may satisfy some superficial administrative requirement to not use legacy technology, but it solves none of the actual, real issues that FoxPro faces which is lack of support from developers, lack of qualified developers, and any sort of vendor support. You're going from one very small niche market, to an even smaller one.

I'm even baffled by WHY the X# folks are putting in the effort to build this. The market for developers is so incredibly tiny and unless they plan to sell this thing at a huge cost, it's almost certain to not recover the development costs. Heck, I can't even justify the minimal work I'm doing on Web Connection. Most of that I do only because I enjoy the work and the technical challenges it involves, but financially there's no money incentive in this market left. How long before a company like X# gives up? And then what? Proprietary product at a dead end? And even if it was open source I doubt there would be enough interest for enough energy to push it forward.

If you really want to address this problem the solution is to re-think of where your code needs to go in the future. And if it's bound to stick around for a long time, then making clear choices that support an eco-system going forward is what you want to look at. If you've been building Web applications with Web Connection, you already have most of the skill set you need to use other tools. The hardest part of a transition from FoxPro to something else is not the silly FoxPro or XBase language - it's the environment, the data access, development paradigm (ie. Web vs. Desktop) etc. X# isn't going to fundamentally change that. So you may get to keep using SCAN/ENDSCAN and REPLACE instead of writing SQL statements, but is that really helping you in the long run? Other platforms have different concepts and the way applications are built. If you've built Web applications, have spent some time with modern JavaScript you are already using other tools that are better positioned to move to other environments.

There are lots of choices for all comfort levels. My choice is .NET but if I want to go down the .NET path, I surely want to go the mainstream route as to not end up in a niche again.

X# might be a great choice in the future for those who really think they have to stick with XBase and don't have external pressure for modernization. Going the X# route is not going to appease those to call for modernization, because XBase code will forever be legacy even if it runs on .NET. And if you're already going down the .NET path, you're still going to have to learn a bunch of .NET concepts anyway. From the there it's not a big step to actually using a standard .NET language (C#, F#, VB) for example.

And it doesn't have to be .NET either. Maybe it's JavaScript with Node and some of the great server frameworks that exist there. Or even something simpler like PHP, or middle ground with Python. There are lots of options, but clinging to FoxPro, especially when the obvious requirements for something else are basically paper tigers rather than a real technical need, is not going to help move you forward and likely won't help with the administrative requirements.

Sorry - got carried away here, but I feel passionately about this because I see it unfortunately too often where a lot of very smart developers are clinging to the notion that the only way forward is to stick with what you know. Yes moving to something new has a learning curve, and you'll probably curse a lot and think about giving up, but at the end of the of that curve you come out with a much better toolkit, support and infrastructure than what we have in FoxPro/XBase today. I've seen it countless times with what used to be die-hard FoxPro developers that went kicking and screaming into .NET and now they are kicking and screaming if they are asked to maintain the legacy Foxpro code. Until you've done something different (and stuck with it long enough to be productive) you don't realize just how far behind XBase environments and languages are.

+++ Rick ---

Rick,
Nice write-up and your insight gives us a lot to think about.

Thanks for giving us much food for thought.

Steve

Hi Rick

I think that you don't know X#.. when you say "etc. X# isn't going to fundamentally change that. " 1 - X# use .NET 2 - X# can transform any Xbase langage to C++ ot C# langage 3 - X# run under 32 and 64 bits 4 - etc... https://www.xsharp.info/ http://www.xsharp.fr/ I suggest you test X # to get a better idea of what it does or does not do. I am sure you will be amazed by its multi-platform and multi-language potential Best regards Gilles

Thanks for your lengthy insights Rick. As always, I enjoy reading your posts...

Just a few comments here:

And you really think that using X# is going to be any better in a future audit?

X# is based on C# and runs in .NET Framework. If let's say, they want me to deploy my "HelloWorld()" function written in VFP to the server tomorrow, I have to use a tool like this. Why? because I don't need to re-write the code in C#. X# will translate it into a .NET .DLL as if it is written in .NET. And this is a compromised solution with the Auditor.

There are lots of choices for all comfort levels. My choice is .NET

I think it's just a matter of choice here Rick, the time constraint is one big factor. In fact, the organization's simple (and crazy) requirement is just to eliminate the FoxPro runtime and COM in the web server (although I opposed). Brainwashed with an auditor's recommendation (of course) is to use C# .NET Framework as this is what they believe, the corporate way to run the business. (I disagree of course)

The other choice is to re-write everything in .NET. Well, then - you'll not gonna get it tomorrow 😃

Web Connection is truly a matured and proven tool for me. X# is too early to judge about this as I have some doubts on its speed and performance.

It may satisfy some superficial administrative requirement to not use legacy technology, but it solves none of the actual, real issues that FoxPro faces

But it sounds like in the case of Danx's clients, that superficial requirement is the overriding concern. Not sure they are really that concerned about code maintainability or eligible developers - they just want to purge their systems of the Foxpro runtimes because the auditors told them it's a dead product.

I agree with your case against clinging to XBase for new development, but there's a valid argument for not throwing out existing source code if it's serving its intended functions.

--sg

@Stein,

That makes a lot of assumptions. First off I seriously doubt that a .NET version of FoxPro will run code as is. It's likely going to require a quite a few modifications to get code to run especially for non-business level code. While that might not be as hard as re-building from scratch, it's still not effortless.

Pushing back against auditors is easy enough if the applications in question are important enough to keep going. These days where you can 'rent' machines running whatever OS and hardware you want to run on in the cloud and have a new server up and running in 15 minutes makes 'legacy' really a thing that can be effectively stretched out. Even Windows 10 can now natively run isolated applications that can be installed in a completely isolated environment and still run like a regular desktop application.

You need to run a ca. 1982 DOS app? There's a VM you can use for that and host it in the cloud. Totally isolated, not a shred of security or potential that it `won't run on some fabled version of Windows that doesn't run x86 code (we've been hearing that since 2004). That's just not going to happen anytime soon even with released software and certainly not with a VM that runs whatever OS version you put on it.

You want a cheap solution because you can't afford re-development? For $50 a month + whatever time to stand up a server, you run your old code there, totally isolated (assuming we're talking about a server application - this is more complicated with desktop applications but there are isolation solutions for that as well).

@Danx,

Auditors are a weird bunch - they go with what the trends are most of the time, not with actual technical concerns. And if that is the case (as Stein suggests basically) then just saying - look ma, we're running on .NET may not be enough. In the end you're still using FoxPro (or the X# XBase dialect). These days the development environment and languages matter too and you can bet the auditors will look at that as well. If I were you I would try and find that out before you go down any route - what's actually going to appease the auditors. And then hope they don't change their mind.

@Gilles Lajot-Sarthou

As I said, I don't doubt the technical accomplishments. And I'd even say if they can pull off what they're promising with high level of compatibility would be amazing. That's great, but the matter remains the same to me at least. There's nothing at this time that could possibly justify me to jump to another XBase technology when:

• There's not going to be any significant new XBase development
• The rest is legacy and updates which makes for a tiny sliver of a market

So X# may benefit a few very hardcore developers. And those developers will, keep that team busy with bug reports, enhancement requests and what not. At the end they'll end up with a better product because of those few devs, but then who then is the target audience? Those 20, 30, 50 hardcore developers?

Maybe consulting around X# will pick up the slack, but it's not just about the money and sustainability. But it's also about an eco-system. To sustain a development environment you also need to grow the people that use it so there's some community around it so questions get answered and tools get built etc. Most of that is gone now...

I can't possibly imagine that any XBase dialect will attract developers from other environments. I can't see a hipster JavaScript dev, or even staid and true .NET or Java Devs jumping ship and going back to XBase. So who then? Existing FoxPro/XBase devs of which there are fewer and fewer by the day? Business people? If they're inclined to 'program' I think these days some visual data tools is much more likely to succeed in that space. What's left?

+++ Rick ---

Thank you, Rick, what makes X# strong is not just the use of XBase-like commands but the transformation of all XBase code into C# code. There is therefore a strong migration of development languages, this is where the strength of X# lies. If we take care to remove from our applications written in Foxpro, the direct management of Xbase tables and commands in favor of SQL commands and a database like SQL Server, PostgreSQL, etc.. then X# will make it possible to migrate more easily all or part of Foxpro source code to C# code. C# code that can be used with Visual Studio. Here is the "miracle" that we expect from X# (miracle of which the first demonstrations let us think that it will take place !!) Time will tell !

Regards

Rick,

Have you even looked at X#?

I am under the impression that you did not:

"And even if it was open source I doubt there would be enough interest for enough energy to push it forward"

The product is fully open source. All the source is on Github.

Robert van der Hulst

XSharp Development Team

www.xsharp.info

So X# may benefit a few very hardcore developers. And those developers will, keep that team busy with bug reports, enhancement requests and what not. At the end they'll end up with a better product because of those few devs, but then who then is the target audience? Those 20, 30, 50 hardcore developers?

Rick,

You've been manipulating these figures for over 10 years now and they are still as wrong as they've always been.

You get confused between the number people who sign up in the VFP conferences and the reality of the VFP ecosystem.

The reason why this ecosystem has vanished along the 15 past years is the endless debates between former 'VFP experts' on whether VFP was better or worse than other languages, which has not the slightest interest. It had an interest in the early 90's, when Java, Python and some other competing languages emerged, not any more after Y2K.

In 2017 I posted a blog entry called The VFP community worldwide, lessons learned from the FoxInCloud site, showing that the audience for FoxinCloud was shifting to the newly developing countries and still strong and much younger than what it seemed.

The reality is the same as for COBOL:

• millions of existing code lines and VFP apps running and servicing hundreds of thousand companies in the world
• hundreds of failure cases in re-writing this code base, in C# or anything else.

What we need as a community, especially from its experts, is a positive way to cope with this reality, arguments for auditors, and economical solutions for companies who still depend on VFP.

X# can definitely be a piece in this giant puzzle.

Thierry Nivelet

Lines of code mean nothing, if those lines of code are never to be touched again.

The number of FoxPro developers is trending towards zero. Anywhere you look online, traffic is dropping. UT - practically dead. FoxCite has a lot less traffic too, although still better than US. Conference attendance has gone to a trickle (last years). User groups for the most part have a handful of people show at most (again here in US don't know in other places). It's more like 3 or 4 friends getting together and talking shop than user groups. And certainly there are no new people coming into this community.

If you see numbers improving or going up it must be somewhere very specific. It's possible to do this with proper effort. I imagine your French user group probably does very well because it's well promoted and supported, and incentivized but that is very rare and unusual. But it just doesn't happen elsewhere. I can't see getting a commercial sponsor or even a host location (as is common for usergroups these days) for a FoxPro group...

Today everything that is left is legacy. I realize very well that FoxPro is not completely dead: I hear from developers and companies almost weekly who desperately need and can't find developers willing to take on maintenance projects to keep up and fix old applications. They have applications that have been running for 20 years. In fact I was just helping to upgrade a server for someone coming from a Server 2000 application last week. The app had been running uninterrupted for nearly 18 years. But also those people that have apps like that, that literally just ran without change for 20 years (an amazing feat for tech in general) are usually so disconnected from the technology they don't even remember how the application, much less the server and architecture works.

This forum isn't very active, but even here job postings usually go unanswered. Where else are they going to go? I usually hear from the same people begging to help them find somebody. If they put up an app on a job board, they get recruiters sending over un-qualified that have never actually used (or heard) of FoxPro. The horror stories are crazy...

Or they want to convert projects to anything else but FoxPro/XBase but don't want to spend/have the money/effort or learn something new. Nobody wants to do the maintenance work and the pool of qualified people that can is declining rapidly due to retirement. Look around the people in this community that are left. We're all getting old and many are already retired or close but still working on. I often hear from business owner stories like this: "I'm just trying to make this app run another few years until I retire". Does that sound like a healthy environment?

Is there still FoxPro work for those that want it? Sure - probably more than ever if you're willing to do the work. But a) finding those people is hard and they are already as busy as can be, and b) there are no new people coming in. This is true for the entire XBase space.

But sure, if you think you can find a market - go for it!

Heck, I'm still here updating and improving Web Connection depite the fact I know that any work I do will never recouperate the efforts other than a spec of pride of maintaining a well used solution that helped a lot of people keep running FoxPro for over 25 years and 15 years after discontinuation. I do it for the fun of it, and often as a learning opportunity for other technologies, but if I needed to support myself with this - forget it. I imagine you see yourself doing pretty much the same with FoxInCloud except you're probably leaning much harder on the consulting end of things. It wasn't always like this though - in the past (mid 90's to mid 2000's) any sort of third party tooling or library was a great way to make a good living on its own.

I keep going, but I have no delusions about this ship turning around and improving 😄. Ain't going to happen.

If the developers you're talking about are not the conference going, forum reading kind then how can they be reached? Even if you could, how do you think they'll respond to new technology if they are the kind that have 9-5 jobs that punch the clock because they have to and aren't really interested in keeping at least a cursory eye on the technology they are using? Most of that group do what they have to and no more and probably falls into the most conservative group of all when it comes to progress.

It's reality that this market has been dying for a long time and it's not coming back no matter how many awesome things and tools happen. We basically have to live on that declining end of the curve. If you think otherwise - I'm not sure what you're looking up to think differently since the signs of decline are everywhere and have been there since Microsoft started completely abandoning FoxPro around the FoxPro 8.0 timeframe.

+++ Rick ---

I hate to be the ultimate spoiler regarding X#, but...

If I were to completely devote the next 1 year to learning the ins and outs of X# will there be a light at the end of the tunnel that is a job?

Sad to say, but FoxPro has been going away for a long time now and, IMO, it just ain't coming back. It was a great ride and a lot of fun, but things have moved on and left it behind.

Robert/All,
I was elated/relieved when I heard of X# as a possible migration path for my large VFP Desktop Application. I will be reviewing all of the potential migration path sessions slated for the Southwest Virtual Conference.

What is being proposed regarding VFP Reports? I have many reports and recreating them in a different tool would be a nightmare.

TIA,
Steve

Steve,

We have our own report engine (it is called ReportPro).

Our current plan is:

• convert VFP reports to XML format
• read this XML file into ReportPro
• run the report in ReportPro

We may have to make some changes to ReportPro to make this work. Our report engine looks a lot like VFP reports but for example our report engine does not use a DataSession but (re)opens the needed tables (when they are not open yet) in new cursors and closes them afterwards. And I would not be surprised if there are properties inside VFP reports that we do not have (yet) in ReportPro.

At this moment ReportPro is based on Win32, but we are already looking at moving at least the Preview and Print part from Win32 to Windows.Forms.

I am afraid that I cannot give a time-frame for this yet. Our project is customer-driven: we set our priorities based on customer feedback and when a customer sponsors development in a certain area of the project than that part gets a higher priority than other parts of the project. We think that makes sense.

We had hoped to see many new FoxPro faces in our community after SW Fox 2019, and there were indeed some new faces, but most people have chosen to download our product for free and not many people have shown their support by buying a Friends Of XSharp subscription.

Robert van der Hulst

XSharp Development Team

www.xsharp.info

Rick,

You have not answered my question "Have you even looked at X#?" so I think I know the answer: you haven't.

I assume therefore that your remarks about it were based on your ideas about the future for the FoxPro and the XBase market in general. That is fine of course, but then you should at least be honest and tell people that you can't judge about the product because you don't know it.

Robert van der Hulst

XSharp Development Team

www.xsharp.info

I've seen several presentations - I never claimed I looked at it or used it...

As I've written here should make it pretty clear that I have no interest spending time in VFP/XBase alternatives or suggesting that as a solution going forward for anything but the most legacy scenarios. I've given my reasoning for this in these posts (if you read them).

The only reason I mention X# in this context is because it's the concrete technology that started off this conversation in the first place.From what I've seen (and even what you showed at previous conferences) X# looks technically impressive (as I stated). I merely question the validity of continuing to string XBase developers forward with the mythical leap to the salvation of the next level solution for FoxPro or XBase developers. Even if you can manage to successfully port a Foxpro application into .NET it's still not going to be a properly architected .NET application. Just running is one thing, but something that is maintainable going forward is another...

Even if you can succeed with all of your ambitious goals, who do you see as your target audience to justify the extensive effort that goes into the development of X#? I have a pretty good idea who, but that is an exceedingly small and rapidly shrinking market. If all of this would have happened 10 years ago, it would have been an awesome opportunity both for your company and the community - but now? It's so sad that some of the most sophisticated tools for FoxPro arrived on the market past the point of no return...

+++ Rick ---